Tesujiバックアップの成功通知を受け取ったら、次は「何を、どの時点まで、誰が戻せるか」を確認します。データを取り出せることと、サービスや業務を再開できることを分けて点検すると、復旧時の不足が見つかります。
IPAは2026年9月30日の中小企業向けガイドライン改訂で、「バックアップを取ろう！」を基本対策に加えました。IPAのガイドライン
まず、バックアップに含まれる範囲を確認する
次の表はTesuji編集上の棚卸し例です。自分たちの構成に合わせ、保存済みのものと未対応のものを分けます。
| 対象 | 確認すること |
|---|---|
| データベース | 取得日時・保持世代・戻せる時点・データの整合性 |
| 添付ファイル・画像 | DBとは別の保存先も対象に含まれるか |
| アプリ・設定 | 再構築に必要なコードと設定の所在 |
| 暗号化・アクセス | 復元に必要な鍵や権限を、担当者が利用できるか |
| 業務の再開 | ログイン・検索・登録・連携などを確認する手順があるか |
たとえばSupabaseの公式資料は、データベースのバックアップにStorage APIで保存したファイル本体は含まれず、DBにはそのメタデータがあると説明しています。DBを復元しても、削除されたファイル本体まで復元されるとは限りません。Supabaseのバックアップ対象
利用するサービスの「自動バックアップ」が何を指すか、対象外のデータや設定も含めて確認する必要があります。
どこまで戻り、いつ再開できればよいか
業務の担当者と、許容できるデータの巻き戻りと、停止時間の目安を決めます。たとえば「昨日のデータは残るが、今日の受注を再入力できない」なら、取得成功だけでは必要な復旧を満たせません。
この例は編集上の検討例です。バックアップの頻度、保持世代、利用可能な復元時点を、業務上の必要性と照合します。同期やレプリケーションがある場合も、誤削除前の状態に戻せる世代が残るかを確認します。
本番とは分けた環境で復元を試す
AWS Backupの公式資料でも、定期的な復元可能性の評価と、復元処理にかかった時間の確認を扱っています。AWSの復元テストの説明
復元演習では、バックアップから戻せたかに加え、利用者の操作まで確認する計画を立てます。メール送信や課金などの外部処理が誤って動かない検証環境を用意し、担当者と必要な権限を決めて実施します。
記録の例は、バックアップの取得時刻、復元した対象、開始・終了時刻、動作確認の結果、足りなかったもの、次の確認予定です。クラウドのテスト機能を使う場合も、対象リソース・費用・後片付けは事前に確認します。
侵害が疑われる場合は、復元前の確認も必要
JPCERT/CCは、被害を免れたバックアップの保護や、復旧前の原因への対処を説明しています。切り離したシステムをネットワークへ戻す前には、マルウェアやバックドア、不正な設定などが排除されていることを確認し、復旧後も再発を監視します。JPCERT/CCの復旧FAQ
担当者は、どのバックアップを使うかと、再接続・業務再開をいつ判断するかを分けて決めます。攻撃による被害が進行している場合は、専門の対応担当者と連携して進めます。
最初の一回で残しておきたいこと
- 何をバックアップし、何が対象外か。
- 保存先と削除・復元の権限を誰が管理しているか。
- 復元した日時・確認した操作・再開までにかかった時間。
- 担当者が不在でも、手順と必要な情報へたどり着けるか。
これはTesuji編集上の確認案です。取得の成功記録と復元の実績をそろえることで、いざというときの判断材料にできます。
確認日：2026年10月28日。サービスのプラン・保持期間・復元条件は、利用時点の公式仕様で確認してください。