法人サイトのバックアップ設計

1. RPO・RTOを業務側と決めます

RPO（目標復旧時点）は、どれだけ前のデータに戻ることを許容できるかという時間の目標です。RTO（目標復旧時間）は、サービス停止から復旧までに許容する時間の目標です。業務影響に基づいて設定する考え方を、AWS Well-Architectedの復旧目標の解説で確認できます。

RTOにはファイルの転送だけでなく、検知、担当者への連絡、復旧可否の判断、作業、動作確認も含めて見積もります。夜間に担当者がいない体制なら、作業時間だけを測って目標達成と判断しないことが重要です。

2. 保存対象を棚卸しします

WordPressでは、通常、データベースとサイトのファイルの両方が復元に必要です。ファイルだけをダウンロードしても、投稿や設定等を含むデータベースの保護にはなりません。WordPress公式のBackupsを参照し、構成に応じた対象を確認します。

3. 保存間隔・保持期間・保存先を別々に決めます

取得間隔は失ってよい更新量に、保持期間は不具合に気づくまでの期間に影響します。毎日取得していても、問題が発覚する前に健全な世代が消えていれば復旧に使えません。また、本番環境と同じ管理権限で全バックアップを削除できる構成には、権限侵害の影響が及ぶ可能性があります。

以下は本稿の設計例です。実際のデータ量・要件・契約条件に合わせて変更してください。

• 小規模な広報サイトの検討例として、日次の取得と、重要な更新直前の追加取得を組み合わせます。
• 保持期間は一律に決めず、誤更新の発見や確認に何日かかるかを踏まえて選びます。
• 本番と別の保存先や、削除権限を分離する方法を検討します。暗号化・復号鍵の保管も含めます。
• 取得失敗・容量不足を担当者に通知し、「取得したはず」のまま放置しない運用にします。

ファイル同期やミラーだけでは、誤削除まで反映する場合があります。過去の状態を保護できるか、復元する機能と保持条件を確認してください。

4. 復元試験を運用に組み込みます

AWSの災害復旧テストの指針では、復旧方法とRTO・RPOの達成を試験で確認する考え方が示されています。小規模サイトでは、まず本番に影響しない検証環境で、次の手順を確認する方法を提案します。

1. 試験条件を決める：対象世代、開始時点、合格基準、担当者、想定障害を記録します。
2. 検証環境を隔離する：外部公開、実メール送信、決済、予約登録などを無効化・制限します。
3. ファイルとDBを復元する：構成情報とバージョンを合わせ、認証情報は安全な経路で設定します。
4. 業務機能を確認する：トップだけでなく記事、画像、管理画面、フォーム連携も試験用条件で確認します。
5. 時間と欠損を測る：作業時間と戻せたデータ時点を記録し、想定RTO・RPOとの隔たりを整理します。
6. 手順を更新する：不足した権限、失敗した操作、担当不在時の課題を記録します。

一例として四半期ごとの確認と、重要な構成変更後の再試験を検討できます。頻度は本稿の例示であり、どのサイトにも十分だという保証ではありません。本番への切替試験が必要なシステムは、別途承認と切戻し計画を用意します。

制作にはAIによる原稿作成の補助を使用しています。公式資料の説明と編集上の提案を区別し、具体例は設計上の仮定として掲載しています。

制作にはAIによる原稿作成の補助を使用しています。公式資料の説明と編集上の提案を区別しています。

修正履歴：2026年9月20日 初稿作成