バックアップ復元テストの証跡管理｜対象・復旧時刻・データ完全性を確認する方法

バックアップの復元テストでは、保存先にファイルがあることだけでなく、必要な時点のデータを戻し、業務で使える状態まで復旧できることを確認します。対象と版、復旧時刻、データ完全性、失敗後の改善と再テストを一組の記録にすると、次の担当者も同じ条件で結果を検証できます。

「バックアップジョブは成功」「ファイルの読み出しは成功」「利用者が業務を再開できる」は、異なる確認結果です。画面の成功表示だけで完了にせず、どこまで実行し、何を照合し、何が未確認なのかを残してください。

---

本記事のポイント

1. バックアップの保存成功と業務の復旧成功を分け、対象・取得時点・期待値を固定して復元テストを実行します。
2. 復元終了と業務確認終了の時刻を分け、件数・内容・参照関係・業務操作を照合して、未確認の範囲も記録します。
3. 失敗した条件、改善担当、期限を元のテストへ結び付け、修正後の再テストと検証用データの処理まで確認します。

---

1. 復元対象と合格条件を先に固定する

復元テストの目的は、障害が起きたときの復旧能力を実際の操作で確かめることです。連絡先や判断の流れを討議するセキュリティ机上演習の観察記録とは分けます。机上で「戻せる」と回答できても、復号鍵を取得できるか、データベースを起動できるか、必要な時間内に業務を再開できるかは、実行しなければ確認できません。

対象は「全システム」ではなく、業務単位で選びます。例えば受注処理なら、受注データだけでなく、商品・顧客マスタ、添付書類、アプリケーション設定、利用者の権限、認証と接続先の依存関係を整理します。一つのファイルを戻せた結果を、受注業務全体の復旧成功へ広げて解釈しないことが重要です。

NISTのSP 800-53 Rev.5では、CP-9で利用者情報、システム情報、関連文書のバックアップと、その機密性・完全性・可用性の保護を扱います。CP-4は計画のテスト、結果のレビュー、必要な是正を扱います。これらは採用する管理策を検討するための米国の資料であり、日本の一般企業に一律の法的義務や実施間隔を課すものではありません。ここで示す台帳と手順は、管理策を参考にした実務上の提案です。

テスト前には、少なくとも「対象システム・データ」「バックアップ取得時点」「復元先」「手順書と設定の版」「合格条件」「実行担当と業務確認者」を固定します。最新のバックアップだけを選ぶのではなく、その取得時点へ戻した場合に失われる更新と、利用者が許容できる範囲も確認します。

確認する項目	テスト前に決めること	証跡として残すこと
対象と時点	どの業務・データを、どの取得時点へ戻すか	対象ID、バックアップID、取得時刻、設定・手順の版
復旧時間	何をもって業務再開とするか	開始、復元終了、業務確認終了、承認の時刻
完全性と利用可否	何を期待値と照合するか	件数・対象ID・内容・参照関係・業務操作の結果
失敗と再確認	中止条件、改善担当、再テストの完了条件	エラー、未確認範囲、修正内容、再実行の条件と結果

合格基準は業務に応じて具体化します。「動く」では曖昧なので、「検証用の受注IDを検索でき、商品と顧客を参照し、帳票を出力できる」などの操作へ落とします。成功件数だけでなく、対象外にした業務、確認できなかった依存先、実施を省いた操作も記録します。

2. 復元先を隔離し、必要な権限と依存関係を確認する

本番データをそのまま試験環境へ戻すと、顧客宛てのメール、請求、外部サービスへの更新が動くおそれがあります。実行前に、本番の宛先・認証情報・連携ジョブを洗い出し、外部への送信や更新を止められる復元先を準備します。単に環境名を「テスト」に変えるだけでは、隔離した証拠にはなりません。

確認するのは、ネットワークの接続先、通知と定期実行の設定、アクセス可能な利用者、データを出力する場所、実行後の削除方法です。本番の復旧先を使う必要があるテストは、通常の検証とは分けて影響範囲、切替・中止の条件、責任者を定めます。訓練目的のために現在の本番データを上書きする手順を、担当者の判断だけで開始しないでください。

暗号化されたバックアップでは、ファイルを読める権限と復号鍵を使える権限が別の場合があります。鍵の所在、取得手順、担当者不在時の経路を確認します。鍵やパスワードそのものを台帳や画面キャプチャへ貼り付けず、鍵の識別子と利用可否、権限の確認結果を残す方法にします。

復元に必要な依存関係も、順序付きで記録します。データベースの前にストレージが必要なのか、アプリケーションの起動前に認証基盤が必要なのか、バックアップソフトウェアの利用にライセンスや特定の実行環境が必要なのかを確かめます。担当者の端末にしかない手順や資格情報へ依存していた場合は、再現条件が不足しているとして扱います。

実行前チェックは、次の順で進めると範囲が明確になります。

1. 対象と期待値を確定する。バックアップIDと取得時点を選び、何の件数・内容・業務操作を照合するかを決めます。
2. 復元先と外部接続を確認する。本番と区別した保存先、宛先、送信停止、ジョブ停止の設定を確認します。
3. 権限と鍵を確認する。実行者と確認者が必要な範囲へアクセスでき、復号に必要な経路を使えることを確かめます。
4. 依存関係と中止条件を確認する。起動順序を揃え、本番への接続や予定外の送信が見つかったら中止する条件を共有します。
5. 記録と後片付けを準備する。時刻を記録する基準、ログ保存先、検証用データの回収・削除、一時権限の解除担当を決めます。

保存媒体の処理まで含む場合は、記憶媒体のデータ消去確認も参照してください。復元テストが成功しても、検証用の複製や一時的に許可したアクセスが残れば、別のリスクになります。

3. 復旧時刻とデータ完全性を、同じテストIDで照合する

復元を実行したら、対象と版、復旧時刻、データ完全性、改善と再テストの四つを同じテストIDへ結び付けます。ログ、実行結果、確認票が別々でも、共通のIDから関係を追えるようにします。記録の形式を増やすことより、どの結果がどの条件を証明するかが分かることを優先します。

復旧時間の目標を扱うときは、RTO（目標復旧時間）とRPO（目標復旧時点）を区別します。SP 800-34では、RTOをシステム資源が利用できない時間の限度、RPOを障害後にデータを戻せる過去の時点として扱います。業務が許容できるデータ損失からRPOを決め、実際に戻せた取得時点と照合します。RTOと業務全体の許容停止時間は同じとは限らず、システム復旧後のデータ再処理や業務確認に必要な時間も別に見積もります。

NISTのSP 800-34 Rev.1は、業務影響分析に基づく優先度や復旧要件を整理し、テスト・訓練・演習と計画の保守を扱います。自社では、対象業務の責任者が目標と確認操作を合意したうえで、その目標へ実測結果を比較します。ツールの既定値や担当者の感覚だけで、許容できる停止時間を決めないようにします。

例えば、検証開始9時、データ復元終了9時40分、アプリケーション起動9時50分、業務操作の確認終了10時20分であれば、復元操作は40分、開始から業務確認終了までは80分です。これは記録方法を説明する例であり、一般的な所要時間や特定製品の性能ではありません。本番障害の検知から判断・準備までを実行していなければ、その時間は含まれていないと注記します。

取得時点も同様です。午前0時のバックアップを戻せたことと、午前9時までの更新を戻せたことは別です。後続のログや差分を適用する手順を実行した場合は、適用したファイル・順序・最終時点を記録します。実行していない追加復旧を、可能だろうという推測で合格に含めないでください。

データの完全性は、次のように複数の確認で支えます。

• 対象と件数：対象のテーブル、ファイル、ID範囲が一致し、欠落や重複がないかを確認します。期待値は現在の本番ではなく、選んだバックアップ取得時点と整合する資料から用意します。
• 内容と参照関係：代表レコードの値、添付ファイルの開封、主キーと参照先、文字や日付の扱いなどを照合します。件数が同じでも内容が正しいとは限りません。
• ファイルの整合：取得時点の信頼できる値がある場合、サイズやチェックサムを比較します。同じバイト列であることと、アプリケーションが使える状態であることを分けます。
• 業務動作：検証用の検索、入力、参照、帳票出力など、合格条件で定めた操作を業務確認者が試します。接続を止めた外部サービスは、実接続の動作を未確認として残します。

CP-9の追加管理策には、バックアップ媒体の信頼性と情報の完全性を確認するテストと、サンプルを使った選択したシステム機能の復元テストが別項目として示されています。サンプルの成功は有用ですが、全件や全依存関係の成功とは同義ではありません。選んだ対象、抽出方法、対象外の範囲を記録し、重要な業務へ対象を広げる判断につなげます。

ログの時刻に差がある場合は、タイムゾーンと時計の基準も残します。セキュリティ事故の時系列整理で扱うように、観測した時刻と推定した時刻を区別すると、どこに時間がかかったかを誤って判断しにくくなります。キャプチャだけでなく、対象IDと実行条件を機械的なログや確認票へ結び付けてください。

4. 失敗を改善へつなぎ、再テストまで閉じる

復元が失敗した場合は、原因を「担当者の手順ミス」へ急いでまとめず、どの段階で何が起きたかを分けます。バックアップの欠損、復号鍵へのアクセス不足、設定の不足、ソフトウェアの非互換、依存サービスの停止、業務確認の不一致では、改善する対象が異なります。

台帳には、失敗した操作、エラーやログへの参照、影響を受ける業務、確認できた範囲、未確認の範囲、原因の仮説、改善担当、期限、再テスト条件を記載します。秘密値や顧客の実データをそのまま載せず、必要な証跡を権限のある保存先へ置き、台帳から参照できるようにします。実行者と業務確認者の結果が違う場合も、違いを残したまま追加確認へ進めます。

改善後の完了条件は、設定を変えたことや手順書を改訂したことだけではなく、失敗した条件で再実行して期待値が一致したことにします。新しいテストIDを付けても、元の失敗IDと関連付け、変更した版、実行日時、結果を追えるようにします。対象や条件を変えた場合は、その違いを記載し、単純な再現成功とは区別してください。

実施頻度を一律に「毎月」とする必要はありません。業務の重要度、バックアップ方式、変化の頻度、過去の失敗、契約や組織の規程から定めます。定期日程に加えて、保存先、復号鍵、アプリケーションの版、データ構造、復旧担当が変わったときの追加確認を決めると、前回の成功を現在の構成へ無条件に持ち越すことを防げます。

復元テストの証跡は、成功画面の保存ではなく、同じ条件で業務の利用可否を再確認できる記録です。テスト終了時には、検証用データの回収・削除、一時権限の解除、止めたジョブの扱いまで確認します。未解決の問題を受容して次へ進む場合は、承認者、期限、代替策を残し、合格した範囲と未解決の範囲を分けて伝えます。

よくある質問

バックアップジョブが成功していれば、復元テストは省けますか？

保存処理の成功だけでは、必要なデータを戻して業務で使えることを確認できません。復号、依存関係、起動、データ照合、業務操作まで、対象に応じたテストを行い、実行していない範囲を残します。

チェックサムが一致すれば、完全性確認は終わりですか？

信頼できる取得時点の値との一致は、バイト列の整合を確認する手段です。参照関係、アプリケーションの起動、業務操作の正しさまで証明するものではないため、件数・内容・利用可否も別に照合します。

サンプルの復元に成功したら、全体を合格にできますか？

サンプルで実行した範囲の成功として記録します。全件、別の取得時点、未確認の依存先まで成功したと判断せず、重要度に応じて対象を広げます。抽出方法と対象外の範囲も証跡に含めます。

復旧時間は、復元ツールの実行時間だけで測りますか？

目的によって区間を定めます。ツールの所要時間と、開始から業務利用可能になるまでの時間を分け、起動・検証・承認の時刻も残します。障害の検知や切替判断を実行していないなら、その時間を含まないテストであることを明記します。

NISTの管理策に従えば、日本企業でも必ず月次テストが必要ですか？

そのような一律の義務を示す資料ではありません。組織が採用する管理策、業務上の重要度、構成変更、規程・契約に基づいて頻度と対象を決めます。NISTの項目は、確認漏れを減らすための参考として使います。