本文へスキップ
NeoLogic
NeoLogic

毎晩「バックアップ成功」でも戻せない?復旧できる会社が先に決めていること

13時20分に受注システムが止まったら、どこまでのデータを、何時までに戻したいか。3つの比較例で保存方法を選び、実際に戻して試す項目を整理します。担当者が不在でも使える復元確認票付き。

バックアップの保存と、添付資料を含めて業務を復元できることの違い。

バックアップがあっても、復旧できるとは限りません。先に決めるのは、復旧する対象、失ってよいデータの期間、再開までの目標時間です。その条件から取得頻度・保管先・世代・復元手順を選び、実際に戻して試します。

毎晩「バックアップ成功」の通知が届いていても、「今日システムが止まったら、注文書の添付まで戻せるか。何時間で仕事を再開できるか」と聞かれると、答えに詰まるかもしれません。保存処理の完了後も、必要なデータで仕事を再開できるかを確かめる必要があるからです。

IPAのガイドラインも、失ってよいデータの期間(RPO)と再開までの目標時間(RTO)に沿って取得方法を選び、手順を整え、訓練で試すよう求めています。

データ・添付・設定を使う小規模な業務システムを対象にします。目標値や保存間隔は、自社の業務に合わせて決めてください(出典:IPAの復旧対策(PDF))。

13時20分に止まった受注システムを考える

受注システムが止まった日を、仮の時刻で追ってみます(想定例)。すべて2026年9月10日・日本時間です。後の比較表では、この受注業務をB案として扱います。

時刻 何の時点か
12:00 戻す世代に含まれるデータの時点
13:20 システム停止
13:50 復元作業の開始
14:30 データの復元完了
15:10 業務確認を終え、再開を承認する想定

12時から停止までの80分は、バックアップに含まれない更新を調べる期間です。停止から再開承認までの110分は、業務を戻すのにかかった時間として測ります。復元作業の40分だけでは、後者を表せません。

この例では両方の目標を4時間としていますが、受注を補う受付票が別に残り、注文書の添付も使えることが前提です。時間の計算が目標内でも、実際に戻せたかは別に試します。

依頼先とは、まず三つを決めてください。

  • 何を戻すか。受注一覧だけでなく、注文書の添付や登録権限まで含むか。
  • どこまで失えるか。別の受付票から補えるのは何時間分か。
  • いつ、何ができれば再開か。データを戻すだけか、受注登録と添付閲覧までか。

注文が戻っても、添付が戻らない場面を試す

2026年10月26日、注文1件・4,000円のJSONと、対応する注文書1件のテキストを一時フォルダーへ保存し、別のフォルダーへ復元しました。再現教材(Python)の「restore」で試せます。先ほどの1,240件を使う想定試験とは別の、小さな教材です。

戻したもの 確認結果 再開の判断
注文のJSONだけ 1件・4,000円は一致。参照先の注文書がない 添付が必要な業務は再開できない
同じ名前で内容の違う注文書も置く ファイルは存在するが、保存時の内容との照合で不一致 名前と存在だけで復元成功にしない
保存した注文書を戻す 1件・4,000円と添付内容が一致。模型の新規注文も保存・再読込できた この教材の確認範囲では操作可能

照合には保存時に記録したファイル内容の要約値を使いました。実際の対象では、添付の版・関連する受注番号・閲覧権限も確かめます。教材は暗号化・利用権限・外部接続・本番相当量を扱っておらず、実際の復旧時間や目標達成を示すものではありません。冒頭の80分・110分も、引き続き時刻を仮定した計算例です。

失うと困るものを選ぶ

まず「受注を登録して注文書を開く」「請求額を集計する」など、再開したい操作を一つ選びます。その操作に必要なものをたどると、表のデータだけでは足りない箇所が見えてきます。対象が曖昧なままでは、保存容量も復元作業も、依頼先の担当範囲も決められません。

例えば、受注データはデータベース、注文書は別のファイル保管先、画面や通知の設定は管理画面にある構成です。データベースのバックアップだけでは添付や設定が含まれない場合があります。アプリの版、利用権限、証明書や暗号鍵、外部サービスへの接続も、業務再開に必要かを確かめます。NISTの指針でも、復旧に必要な設定・鍵・依存する仕組みが保護の対象です(出典:NISTの復旧指針(PDF))。

台帳には、対象名、保管先、管理者、保存方法、対象外の理由を残します。暗号鍵やパスワードの値そのものは貼らず、安全な保管先と取得権限、承認手順を記載します。古い世代の復号に必要な鍵も使えるか確かめてください。添付とデータで保存時点が違う場合は、両方が矛盾なく利用できる時点と戻し方を決めます。バックアップのほかに、発注時に確かめるセキュリティの範囲は、小さな会社のシステムに必要なセキュリティにまとめています。

二つの目標を決める

何時点まで戻すかと、いつまでに再開するかを分ける

RPO(目標復旧時点)は、障害前のどの時点のデータまで戻すかという目標です。「失ってよい期間」として、停止時点から何時間前までの欠落を許容するかで表します。「4時間分なら別の記録から入力し直せる」と合意するなら、RPOは4時間が候補になります。失ってよいデータの期間は、業務責任者と決めます。

RTO(目標復旧時間)は、決めた利用状態まで復旧する時間の目標です。「担当者が受注を登録できる」など、業務上の完了条件を添えます。配布する記入票では、停止から連絡・判断・環境準備・復元・業務確認を経て再開承認するまでを測ります。契約やサービスごとに測定の起点と終点が異なる場合は、この条件と突き合わせます(出典:IPAの復旧対策(PDF)、NISTの復旧指針(PDF))。

RTOは、業務が耐えられる停止時間の限界そのものとは分けます。締め切り前に、滞留した仕事や再入力を処理する余裕を残して目標を決めます。目標は復旧の実績や保証でもありません。実測して届かなければ、仕組み、担当体制、代替業務、目標のどれを見直すかを判断します(出典:NISTの復旧指針(PDF))。

社内資料と当日取引では、同じ設定にしない

表1は、同じ会社の業務を一律に扱わず、必要なデータと再入力の負担で分ける例です。時刻・期間は経過時間で比較し、夜間や休日も含みます。Aは1日分を作り直せる社内資料、Bは数時間なら受付票で補える受注、Cは当日取引をできるだけ失いたくない受注・在庫の業務と仮定します。

表1 業務から決める復旧目標

比較項目 A:1日分を許容 B:数時間を許容 C:短時間のみ許容
復旧する対象 社内資料・添付・閲覧権限 受注データ・注文書添付・設定・権限 受注・在庫・添付・設定・鍵の利用経路
業務上の前提 最大1日分を作り直せる 直近4時間分は別管理の受付票で再入力できる 直近15分を超える欠落を許容しない
失ってよい期間(RPO) 24時間 4時間 15分
再開までの目標(RTO) 8時間 4時間 1時間
再開の完了条件 資料と添付を閲覧できる 受注登録・添付閲覧ができる 受注登録と在庫更新を矛盾なく行える

Bでも、受付票がシステムと一緒に失われるなら「4時間分は戻せなくても補える」という前提は崩れます。Cでも「確定済みの取引は1件も失えない」なら15分では不足します。短い目標を全業務に広げる前に、再入力の根拠、締め切り、二重処理を防ぐ方法を業務ごとに確かめてください。

保管方法を比較する

取得頻度、過去の版を残す世代管理、別環境への保管、削除・改変を制限する設定は、競合する商品分類ではありません。異なる事故に備える要素として、組み合わせて設計します。IPAのガイドラインに沿って、対象・頻度・遠隔地を含む保管方法・復元手順を整えます。世代管理と物理的な分離も検討します(出典:IPAの復旧対策(PDF))。

表2は表1の目標を満たすために検討する案です。例えばRPO4時間に対して取得候補を2時間間隔とし、処理や転送の遅れを見込む余地を持たせています。指定間隔で動くだけでは足りず、失敗や遅延を含めて、実際に使える最新の復元時点が目標内かを確かめます。

運用担当者へ:三つの目標に合わせた保存・復元案

表2 目標から検討する保存・復元案

比較項目 A:1日分を許容 B:数時間を許容 C:短時間のみ許容
取得方法の候補 12時間ごとに対象一式を取得 2時間ごとに整合した対象一式を取得 日次の基点+5分間隔の変更ログ。添付も対応時点を保護
保管と世代の例 12時間ごとの複数世代を14日保持 2時間ごとの複数世代を7日保持 直近24時間を再生できる基点とログ+日次世代を14日保持
再開に向けた準備 戻す環境と担当者を事前に確保 受付票との照合・再入力手順を用意 待機環境や自動化も検討し、業務全体で時間を測る
復元結果と確認者 結果:未実施・不明。予定:運用担当/資料担当 結果:未実施・不明。予定:運用担当/受注責任者 結果:未実施・不明。予定:運用担当/受注・在庫責任者
条件外・未確認 対象外の添付・権限、実際の所要時間は不明 7日より古い正常世代はこの案では戻せない ログだけでは復元できない。添付との整合性、転送遅延、1時間での再開は未確認

表1・2の共通条件:本番と保管先の管理権限を分け、暗号化や削除・改変への保護を設ける想定です。確認日:2026-09-15。

表1の原則は、IPA同ガイドライン、pp.33・38(PDF)とNIST SP 800-209、4.7〜4.9(PDF)をもとにしています。担当範囲を決めるときは、IPA「情報システム・モデル取引・契約書」第二版の案内を参考にできます。

過去へ戻れる期間と、削除を防ぐ設定も確かめる

同期は、離れた場所の内容をそろえるための仕組みです。誤削除や改変も反映され、以前の状態を別に保持していなければ、同期先から元に戻せません。履歴や削除保護があるサービスでも、対象・保持期間・復元権限を確かめます。「同期しているから十分」でも「同期は不要」でもなく、過去へ戻れる仕組みを別に持つことが判断点です(出典:NISTの復旧指針(PDF))。

保持期間は、誤りに気付くまでの日数と、調査・復元する余裕から決めます。Bの7日保持では、10日前の誤更新に今日気付いても、その直前の世代は残りません。逆に長く保存していても、取り出しに時間がかかればRTOを超えます。会計や契約などの保存義務は、障害復旧用の保持期間とは別に決めます。

誤削除や権限の悪用には、暗号化に加えて操作の制限が必要です。保管先を分けるだけでなく、同じ管理者権限で本番とバックアップを同時に消せないか、変更・削除を制限する保護を解除できる人は誰かを決めておきます。鍵はデータと別に安全に管理し、必要な期間使える状態を保ちます(出典:NISTの復旧指針(p.60)(PDF)、NISTの復旧指針(p.63)(PDF))。

復元して確かめる

復元の試験は、本番とは隔離した環境で行います。通知メール、決済、外部システムへの更新、定期処理を止め、本番へ影響しない条件を先に決めます。検証用データにもアクセス制限を設け、終了後の保管・削除を決めてください。攻撃や改変が疑われる場合は、原因を残した環境へそのまま戻さず、安全性の調査と復元候補の選定を別の作業にします。

復元後は、同じ時点・範囲で取得した照合用記録と、対象件数、重要な金額や数量、添付の対応、主要な操作を比べます。現在の本番件数と過去の復元件数をそのまま比べても、正しさは判断できません。NISTも、復旧データの検証と機能の検証を分けています。件数が一致しても、内容や権限が違えば再開条件を満たしません(出典:NISTの復旧指針(p.55)(PDF)、NISTの復旧指針(p.60)(PDF))。

表3はB案の復元試験に使う記録票です。実際に試した結果を記入する前の見本です。作業開始からの時間だけでなく、停止からの全体時間を記録すると、連絡待ちや承認待ちも見直せます。

復元試験で記入する結果・担当・残る課題

表3 復元試験の記録例

記録項目 説明用の記入内容
対象と条件 B:受注・注文書添付・設定・権限。RPO4時間、RTO4時間。隔離環境で受注登録と添付閲覧まで確認する想定。
停止・復元時点 仮の停止:2026-09-10 13:20。使用する世代のデータ時点:同日12:00。差は80分。時刻はすべて日本時間。
再開までの時刻 仮の復元開始13:50、データ復元完了14:30、業務確認・再開承認15:10。停止から110分。
照合結果の書き方 12:00時点の受注1,240件、指定した重要10件の金額・数量、添付10件の一致と、登録・閲覧の成功を記録する書き方。実際の照合・操作は未実施。
復元結果と確認者 実施状況:未実施。時間条件のみの計算例は目標内。総合判定は未判定。確認者は未定(想定役割:運用担当/受注責任者)。
次に試すこと 全件の添付内容・本番相当のデータ量・外部連携・13:20以降の受付と再入力。実機試験の実施日と担当者を決める。
記入日 2026-09-15。実施日・構成の版・証跡の保存先は試験後に記入。

表3の確かめ方は、NIST SP 800-34 Rev.1、4.4(PDF)とNIST SP 800-209、4.8(PDF)をもとにしています。

80分が4時間以内でも、すべての復元時点で目標を守れる証明にはなりません。取得直前の停止、取得失敗、古い正常世代への戻しも確かめます。本番と検証環境の条件が違えば所要時間は変わります。初回、構成や保存方法の変更時、その後の定期確認を計画し、未確認部分を成功扱いにしないでください。

不在時でも復旧できるようにする

最後に、主担当が不在でも読める場所へ、連絡先、代行者、復元手順、必要な権限の取得方法、最新版の確認票をまとめます。社内メールや認証基盤が止まっても連絡・参照できる手段を用意し、鍵や共通パスワードを資料に貼る引き継ぎは避けます。実施者、業務上の確認者、再開を承認する人は分けて記録します。

外部へ頼むときも「バックアップ込み」で終わらせず、取得、失敗通知、復元の実行、業務照合、再入力の担当を分けます。受付時間、着手までの条件、緊急時の費用、目標時間と保証の有無も聞きます。IPAのモデル契約を対話の参考にしながら、個別サービスの復旧範囲と担当を契約で決めます(出典:IPAの復旧対策(p.40)(PDF)、IPAのモデル契約)。

次の打ち合わせでは、業務を一つ選び、「何を戻すか」「どこまで失えるか」「いつ何ができれば再開か」を記入してください。そのうえで、最後に戻した世代、結果、確かめた人、証跡を見て、不明なら実施日と担当を決めます。成功通知に加えて、この記録までそろっているかを出発点にします。

担当交代に伴う資料や権限の棚卸しは、他社開発システムの保守引き継ぎで調べることで整理しています。新旧システムの切替時の照合・切り戻しを決めたい場合は、日常のバックアップ設計とは分けて、システム移行の切り戻し|新しい注文と訂正の扱いをご覧ください。

継続的な運用相談や小さな改善が必要なら、バックアップや復元の担当範囲、対応時間も含めて相談できます。NeoLogicの月額支援で対応する作業は個別に確認します。常時監視や復旧時間の保証は含みません。

記入済み見本と空欄版は、判断表・復元確認票をダウンロード(Excel)して使えます。要件票で自社の対象と目標を整理し、復元票に試験結果を記録してください。

復旧を外部へ依頼する場合は、連絡できる時間と月額料金に含む作業を合わせて決めます(システムの保守・運用|月額料金と対応範囲の比較)。

月額の保守・運用改善の相談へ

参考出典

あわせて読む