リカバリ処理の完全ガイド:RTO/RPOを軸にしたバックアップ戦略と運用ベストプラクティス
リカバリ処理とは
リカバリ処理(リカバリー処理)とは、システム障害、データ破損、誤操作、災害、ランサムウェア等によって損なわれた情報やサービスを、所定の正常な状態に戻すための一連の技術的・運用的プロセスを指します。単なる「バックアップからの復元」だけでなく、原因の特定、復旧手順の実行、整合性確認、サービス再開、再発防止策の実施までを含む広義の概念です。
リカバリの目的と評価指標(RTO / RPO)
目的:ビジネスの継続性を確保し、ダウンタイムやデータ損失を許容範囲内に抑えること。利用者や取引先への影響を最小化することが最優先です。
RTO(Recovery Time Objective):障害発生からサービス復旧までの許容最大時間。例えばRTOが1時間であれば、1時間以内にサービスを復旧させる体制と手順が必要になります。
RPO(Recovery Point Objective):復旧時に許容できるデータ損失の最大量(時間)。RPOが15分であれば、最悪でも直近15分分のデータは失われてよい範囲と定義されます。
バックアップとリカバリ手法の基本
バックアップの種類:フルバックアップ(システム全体のコピー)、差分バックアップ(最後のフル以降の差分)、増分バックアップ(最後のバックアップ以降の変更のみ)。それぞれ復旧時間やストレージ効率が異なります。
スナップショット:ストレージやファイルシステムの瞬時イメージ。高速に取得できる反面、同一ボリューム上の障害や誤削除からは保護しないことがあります(スナップショットの保管先と保持ポリシーが重要)。
永続化ストレージとレプリケーション:RAIDやレプリケーション(同期/非同期)で可用性を高める。レプリケーションは物理障害やホスト故障に強いが、論理的ミスやランサムウェアは透過的に複製され得る点に注意が必要です。
スナップショットとバックアップの使い分け:スナップショットは短期間での高速リカバリ向け、バックアップ/アーカイブは長期保存・隔離(オフライン/オフサイト)向けが一般的です。
データベースにおけるリカバリの特徴
データベースはトランザクション整合性を保つ必要があるため、専用のリカバリ手法が発達しています。主な技術要素は以下の通りです。
WAL(Write-Ahead Logging)/トランザクションログ:変更内容を順次記録することで、障害時に未確定の処理を巻き戻し、確定した処理を再実行(リドゥ)できます。PostgreSQLのアーカイブ機能やOracleのREDOログが代表例です。
ベースバックアップ+ログアーカイブ:ベースバックアップ(フル)とその後のログを組み合わせることで、任意の時点への復旧(ポイントインタイムリカバリ:PITR)が可能になります。
ホットバックアップ/コールドバックアップ:ホットは稼働中のバックアップで整合性確保が必須、コールドは停止してからのバックアップで整合性は容易ですが停止時間が発生します。
分散データベースと整合性:分散環境では分散トランザクション、2フェーズコミット、最終的整合性モデルなどがあり、リカバリ手順は単一ノードとは異なります。
障害別のリカバリ戦略
物理障害(ディスク故障、サーバーダウン):RAIDや冗長化、ホットスタンバイによる即時フェイルオーバー、ブート可能なリカバリ媒体の準備が基本。ストレージ故障はRAIDリビルドやブロックレベルでの復旧が必要になることがあります。
論理障害(データの誤削除、アプリケーション不整合):論理障害はバックアップからの復元やトランザクションログの遡及(PITR)が有効。誤操作に備えたアクセス制御と操作ログの保持も重要です。
ランサムウェア・マルウェア感染:暗号化されたデータを復旧するためには、イミュータブル(改竄不可)なバックアップ、オフライン/オフサイトのコピー、バージョニング、検知後の隔離が鍵。単純にスナップショットやレプリケーションだけでは被害が広がる危険があります。
大規模災害(サイト喪失):DR(ディザスタリカバリ)計画、遠隔地へのレプリケーション、クラウドのクロスリージョン冗長、フェイルオーバーテストが必須です。RTO/RPOの要件に応じたアーキテクチャ設計が必要です。
運用面でのベストプラクティス
定期的なリカバリテスト:バックアップの整合性検証、実際の復旧訓練(テーブル単位、システム全体まで段階的に)を行い、実運用での所要時間と問題点を把握します。
ドキュメントとランブック(Runbook)の整備:手順書、連絡先、コマンド、チェックポイントを明確にし、誰でも実行できる状態にしておきます。非常時に混乱しないための事前準備が効果を発揮します。
自動化とオーケストレーション:AnsibleやTerraform、クラウドのリカバリサービスを活用して再現性のある復旧を実現。手作業はミスを招きやすいため、特に時間制約が厳しいRTO環境では自動化が有効です。
モニタリングとアラート:バックアップの成功/失敗、ストレージ使用量、ログアーカイブ遅延などを監視して早期検知と対応を行います。
適切な保持ポリシーとデータ分類:業務重要度に応じた保持期間と保存場所、暗号化やアクセス制御を定義し、法令・コンプライアンス要件も満たす必要があります。
クラウド時代のリカバリ
クラウドではスナップショット、オブジェクト版管理(バージョニング)、マルチAZ/リージョンのレプリケーション、マネージドバックアップサービス(例:AWS Backup、Azure Backup)などの機能が提供され、短時間での復旧やリソースの迅速な再構築が可能です。一方で、設定ミスや誤設定による露呈、コスト管理、運用フローの増加に注意が必要です。
セキュリティと法的考慮点
暗号化と鍵管理:バックアップデータの暗号化、鍵の分離管理により、盗難や漏洩時のリスクを低減します。
イミュータブルバックアップとアーカイブ:改竄防止のために削除や変更ができない形で保存する技術(WORMやオブジェクトストレージのイミュータブル設定)を検討します。
法的/コンプライアンス:データ保持期間、個人情報保護、監査要件に基づいた保存・削除ポリシーを整備します。
まとめ
リカバリ処理は単なる「ファイルを戻す」操作ではなく、ビジネス要件(RTO/RPO)に基づいた設計、適切なバックアップ戦略、整合性確保、運用手順、テスト、セキュリティ対策を包含する総合的な活動です。クラウドやコンテナネイティブなど新しい技術が登場しても、基本は同じ—「事前準備」「定期的な検証」「自動化」「最悪時の対応手順の明文化」が成功の鍵となります。
参考文献
- Backup — Wikipedia
- Data recovery — Wikipedia
- Recovery time objective — Wikipedia
- Recovery point objective — Wikipedia
- PostgreSQL: Continuous Archiving and Point-in-Time Recovery
- AWS Backup — Amazon Web Services
- Amazon EBS スナップショット — AWS ドキュメント
- NIST Special Publication 800-34 Rev.1: Contingency Planning Guide for Federal Information Systems
- Oracle Database Backup and Recovery Documentation


