許容データ損失を先に決める
復旧時点の目標をRPO、復旧までの時間の目標をRTOと呼びます。例えば前日分へ戻すと当日の問い合わせ履歴が消えるなら、その損失を業務として許容できるか確認します。フォームがDB保存しない構成でも、送信先メールや外部台帳の保全は別に必要です。
頻度の設計例
| サイトの状況 | 設計の出発点 |
|---|---|
| 月数回の会社案内更新 | 定期取得に加え更新前後を保存 |
| 毎日記事・画像を追加 | 日次取得と追加後の取得を検討 |
| EC・会員・予約を運用 | より短い間隔、DB整合性と差分復旧を検討 |
これは保証基準ではなく設計例です。保存容量、処理負荷、復元方法と組み合わせて調整します。
保存期間は発覚の遅れも考慮する
改ざんは当日に気付くとは限りません。短期間の世代だけだと、全て侵害後のコピーになることがあります。日次・週次・月次などを組み合わせ、正常時点を探せる期間を確保します。個人情報の保管目的・期間も社内ルールと整合させます。
定期的な管理で確認すること
取得失敗、容量、外部転送、古い世代の削除、復元試験を確認します。バックアップ設定を変更した際は、次回の取得結果まで確かめ、設定画面だけで完了にしないでください。
世代管理を設計する例
日次の取得を一定期間、週次・月次の取得をより長く残す方法があります。ただし保存数は固定の正解ではなく、更新頻度、異常の発見までの時間、保管費用、復旧要件から決めます。長期保管には個人情報や古い秘密情報も含まれるため、アクセス権と削除ルールを合わせて管理します。取得間隔を短くしても、容量不足で失敗しているなら役立ちません。成功率、最終取得時刻、ファイルサイズ、外部転送、復元できる最古・最新の世代を定期的に点検します。
よくある質問
DBは毎日、画像は週次でもよいですか？
更新頻度と整合性を確認します。DBが参照する画像を戻せない組合せは避け、どの時点の組合せで復元できるかを記録します。差分取得を使う場合も、必要な基点が残っているか確認します。
長期保存すればするほど安全ですか？
保存量が多いほど正常世代を探しやすい場合はありますが、管理負担と流出影響も増えます。保存期間を目的に合わせ、原本と作業用コピーを区別して整理します。