バックアップがあっても復旧できないとき——RTO・RPOと復旧テストの考え方

データが消えたとき、「バックアップがあるから大丈夫」と考えている経営者や担当者は少なくない。しかし実際に障害が起きると、バックアップファイルは存在するのに業務が再開できない、という事態が起こる。保存と復旧は、別の問題だ。

「保存されている」と「戻せる」は違う

バックアップがあることと、復旧できることは同じではない。

バックアップとは、ある時点のデータを別の場所に複製しておく作業だ。一方、復旧とは、そのデータを使って業務システムを動く状態に戻し、実際に業務を再開できるようにすることを指す。この2つの間には、環境の再構築・設定の復元・連携システムの確認・担当者の操作という複数のステップが存在する。

よくある失敗として、次のようなケースがある。

• バックアップは取っていたが復元手順書がなく、手順を知る担当者が退職していた
• クラウドにデータはあったが、復元先の環境がバージョンアップされていて設定が合わなかった
• 復元自体はできたが、周辺システムとの連携が切れており業務に使える状態にならなかった

バックアップはあくまで素材だ。それをどう使うかの設計が、事業継続の実効性を決める。

RTO・RPOという2つの数値を持つ

事業継続の計画を立てるとき、まず定めるべき指標がある。それがRTO（Recovery Time Objective・目標復旧時間）とRPO（Recovery Point Objective・目標復旧時点）だ。

RTOは、障害が発生してから業務を再開するまでに許容できる最大時間を指す。「受注業務は4時間以内に再開する」のように、業務ごとに具体的な時間で設定する。

RPOは、どの時点のデータまで失ってよいかを示す。「最大24時間分のデータ損失を許容する」であれば、1日1回のバックアップで理論上は対応できる。逆に「1時間以内」とするなら、より頻度の高い取得が必要になる。

この2つを定めることで、バックアップの頻度・保存先・復旧手順に求められる水準が決まる。RTO・RPOを定めないままバックアップを取っていても、障害時に何時間以内に再開できるかは誰にも分からない状態のままだ。

RTO・RPOは「どこまで許容するか」という経営判断であり、ITだけで決められる問題ではない。業務ごとに優先順位をつけることが出発点になる。

復旧テストが「備え」を本物にする

復旧テストとは、実際にバックアップから環境を復元し、業務が再開できる状態になるかをRTO以内に達成できるかを確認する作業だ。多くの組織でバックアップは取られていても、復旧テストは一度も行われていないケースは珍しくない。

復旧テストが持つ実務的な意味は3つある。

1. 手順書の実効性を確認する——文書化された手順が実際の環境で通用するかを検証する
2. 環境変化への対応を確認する——OSやソフトウェアのバージョンアップで手順が変わっていないかを確かめる
3. 担当者の習熟を確認する——障害時は時間的プレッシャーがかかる。手順を把握した担当者がいるかどうかが復旧速度を左右する

テストの実施タイミングとして目安になるのは、年1回以上の定期実施、システムの大きな変更・移行後、担当者の異動・退職後の3つだ。

システムを外部ベンダーに委ねている場合は、復旧テストの実施主体・費用負担・結果の共有方法を発注時点で合意しておく必要がある。発注側が握り続けるべき決定事項のひとつとして、復旧テストの確認権限を自社に残しておくことが重要だ。

また、復旧後に業務をどれだけ早く正常化できるかは、日常的な業務データの整備状況にも左右される。業務データが記録として整っているかどうかは、システムが戻った後の実務の立ち上がりに直結する。

バックアップの仕組みがあっても、RTO・RPOが未定義で復旧テストを一度も実施したことがないなら、それは「備えのつもり」に過ぎない。復旧できることを定期的に確かめることが、バックアップと同じかそれ以上に重要だ。どこから手をつけるか迷う場合は、DX伴走支援として現状の棚卸しから一緒に整えることができる。