バックアップの復元訓練を経営者が確認する。保存成功だけでは足りません

復元訓練では、データを使え、関係を保ち、業務を再開できるか確認します。三つを合格条件とし、証跡を残します。

注文データでは、注文本体だけでなく、明細、顧客、決済・出荷状態との対応と、担当者が通常業務へ進めることまで確認します。保存成功の報告ではなく、「注文業務を戻せます」という答えが必要です。

SaaS解約時のデータ移行でも同じです。書き出したファイルを開けることと、添付・履歴・参照関係を含む業務を戻せることを分けて確認すると、解約後に元サービスを参照できなくても再利用できるかを判定できます。

ただし、三つの条件を抽象語のまま並べても判定は割れます。誰が何を見て、どの証拠がそろえば承認するのかを定めます。平時の訓練を経営判断に変えるには、判定の境界まで先に決める必要があります。

バックアップの復元訓練は業務の合格条件で承認する

保存ジョブの成功は、データを戻せることも、戻したデータで仕事ができることも証明しません。2026年9月21日時点で、AWS Well-Architected Frameworkの復旧テストに関する公式資料は、バックアップから定期的にデータを復元し、元データが含まれること、破損やアクセス不能がないこと、データ損失が定めたRPO内であることを確認するよう示しています。バックアップの実装がRTOとRPOを満たすかも、復旧テストで検証する対象です。

NIST SP 800-34 Rev. 1の整理では、RPOは停止後に復旧するデータの目標時点です。RTOは、他のシステムや業務へ許容できない影響が出る前までに、対象システムが利用不能でいられる最大時間を指します。業務全体の最大許容停止時間とは分けて考えます。略語を承認するのではなく、「注文をどの時点まで戻すか」「いつまでに受注後の処理を再開するか」を業務の言葉で決めます。具体的な時間は事業や契約によって変わるため、他社の数字を借りず、自社が耐えられる停止とデータ損失から定めます。

ここで経営者が決めるのは、復元コマンドやデータベースの操作方法ではありません。どの業務を戻せれば会社として合格なのか、許容するRTO・RPOは何か、誰が業務上の利用可能性を判定するかです。技術担当者には復元作業と技術的な検証を任せても、「会社が使える状態」の定義まで任せきりにはできません。

検証ツールにも境界があります。2026年9月21日時点のPostgreSQL 18のpg_verifybackup公式文書は、ベースバックアップの整合性検証だけでは全確認を網羅できないとしています。テスト復元も行い、復元したデータベースの動作とデータを確認すべきだと説明しています。PostgreSQL固有の仕様ですが、ツールの成功と業務復旧を分ける参考になります。

僕なら、経営会議には合格条件ごとの判定を出してもらい、ツールの成功画面はその証拠の一部として扱います。技術の報告を経営が承認できる言葉へ変える役割が曖昧なら、経営と技術をつなぐ人がいないと、会議は決まらないで整理したように、判断の前処理を担う人も決めておくべきです。

注文データの合格条件を三層に分ける

以下は特定製品の公式仕様ではありません。AWSが求めるデータソース別の検証基準、PostgreSQL公式文書が促す正しいデータと動作の確認、NISTが確認領域に含める通常運用の復元を、注文業務へ落とした僕の実務提案です。三層の条件と証拠を一枚の承認票に集約します。

三層すべてが合格し、事前に定めたRPO・RTOも満たしたときに、注文業務の復元を合格とします。どれか一つでも未確認なら、「バックアップは戻ったが、注文業務の復元は未確認」です。全部を一つの「成功」とだけ記録すると、注文本体のファイルが存在するだけなのか、関連データまで整合しているのか、現場が操作できるのかが見えなくなります。

復元対象では境界が重要です。注文本体だけを戻しても、決済状態がなければ担当者は処理を続けてよい注文を判定できません。対象外データは業務再開への影響を明記し、訓練目的に照らして承認可否を判断します。

整合確認では、注文の表示だけでなく、明細や顧客との関係、決済や出荷状態の矛盾を見ます。AWSの公式資料は、2026年9月21日時点で、データ型、形式、チェックサム、サイズ、独自の検証ロジック、最新レコード、RPO内かを検証例に挙げています。注文業務の正しさを判定できる方法を選び、抽出確認なら全件の正常を証明したわけではないことも記録します。

業務再開では、復元環境へ入れることと通常業務を進められることを分けます。注文を検索できても、出荷に必要な状態を確認できなければ不合格です。再開とみなす操作は訓練前に業務責任者が決め、RTOと業務操作の完了を確認範囲に含めます。

訓練前の承認票と訓練後の証跡を同じ条件でつなぐ

合格条件は訓練前に作ります。2026年9月21日時点で、NIST SP 800-34 Rev. 1は、明示的なテスト目的と成功基準に照らして評価するテスト計画を作り、日程、参加者、範囲、シナリオ、実施に必要な事項を明確にするよう示しています。結果を見てから基準を決めれば、復元できた範囲を合格と呼ぶだけになりかねません。

注文データの承認票には、少なくとも次を一組で書きます。

• 目的とシナリオ：何が使えない想定で、どの注文業務を再開するのか
• 復元の入力と出力：どの時点のどのバックアップを、どの環境へ復元するのか
• 許容条件：RPOの基準にする時点と、RTOの計測開始・終了をどこに置くのか
• 三層の合格条件：復元対象、整合確認、業務再開を何で判定するのか
• 役割と証拠：技術担当者、業務担当者、最終判定者は誰で、何を記録するのか

実施者、業務担当者、経営者は、各欄で作業と承認を同じ紙面から追えます。「全注文を完全に確認する」のような実行方法のない表現は避け、検証、証拠、確認者を対応させます。

訓練後は承認票へ、条件ごとの合否、実測復旧時間、確認者、証拠、不合格理由、是正措置を追記します。復元、整合確認、業務操作の記録を三層の条件へ対応づけます。同資料は、2026年9月21日時点で、結果をアフターアクションレポートに記録し、是正措置を計画更新のために残すとしています。確認領域はシステム復旧、接続、代替機器の性能、通常運用の復元です。

証跡は成功報告ではなく、未確認事項と次の修正対象を決める材料です。不合格時は是正措置、責任者、再確認条件を承認します。製品変更や追加機能を先に決めず、未達の合格条件から対策を選びます。

承認者も明確にします。技術担当者は復元と技術検証、業務担当者は注文処理の再開確認、経営者は最終判定を担います。外部支援を入れても決裁は社内に残し、CTO代行を入れると、組織の意思決定はどう変わるのかも踏まえて、助言、検証、最終承認を分けます。

次の復元訓練は注文業務の流れを判定できる条件から始める

経営者が求めるべき報告は「バックアップに成功しました」から「事前承認した条件で注文業務の復元に合格しました」への変更です。その条件は、注文本体と関連データを戻す復元対象、注文・明細・顧客・決済や出荷状態の対応を見る整合確認、担当者が検索や出荷などの通常業務を行う業務再開の三層で作ります。

次の訓練を承認する前に、現在の計画へ三つの欄を追加してください。各欄に対象、検証方法、確認者、証拠、合否を書けば、訓練後も同じ物差しで判定できます。記入できない欄がある場合は、製品変更の検討前に、業務責任者と技術担当者で合格の意味を決めます。

保存成功の通知は、復元訓練の入口にすぎません。注文データが存在し、関係が保たれ、担当者が仕事へ戻れることまで一続きの証拠で示したとき、経営者は初めて「復元できるバックアップです」と承認できます。