バックアップの復元テスト｜業務側の5つの確認

はじめに

障害の後、担当者から「バックアップから戻せました」と報告が来た。ところが営業担当は、受注に添付した発注書を開けない。経理担当は、請求済みかどうかを判断できない。システムが起動したことと、仕事を再開できることの違いを示す、説明用の例だ。

バックアップの復元テストは、保存したデータを取り出し、必要な機能や情報を使える状態に戻せるか確かめる作業である。業務部門が決めたいのは、復元コマンドではない。どの仕事を優先し、いつの情報まで戻し、何を確認すれば再開してよいとするかだ。

この記事では、発注側の担当者やDX推進担当者が、情報システム部門・保守会社と合意するための5つの確認項目を整理する。以下の例や記録案は一般的な整理方法であり、個別システムの復元可否や所要時間を保証するものではない。

保存成功・復元完了・業務再開を分ける

まず、報告の意味をそろえたい。「保存成功」はバックアップを取得できた状態、「復元完了」は選んだデータやシステムを復元先へ戻せた状態、「業務再開」は必要な操作と整合性の確認を終え、責任者が再開を判断した状態、と分けて記録する。

AWS Backupの公式資料でも、復元ジョブの完了後に別の検証処理を実行し、その結果を確認する仕組みが示されている。AWSの利用を前提にする必要はないが、復元処理の成功と利用可能性の検証を別に扱う点は参考になる。

「復元が終わったので合格」と先に決めず、業務側の確認が残っていれば、そのまま未確認とする。逆に、一つの業務が再開できても、試していないシステムまで復旧済みにはしない。

業務側で合意する5つの確認項目

1. 復元対象を、再開したい仕事から選ぶ

最初に、障害が起きたときに止められない仕事を一つ選ぶ。「顧客データベースを戻す」より、「既存の受注内容を確認して出荷依頼を作る」のように書くと、必要な情報を洗い出しやすい。

受注業務なら、受注本体だけでなく、顧客情報、商品情報、添付書類、承認状態が必要かもしれない。画面へログインするための設定や、外部サービスの接続条件も確認する。データを戻しても、利用者の認証が使えなければ仕事は始められない。

対象表には、情報の名前、管理元、対象の期間、復元担当、業務確認者を記す。対象外も書き、「メールの過去履歴は今回の試験に含めない」など、今回の合格が及ぶ範囲を明らかにする。

移行に伴う復旧準備なら、移行計画書に整理する項目と対象表を対応させる。ただし、新環境への移行や切り戻しの試験を、普段のバックアップ復元テストと同じものにはしない。想定する障害と戻す先が異なるためだ。

2. 戻せる時点と、再開までの時間を決める

「最新データへ戻したい」「なるべく早く再開したい」だけでは、合否を判断できない。どれほど前までのデータ損失を許容するか、サービス停止から再開までどれほど待てるかを、業務への影響から決める。

AWSの復旧目標の説明では、許容する停止から復旧までの時間をRTO、許容できるデータ損失の時間幅をRPOとして整理している。どちらも目標であり、バックアップを設定しただけで達成が保証される数値ではない。

たとえば、受注を前日終了時点へ戻す案なら、当日分を別の記録から照合・再入力できるかを業務側で確認する。再入力の担当も記録もなければ、その案は業務上成立しない。必要な目標を技術担当へ伝え、費用や実現方法と合わせて調整する。

試験では、復元処理の時間だけでなく、担当者への連絡、必要な権限の確保、データの確認にかかった時間も分けて残す。検証環境で一度測った時間を、本番障害時の所要時間と断定しないことも重要だ。

3. 安全な復元先と、操作してよい範囲を確認する

実際の操作は、利用する製品の公式手順と保守担当者の判断に従う。業務担当者が独断で本番へ復元してはならない。試験計画では、本番を上書きしない復元先と、想定外の外部送信を止める方法を先に確認する。

受注システムを試すなら、復元した注文から出荷依頼や請求通知が実際の取引先へ送られないかが論点になる。画面に「テスト」と表示するだけでなく、接続先や送信処理の制御を技術担当に確認してもらう。

復元データに個人情報や機密情報が含まれる場合は、閲覧者、保管期間、試験終了後の扱いも決める。本番から切り離した環境だからといって、誰でも見てよいデータにはならない。

また、誤削除を想定した試験と、侵害を受けた後の復旧判断は分ける。後者では、戻すデータや環境の安全性を別途確認する必要がある。試験で戻せたという理由だけで、本番への再接続を承認しない。

4. 起動確認の先に、業務の合格条件を置く

業務側の確認は「画面が出る」から一歩進める。事前に選んだ取引やデータを使い、何と照合し、どの状態なら合格かを決める。次は受注業務の記入例であり、全システム共通の必須基準ではない。

件数だけが一致しても、中身や関係が正しいとは限らない。反対に、保存対象を絞っている場合は、すべての件数一致を求めると誤った判定になる。確認対象と期待結果をセットで残す。

すべてを一度に試せないときは、確認済み・不合格・未実施を分ける。重要な業務が未実施なら、全体合格にまとめない。業務責任者が再開を判断するために、何が確認でき、何が残ったかを明確にする。

5. 担当者と、次回までに直す条件を残す

復元の操作担当、業務内容の確認者、再開の判断者を分けて決める。保守会社の作業終了報告だけで業務側の確認を省かず、担当者が不在の場合の連絡先も整理する。

日本自動車工業会・日本自動車部品工業会の中小企業向け手引きの72ページでは、復元手順書や定期的な復元テストを含むチェック例と、記録を経営層へ報告する扱いが示されている。掲載された頻度を全業種一律の義務とみなすのではなく、自社の更新頻度、業務影響、契約上の条件に合わせて計画したい。

試験後は、単に「次回も実施」とせず、見つかった問題と修正担当、期限、再試験が必要な範囲を残す。設定変更や担当交代など、手順が実態とずれやすいタイミングも見直しの契機として計画へ含める。

一枚の確認票で、未確認を隠さない

記録は大きな報告書でなくてもよい。少なくとも、対象業務、使用したバックアップの識別情報と時点、復元先、開始・終了時刻、確認者、項目別の結果、未確認事項、改善担当をたどれるようにする。

たとえば「復元処理は完了。受注内容と添付書類は確認済み。後続連携は未実施のため、出荷業務の再開判断は保留」と書けば、残る作業が伝わる。「成功」の一語でまとめるより、次の担当者が判断しやすい。

復元テストで見つけた不足を要件へ戻すときは、要件トレーサビリティの整理を参考に、確認項目と元の仕様を結び付ける。何を直せば再試験できるかが明らかになる。

まずは一つの重要業務で、再開条件を言葉にする

最初の打ち合わせでは、「どの業務を試すか」「戻せる時点をどう判断するか」「誰が再開可能と確認するか」を決めよう。安全な復元先や操作手順は、情報システム部門・保守会社と具体化する。

要件や手順が複数の資料に散らばっているなら、上流工程AIワークスペースKakusillのような、要件定義から仕様管理までを支える仕組みの活用も検討できる。復元テストを自動実行する製品という意味ではなく、業務上の確認条件を関係者と整理するための選択肢だ。

バックアップの有無を尋ねるだけでなく、業務の再開条件を合意する。その一枚を持って技術担当と試験計画を確認することが、次の行動になる。