Autonomous Recovery Service

解決する課題

• Oracle DB の バックアップの設計・実行・保持・検証を自動化 し、運用の手間を減らしたい
• バックアップを Object Storage に置く従来方式より、復旧速度とデータ損失の少なさを高めたい
• 障害や災害が起きても 直近の状態へ素早く戻したい(データ損失をほぼゼロにしたい)
• バックアップ自体を ランサムウェアや誤削除から保護 し、確実に復旧できる状態を保ちたい
• 複数の DB のバックアップ状況を 一元的に可視化・統制 したい

主要概念と用語

• Autonomous Recovery Service: Oracle DB のバックアップと復旧を集中管理するマネージドなデータ保護サービス。オンプレの Zero Data Loss Recovery Appliance(ZDLRA)の技術をクラウドで提供する
• 保護対象データベース(Protected Database): このサービスでバックアップ・保護する Oracle DB。Base Database や Exadata などが対象になる
• 保護ポリシー(Protection Policy): バックアップ保持期間などを定義するポリシー。Oracle 定義の Platinum / Gold / Silver / Bronze と、独自に作るカスタムから選ぶ
• リカバリ・ウィンドウ(Recovery Window): 任意時点へ復旧できる保持期間。短期の下限から数十日規模の上限の範囲で設定する
• リアルタイム保護(Real-time Protection): REDO ログを継続的に転送し、直近の更新まで保護する機能。データ損失(RPO)を限りなく小さくできる
• Recovery Service サブネット: 保護対象 DB とサービス間の通信に使う、専用のプライベートサブネット
• 仮想フルバックアップ(Virtual Full Backup): 増分を取り込みつつ、常に「フルバックアップ相当」を仮想的に保持する方式。復旧時に増分を積み上げる手間がない
• 不変(イミュータブル)保護: バックアップを改ざん・削除できない形で保持し、ランサムウェア被害時も復旧できるようにする考え方

仕様・制限・クォータ

• 保護ポリシーは Platinum / Gold / Silver / Bronze の Oracle 定義から選ぶか、カスタムポリシー で保持期間を指定する
• バックアップの保持期間(リカバリ・ウィンドウ)には 下限と上限 があり、要件に合わせてその範囲で設定する。具体的な日数は変動しうるため、要件確定時に公式ドキュメントで確認する
• リアルタイム保護 を有効にすると REDO を継続転送し、RPO を直近の更新近くまで小さくできる。無効時は定期の自動バックアップが基本動作になる
• 保護対象 DB とサービスの通信には 専用のサブネット(Recovery Service サブネット) が必要
• 対応する DB の種別やリージョン提供状況は拡張されていくため、採用前に対象環境での提供可否を公式ドキュメントで確認する
• 具体的な料金・保持日数・対応バージョンは変動するため、断定せず最新値を確認する

内部の仕組み

Autonomous Recovery Service は、オンプレで実績のある Zero Data Loss Recovery Appliance(ZDLRA)の技術をクラウドのマネージドサービスとして提供 したものです。保護対象の Oracle DB は、最初に1回フルバックアップを取った後は 増分(変更ブロック)だけを継続的に送る 動作になります。

サービス側では受け取った増分を取り込み、常に 「フルバックアップ相当」を仮想的に保持(仮想フルバックアップ) します。これにより、復旧時に古いフルへ多数の増分を順番に適用する従来方式の手間と時間を避けられ、任意時点への復旧を高速に行えます。

さらに リアルタイム保護 を有効にすると、DB は REDO ログを継続的にサービスへ転送 します。これにより、直近のトランザクションまで保護され、データ損失(RPO)を限りなくゼロに近づけられます。バックアップは改ざん・削除されにくい形で保持されるため、ランサムウェアや誤操作の被害時にも整合性のある状態へ戻せます。

設計パターン / ベストプラクティス

• 用途に合う保護ポリシーを選ぶ: 最重要 DB は保持の長いポリシー、検証系は短いポリシーやカスタムで無駄を抑える
• リアルタイム保護を有効化: データ損失を許容できない基幹 DB では REDO 連続転送を有効にし、RPO を最小化する
• 専用サブネットを事前設計: Recovery Service サブネットをネットワーク設計に組み込み、接続要件を満たしておく
• DR と組み合わせる: Data Guard などの待機構成と併用し、バックアップ復旧と切替の両面で備える
• 復旧テストを定期実施: 取得しているだけで安心せず、実際にリストアできるか定期的に検証する
• 既存バックアップ運用の移行先: 手動 RMAN + Object Storage 運用の置き換え先として、運用負荷とデータ損失リスクを下げる目的で採用する

運用・監視

• OCI Console から保護対象 DB のバックアップ状況・保護ポリシー・リカバリ・ウィンドウを一元的に確認する
• 自動バックアップが標準動作で、保持期間内の任意時点への復旧(point-in-time recovery) が行える
• OCI Monitoring / メトリクス や通知と連携し、バックアップの成否や保護状態の逸脱を監視する
• リアルタイム保護を使う場合は REDO 転送が継続しているか を監視し、保護の途切れに気付けるようにする
• 復旧は 任意時点へのリストア を基本とし、定期的に復旧テストを実施して実効性を担保する

コスト

バックアップとして保持するデータ量と、保持期間(リカバリ・ウィンドウ)が課金の中心になります。保持を長くするほど保管コストが増えるため、用途に応じてポリシーを選ぶことが最適化の要点です。

セキュリティ

• バックアップは 暗号化されて保持 され、保管中のデータを保護する
• バックアップを 改ざん・削除されにくい不変な形で保持 し、ランサムウェアや誤操作の被害時も復旧できるようにする
• 通信は 専用の Recovery Service サブネット を介し、プライベート経路で行う
• IAM ポリシー で保護ポリシーや復旧操作の権限を制御し、最小権限で運用する
• バックアップを本番 DB から 論理的に分離 して保持することで、本番が侵害されてもバックアップを守りやすい

関連サービス・比較

最も近い既存手段は、RMAN による Object Storage へのバックアップ運用です。両者を比較します。

ハンズオン / CLI例

# 保護ポリシーの一覧を確認する
oci recovery protection-policy-collection list-protection-policies \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

# 保護対象データベース(Protected Database)を登録する
oci recovery protected-database create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name app-db-protected \
  --db-unique-name APPDB \
  --database-size XS \
  --protection-policy-id ocid1.protectionpolicy.oc1..xxxx \
  --recovery-service-subnets '[{"recoveryServiceSubnetId":"ocid1.recoveryservicesubnet.oc1..xxxx"}]' \
  --password 'Ex4mplePass123'

# 登録済みの保護対象データベースを一覧表示する
oci recovery protected-database-collection list-protected-databases \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

# 特定の保護対象データベースのメトリクス・保護状態を確認する
oci recovery protected-database get \
  --protected-database-id ocid1.protecteddatabase.oc1..xxxx