バックアップRTO/RPO

計算式と考え方

RPO（Recovery Point Objective）は許容できるデータ損失の時間幅で、これがそのままバックアップの取得間隔になります。RPO 1時間なら1時間ごとのバックアップが必要です。RTO（Recovery Time Objective）は許容できる停止時間で、この中にデータの復元時間と復旧作業の時間を収める必要があります。500GBを50MB/秒で復元すると約2.8時間かかり、RTO 4時間なら残り1.2時間しか作業の余裕がありません。障害の切り分け、判断、動作確認の時間を考えると、この余裕はかなり厳しい水準です。

RTO/RPOと必要な方式

バックアップRTO/RPOの詳しい解説

RTOとRPOは事業継続計画の中核となる2つの指標で、それぞれどれだけ止まってよいか、どれだけデータを失ってよいかを定めます。この2つは技術的に決めるものではなく、事業側が損失額と対策コストを比較して決めるべきものです。RTOを短くするほど、RPOをゼロに近づけるほど、必要な設備と運用のコストは急激に上がります。しかも上がり方は連続的ではなく、日次バックアップから増分取得へ、増分取得から同期レプリケーションへと方式が変わる境目で階段状に跳ね上がります。1時間の停止で30万円の損失が出る業務なら、RTOを4時間から1時間に短縮する投資が年間いくらまでなら見合うか、という形で判断することになります。実務でよくある失敗は、目標だけを高く設定して実現手段を検証しないことです。RTO 4時間と定めても、データの復元だけで3時間かかるなら、障害の検知、原因の切り分け、復旧方針の決定、復旧後の動作確認に使える時間は1時間しかありません。現実にはこれらの工程のほうが時間を要することが多く、目標が机上のものになります。復元時間を短縮する手段としては、回線の増強、バックアップの保管場所を近くにする、重要システムだけを先に復旧する段階的復旧の設計、待機系を常時稼働させておくといった選択肢があります。近年はランサムウェアへの備えという観点が加わり、バックアップ自体が暗号化されないよう、書き換えできない形式での保存や、本番環境から切り離した保管、複数世代の保持が求められるようになりました。感染に気づくまで時間がかかる場合、直近のバックアップが既に汚染されていることがあるため、世代をどこまでさかのぼれるかがRPOと別に問われます。またRTOとRPOはシステムごとに設定すべきもので、基幹系と情報系で同じ目標を置くのは非効率です。事業への影響度で分類し、重要度に応じた投資配分を行うのが合理的です。目標を定めた後は、実際に復元する訓練を行って所要時間を実測し、記録を残しておくことで数値の妥当性を検証できます。なお目標値は一度決めて終わりではありません。システムの構成もデータ量も変化し、データが増えれば同じ手段でも復元時間は延びます。年に一度は前提と実測値を突き合わせ、現在の構成で目標を達成できるかを見直す運用が必要です。あわせて、復旧手順書が最新の構成を反映しているか、担当者が不在でも実施できる内容になっているかを確認しておくと、実際の障害時に差が出ます。

業界・現場での使い方

よくある間違い・注意点

• 目標だけ定めて検証しない — 復元時間を実測すると目標を満たせないことがあります。訓練で実時間を測ってください。
• 全システムに同じ目標を置く — 重要度で分類すべきです。一律に高い目標を置くとコストが見合わなくなります。
• 切り分けと判断の時間を見込まない — 復元時間だけでRTOを埋めると、実際の障害対応では間に合いません。

関連する規格・法規

• 業界標準
• ISO/IEC規格

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール