1 概要
復旧時点目標は、情報システムやデータが失われた際に、どの時点までさかのぼって情報を復元できればよいかを示す指標である。英語では一般に RPO と呼ばれ、事業継続計画や災害復旧計画の設計で広く用いられる。許容されるデータ損失を時間軸で表すため、運用上の優先順位を決める基準にもなる。
1.1 定義
この指標は、障害発生時点と復元対象となる最新の記録時点との差を意味する。たとえば RPO が 1 時間であれば、最大でも 1 時間分の更新内容の損失を許容する設計となる。金額や件数ではなく、時間で表現する点に特徴がある。
1.2 役割
復旧時点目標は、バックアップの取得間隔、複製の方式、保存先の分散などを決める際の出発点となる。業務への影響を抑えるうえで、どの程度の情報欠損なら受け入れられるかを明確にする役割を持つ。また、復旧時間目標と組み合わせることで、単にデータを戻すだけでなく、いつまでに業務を再開できるかも整理できる。
1.3 関連する指標
最もよく併記されるのは復旧時間目標であり、こちらはシステムや業務を再開するまでの許容時間を示す。前者が「どこまで戻すか」を扱うのに対し、後者は「いつ戻すか」を扱う。両者は似ているが別の概念であり、混同すると対策の設計を誤りやすい。
2 設定の考え方
復旧時点目標は、抽象的に決めるのではなく、実際の業務で失われても支障が少ない情報量を基準に定める必要がある。対象となるシステムの性格、利用頻度、外部連携の有無などによって、適切な値は大きく変わる。一般に重要性が高いほど、より短い目標が求められる。
2.1 業務要件の整理
まず、どの業務が止まると影響が大きいかを整理し、その業務で扱うデータの更新頻度や締切を確認する。単一の数値だけで判断するのではなく、部門ごとの利用実態や例外処理も含めて把握することが重要である。こうした整理により、必要以上に厳しい設定や、逆に不十分な設定を避けやすくなる。
2.1.1 データ損失の許容範囲
許容範囲は、業務上どれだけの再入力や補正作業を受け入れられるかで決まる。たとえば、売上記録、在庫更新、契約情報のように、失われると再作成が難しいデータは、短い目標が必要になる。一方、再収集や再入力が容易な情報では、比較的長い時間を許容できる。
2.1.2 システム重要度の評価
重要度の評価では、停止時の影響度、利用者数、法令や契約上の要請、他システムへの波及を考慮する。中核業務を支える基盤ほど、復元可能な時点を新しく保つ必要がある。評価結果は、対策の優先順位付けや投資判断にも用いられる。
2.2 可用性との関係
可用性は、サービスが利用できる状態を保つ度合いを示す概念であり、復旧時点目標とは焦点が異なる。高い可用性を求める場合、障害が起きてもデータ損失を最小に抑える設計が選ばれやすい。もっとも、可用性が高くても、復旧時点目標が厳密とは限らず、両者は独立した観点として扱う必要がある。
2.3 コストとのバランス
短い復旧時点目標を実現するには、複製機器、通信回線、保存領域、運用要員などへの投資が増えやすい。したがって、最適な値は「損失をどこまで抑えたいか」と「そのためにどれだけ費用をかけられるか」の折り合いで決まる。実務では、業務ごとの優先度に応じて段階的に設定する方法がよく採られる。
3 実現方法
復旧時点目標を満たすには、単一の手段に頼るのではなく、複数の保護策を組み合わせるのが一般的である。バックアップは確実性に優れ、レプリケーションは損失を抑えやすい。さらに、障害発生後の手順が整備されていなければ、理論上の目標を実際に達成できない。
3.1 バックアップ
バックアップは、一定時点のデータを別媒体へ保存し、必要に応じて戻せるようにする基本的な手段である。取得間隔が短いほど最新情報を保ちやすいが、保存容量や処理負荷は増加する。完全な即時性は得にくいものの、広く利用される堅実な方法である。
3.1.1 世代管理
世代管理は、直近の保存だけでなく、複数回分のバックアップを残しておく考え方である。これにより、誤操作や論理破損が後から発見された場合でも、より適切な時点へ戻しやすくなる。必要な保存期間は、業務上の確認期間や監査要件に応じて決められる。
3.1.2 保存間隔の設計
保存間隔は、更新頻度と許容損失から逆算して設計する。更新が頻繁なシステムでは、短い間隔で取得しないと目標を満たしにくい。反対に、変更が少ない環境では、比較的長い間隔でも十分な場合がある。
3.2 レプリケーション
レプリケーションは、データを別の装置や拠点へ複製し、障害時の損失を減らす方法である。バックアップよりも迅速に切り替えられることが多く、サービス継続性の向上に寄与する。構成によっては、ほぼ同時点の状態を保つことも可能である。
3.2.1 同期方式
同期方式では、書き込み完了の条件に複製先への反映を含めるため、データのずれを抑えやすい。復旧時点目標を非常に短く設定したい場合に有効だが、応答時間や通信遅延への影響が大きくなることがある。遠隔地との接続では、運用上の制約も考慮が必要である。
3.2.2 非同期方式
非同期方式では、複製先への反映が後から行われるため、性能面では有利になりやすい。もっとも、障害発生の瞬間によっては未反映分が残るため、一定のデータ損失を見込む必要がある。コストや遅延との兼ね合いで、広く採用されている。
3.3 障害復旧手順
技術的な保護策が整っていても、復旧の手順が曖昧だと目標を達成できない。どのバックアップを使うか、どの順序でサービスを再開するか、どの権限で作業するかを事前に明文化しておく必要がある。手順書は、担当者の交代や組織変更があっても機能するよう、定期的に整備されるべきである。
4 運用と見直し
復旧時点目標は一度決めれば終わりではなく、業務やシステム構成の変化に応じて継続的に見直す必要がある。実際の運用では、設定値と保護策が一致しているか、想定どおりに復元できるかを確認する作業が欠かせない。机上の設計だけでは、現場での実効性は保証されない。
4.1 定期的な検証
定期検証では、実際に復元操作を行い、目標どおりの時点まで戻せるかを確かめる。バックアップ媒体の破損、手順の不備、担当者の習熟不足など、事前には見えにくい問題を発見できる。検証結果は、そのまま次回の設計改善につなげるのが望ましい。
4.2 訓練と監査
訓練は、障害発生時の動きを体験し、実務担当者が手順に慣れるために行う。監査は、設定、記録、実施状況が規程どおりかを確認する仕組みである。両者を組み合わせることで、文書上の整合性だけでなく、実行可能性も高められる。
4.3 変更時の再評価
システム更新、新規業務の追加、クラウド移行、運用体制の改編などがあると、以前の設定が合わなくなることがある。そのため、変更管理の一環として復旧時点目標を再評価することが重要である。更新のたびに影響範囲を見直せば、過不足のない保護水準を維持しやすい。