バックアップの復元テストでは、データが戻ったことに加え、必要な業務を再開できるかを確認します。最初に決めたいのは、何を戻すか、いつまでに戻すか、どの状態を合格とするかの3点です。本記事では、企業のIT担当者がテスト計画を作るための手順と記録例を整理します。
「バックアップ成功」と「業務復旧」を分けて確認する
バックアップジョブの正常終了だけでは、復元後のアプリケーション操作まで確認したことにはなりません。Microsoftのバックアップと回復の指針も、復元したデータの整合性、アプリケーションの機能、復旧にかかった時間の検証を挙げています。Microsoftのバックアップテスト指針
テスト計画では、次の3つの結果を別々に残すと、未確認の範囲を把握できます。これは計画を作るための整理例です。
| 確認段階 | 確かめること | 記録する証拠の例 |
|---|---|---|
| バックアップ取得 | 対象の取得処理が完了したか | 対象名、取得時刻、ジョブ結果 |
| データ復元 | 選んだ時点のデータを読み出せるか | 復元先、復元時刻、件数や内容の照合結果 |
| 業務再開 | 利用者が必要な処理を行えるか | ログイン、検索、登録などの確認結果 |
例えばファイルを復元できても、利用者の権限で開けるかが未確認なら、その項目は「未確認」のまま残します。すべてを一つの「成功」にまとめないことが大切です。
1. RTO・RPOとテスト対象を決める
復旧の目標は、システム担当者だけで決めず、業務側が許容できる停止とデータ損失から整理します。
RTO（目標復旧時間）は、サービス停止から復旧までに許容する時間の目標です。RPO（目標復旧時点）は、どの程度の期間のデータ損失を許容できるかを示します。例えばRPOを1時間とすることは、直近1時間分の更新を失う可能性を許容する目標設定です。目標を置くだけで、その復旧能力が保証されるわけではありません。AWSによるRTO・RPOの説明
以下は、受注管理システムを対象とした仮の計画です。数値は推奨値でも自社の実績でもありません。
| 項目 | 記入例 |
|---|---|
| 再開したい業務 | 受注の検索と新規登録 |
| 停止の起点 | 利用者が受注処理を行えなくなった時刻 |
| RTO | 停止から4時間以内に対象業務を再開 |
| RPO | 停止前1時間以内の更新まで復元 |
| 対象 | アプリケーション、データベース、添付ファイル、認証と設定 |
| 業務確認者 | 受注部門の担当者 |
| 除外範囲 | 外部連携先そのものの復旧。接続確認は別途実施 |
対象のつながりが曖昧なら、先にシステムと依存関係の確認項目で整理できます。ファイル単体の試験なのか、システム全体の復旧訓練なのかも区別しておきましょう。
2. 本番に影響しない復元先を準備する
Microsoftは、復旧テストを本番から分離した非運用環境で行う方法を示しています。復旧手順の検証
計画では、復元先の名前を決めるだけでなく、そこで動くアプリケーションの接続先も確認します。次は実施前の確認例です。
- 本番のデータベースやファイルを上書きしない復元先か。
- テスト環境から顧客へのメールや外部システムへのデータ送信が発生しないか。
- テスト担当者が必要な復元操作を行え、復元データを扱う権限も確認されているか。
- 暗号化したバックアップを読むための鍵や、必要な設定を利用できるか。
- テスト終了後に削除するリソースと、保存すべき確認記録が分かれているか。
本番データを使う場合は、テスト環境でもその情報の取扱条件を守る必要があります。権限や接続先が確認できない場合は、復元を開始する前に担当者へ確認します。
3. 復元後にデータと業務操作を照合する
復元操作は、使用している製品とバックアップ方式の公式手順に従います。AWS Backupには、復元ジョブの実行と所要時間を定期的に確認する復元テスト機能があります。ただし、本稿の業務操作表まで自動で確認されるという意味ではありません。AWS Backupの復元テスト
手動・自動のどちらでも、テスト前に期待する状態を決めておきます。復元後に初めて「何が入っているはずか」を探すのでは、合否を判断しにくくなります。
| 確認項目 | 期待する状態の例 | 結果の残し方 |
|---|---|---|
| 復旧時点 | 指定した時点の受注データがある | 取得時刻と更新日時を照合 |
| データ内容 | 対象受注と添付ファイルの対応が一致 | 代表データのIDと照合結果 |
| 認証・権限 | 業務担当者が許可範囲の情報を閲覧できる | 確認した権限と操作結果 |
| アプリケーション | 検索とテスト用データ登録ができる | 操作手順、結果、エラー |
| 周辺接続 | 試験対象の連携経路が利用できる | 接続先と検証方法 |
この表は記入例で、全システム共通の合格基準ではありません。確認用データの範囲、全件照合が必要な箇所、外部送信を伴う操作の代替方法を、それぞれのシステムに合わせて決めてください。
4. 復元時間と業務再開までの時間を別々に測る
復元処理が短時間で終わっても、業務再開までにかかった時間は別に記録します。テストでは、障害の想定時刻、担当者の招集、復元開始、復元完了、業務確認完了を時系列で残すと、どこに時間がかかったかを振り返れます。
先ほどの仮例で、停止を想定した時刻が9時、復元開始が10時、復元完了が12時、業務確認完了が13時30分だったとします。復元処理は2時間でも、対象業務の再開までを測ると4時間30分です。RTOを4時間としていたなら、この試験結果は目標未達と記録します。
同じ例で、復元できた更新が7時30分までなら、9時の停止に対して1時間30分の更新が失われる想定です。RPOが1時間なら、こちらも目標に達していません。この計算は仮の時刻による説明で、特定製品の性能値ではありません。
5. 未達項目を手順・構成・目標に分けて見直す
結果が未達だった場合は、原因と次の確認を結び付けます。以下は改善内容を整理するための例です。
| 起きたこと | 次に確認すること |
|---|---|
| 復元開始までに時間がかかった | 連絡先、承認、権限、手順の参照先 |
| 復元処理が長かった | データ量、復元方式、復元先の制約 |
| 目的の時点へ戻せなかった | 取得頻度、取得失敗、保持期間、利用可能な復旧時点 |
| データは戻ったが業務が動かなかった | 認証、設定、依存システム、アプリケーションの整合性 |
| 合否を決められなかった | 期待値、確認担当者、記録すべき証拠 |
目標を緩めるだけで合格にせず、業務が許容できる条件と必要な対策を再度照合します。変更した箇所は再テストし、試していない範囲も記録に残します。
最初の一歩は、重要な業務を一つ選び、「戻す対象」「合格条件」「確認者」を書き出すことです。基盤の構成や運用の整理が必要な場合は、テクノヴァースのインフラ支援もご覧ください。