障害に備えるデータのバックアップと復元
「バックアップ成功」という通知は、処理が完了したことを示します。ただし、それだけで障害後に業務を再開できるとは限りません。添付ファイルが足りない、現在のソフトウェアでは使えない、保管先のアカウントに担当者がアクセスできない、といった問題が残る可能性があります。
バックアップとあわせて、戻すデータ、使うコピー、実施する人、運用再開前の確認方法を決めておく必要があります。この記事では架空の受注管理システムを例に、開発・運用の担当者と合意しておきたい点を説明します。
1. バックアップするデータと構成を確認する
まず、障害後に再開する必要がある業務を確認します。受注管理なら、注文を開き、購入内容や関連資料、支払状況を確認できることが必要です。注文一覧だけ戻せても、必要な書類を開けなければ、業務は止まったままかもしれません。
技術担当者と一緒に、データベース、ファイルの保管先、接続設定、対応するソフトウェアの版など、稼働に必要なものを整理します。認証情報や復号鍵も、権限のある人が必要なときに使えるよう管理します。すべてを同じ方法で保存する必要はありませんが、それぞれをどう戻すかは明確にしておきます。
バックアップとデータ同期は区別して考えます。誤って削除したファイルの状態が別の保存先にも同期されると、そこから戻せない場合があります。予備のシステムが動いていても、誤った変更の前へ戻せるとは限りません。今の構成がどのような障害に対応でき、以前の版を残せるのかを確認しましょう。
2. 戻すデータの時点と復旧までの時間を決める
企業側で考えるのは、直近の更新がどの期間まで失われても許容できるか、そしてシステムをいつまでに再び使えるようにするか、という二つの問いです。前者は残すべきデータ、後者はサービス停止の時間に関わります。この目標をもとに、技術側が保存・復旧の方法を検討します。
技術資料では、どの時点のデータまで戻すかという目標をRPO（目標復旧時点）と呼びます。例えば、使える最新のバックアップが午前0時のもので、午後3時に障害が起きたとします。そのコピーには午前0時以降の注文が含まれません。ほかの復旧元がなければ、不足分を照合して再登録する必要があります。これはデータの欠落を説明する例であり、どのシステムでも許容してよい損失ではありません。
利用可能な状態に戻すまでの時間の目標がRTO（目標復旧時間）です。どのシステム、どのサービスをその時間内に使えるようにするのかを明確にします。データをコピーし終えただけでは復旧完了とはいえません。環境の構築、関連サービスとの再接続、データの確認などを済ませてから、注文処理を再開する場合もあります。
目標は業務への影響から決めます。継続的に注文を受けるシステムと、元データから作り直せる帳票では、必要な対策が異なります。より新しいデータを残したり、より短時間で復旧したりするには、費用や運用方法が変わる場合があります。「毎日バックアップする」だけで済ませず、導入先と具体的に話し合いましょう。
復旧能力は、障害後の業務を支えるために、機能とあわせて決めておくべき要件です。こうした運用上の要件全体を整理する際は、次の記事も参考になります。
3. バックアップを保護し、復元する担当者を決める
本番環境に問題が起きても、バックアップを使える状態にしておく必要があります。本番データとコピーが同じ場所にあり、一つのアカウントで両方を削除できると、保存先の故障やアカウントの侵害で同時に影響を受けるおそれがあります。リスクに応じて、別の保管先や一定期間変更できないコピーなど、適切な保護方法を技術側で検討します。
コピーにも顧客情報や書類が含まれるため、閲覧、取得、削除できる人を制限します。暗号化する場合は、復号鍵を安全に管理し、復旧時に使えるようにします。これは権限管理やデータ保護の方針とあわせて決める内容です。
復旧を始める判断、作業の実施、業務再開の確認を誰が担うかも計画に記載します。技術担当者はアプリの稼働を確認し、業務担当者は注文、添付資料、支払状況などを確認します。どちらか一方だけで、両方の確認を済ませたことにはできません。
担当者には、連絡先の登録だけでなく、手順と必要なアクセス権が必要です。運用担当の交代や契約終了時には、次の担当者が復元を実施できるよう、コピーの取得権限、必要なツール、支援の受け方も引き継ぎます。
4. 復元を試し、業務を再開できるか確認する
確認するには、誤削除や本番の保存先が使えない場合など、一つの状況を決めて復元を試します。使うコピー、復元先、参加者、確認する結果を事前に合意します。本番データを上書きしないよう、適切な環境と対策を用意することが前提です。
運用担当者が手順書に沿って実施し、不足している手順を見つけます。開始時刻、権限や支援を待った時間、アプリの起動、業務担当者の確認まで記録します。データのコピー時間だけでは、利用を再開するまでの作業全体を把握できません。
次に、代表的な注文で、内容と添付ファイルを開けるか、関連データが一致するか、次の処理へ進めるかを確認します。午前0時の状態までしか戻せないなら、利用を認められた照合元から、その後の注文を特定します。再登録では、注文や入金を二重に記録しない方法も必要です。
結果には、試した範囲、所要時間、戻せたデータの時点、残った制約を記載します。鍵や手順の不足、データ確認に時間がかかる点があれば、修正担当を決めて再確認します。試験環境で一度戻せたからといって、あらゆる障害への準備が整ったとは限りません。
試行後は、バックアップの監視、失敗通知への対応、復元の再確認を運用計画に組み込みます。ファイルの保管先、データ構造、利用サービスが変わったら、復旧方法も見直します。外部委託の場合は、支援に含まれる作業と企業側に残る責任を明確にします。
成功通知を受け取るだけで復元を試したことがない場合は、範囲を決めた確認から始めましょう。現在のシステム、重要な業務、バックアップの方法をもとに、復旧計画で不足している点をFenixと一緒に整理できます。
