何時間で戻し、どこまで戻す？復旧目標を業務から決める

RTOとRPOで考える、再開まで待てる時間と戻せなくなる更新の範囲。二つを別々の問いにする。

二つの目標を、別の時計で考える

AWSの復旧目標の資料は、RTOをサービス復旧まで許容する時間、RPOを復旧するデータと障害直前のデータの間で許容する差として説明しています。SONAEは、兼任のIT担当が業務責任者へ相談する際、「いつまでに再開したいか」と「どの時点までの記録が必要か」を分けて聞く方法を提案します。バックアップを取る間隔と、仕事を戻す時間を同じ数字にしません。用語を覚える前に、止まる仕事と困る場面を言葉にしましょう。

架空の受注業務で、時刻を並べる

図の例では、正午に業務が止まると想定し、十六時までの再開を目標にします。これはRTO四時間の架空例です。データは十一時以降の更新をどこまで許容できるかを検討し、一時間前まで戻せる目標をRPO一時間とします。この数字は一般的な推奨でも、SONAEの達成実績でもありません。どちらか一方を満たしても、もう一方が足りないことがあります。更新の頻度、顧客との約束、確認する作業を業務責任者と照合しましょう。

止まったときに、どの仕事が困るかを聞く

受注、出荷、請求など、業務の締め切りと止まる影響を並べます。すべてを最短で戻すという希望だけでは、優先順位も費用も判断できません。架空の受注では、当日の発送へ必要な情報と、翌日までにそろえればよい集計を分けます。法令や契約による条件が関わる場合は、適切な担当が確認します。本記事の例でその条件を満たすと判断しません。重要な仕事を支える認証、通信、端末、担当者が使えることも前提として挙げます。

失われる更新を、どう補うかも決める

過去の時点へ戻した後、受け付けた注文や変更を補う必要があるかを確認します。連絡の控え、別の承認された記録、相手との照合など、自社で使える方法を検討します。バックアップの間隔が短いことだけで、すべての最新データが正しく戻る保証にはなりません。復旧後に重複や欠落を確かめる担当を決めます。許容できない情報があるなら、その理由を責任者へ伝え、仕組みと費用、代替の作業を含めて目標を見直しましょう。

目標と、実際に測った結果を分けて残す

復元試験を計画する場合、対象、復元先、開始と終了の条件、内容を確認する担当を決めます。ファイルが戻る時刻と、社員が必要な仕事を再開できる時刻は違う場合があります。架空データの演習でも、取り込み、設定、認証、内容の照合を含めて何を測るかを明確にします。設計上の見積もりを実測の達成値として記載しません。このサイトで示す時刻は説明用の目標であり、顧客環境で復旧を測定した記録ではありません。

合意した目標を、変更のときに見直す

対象の業務、停止の影響、RTOとRPO、前提、確認者、残る不足を一つの表にします。費用や契約の条件も実際の候補で確認します。完了の目安は、業務側とIT側が二つの目標を区別し、満たすための準備と未検証を説明できることです。新しいサービスや締め切りが増えた場合は、以前の数字を自動で流用しません。バックアップの有無だけではなく、仕事を再開する条件として管理することで、次の試験と改善へつなげましょう。

相談前の確認表

• 再開時間とデータの差を分けた
• 業務責任者が目標の理由を確認する
• 復旧後の欠落や重複を補う担当がある
• 目標・見積もり・実測を区別した

参考資料（確認日：2026年10月23日）：AWS Whitepaper：Recovery objectives ↗

一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。