この記事はBryan Grennによる”Autonomous Recovery Service Checklist“の日本語翻訳版記事です。

公開日：2024年3月12日
最終更新日：2025年12月01日

OCI（またはマルチクラウド）上のOracle DatabaseでAutonomous Recovery Serviceを活用することで、Oracleデータベースのバックアップとして最適な方法となります。

Recovery Serviceの設定方法については、ドキュメント[こちら]をご参照ください。
本ブログ記事では、このサービスを正しく導入するためのステップをご紹介します。

まず最初に—お客様がバックアップを構成する際によくある問題が、Autonomous Recovery Service用のネットワークポートの開放です。

Autonomous Recovery Serviceを利用するために、設定が必要なポートは2つあります。

  • 2484 — このポートは、Autonomous Recovery Serviceが利用するRMANカタログへのSQL*Net接続で使用されます。
  • 8005 — このポートは、バックアップデータ自体の転送で使用されます。

これらのセキュリティルールは、Security List（セキュリティリスト）またはNSG（Network Security Group）で設定できます。
OCI上のデータベースをバックアップする際は、Security Listによる設定が最も簡単で推奨されています。
一方、マルチクラウド環境でデータベースをバックアップする場合は、通常NSGが使用されます。

以下、始めるためのチェックリストです。
まずはOCIネイティブデータベース用またはマルチクラウドデータベース用の手順を完了し、その後共通手順に進んでください。

セクション 1 – OCIネイティブデータベース

1.1 データベースバックアップ用セキュリティリストの作成

セキュリティリストは最も簡単に利用でき、リカバリーサービス用サブネットへのトラフィックを制御できます。
セキュリティリストには、宛先ポート8005と2484を許可するステートフルなインバウンド（Ingress）ルールを含める必要があります。

セキュリティリスト内のセキュリティルール チェックリスト

1. ルール1 – インバウンド: Database VCN内からのHTTPSバックアップトラフィックを許可

  • ステートレス：いいえ（すべてのルールはステートフルである必要があります）
  • ソースタイプ：CIDR
  • ソースCIDR：データベースが存在するVCNのCIDR
  • IPプロトコル：TCP
  • ソースポート範囲：すべて
  • 宛先ポート範囲：8005

2. ルール2 – インバウンド: Database VCN内からのSQLNetトラフィックを許可

  • ステートレス：いいえ（すべてのルールはステートフルである必要があります）
  • ソースタイプ：CIDR
  • ソースCIDR：データベースが存在するVCNのCIDR
  • IPプロトコル：TCP
  • ソースポート範囲：すべて
  • 宛先ポート範囲：2484

注意：もしVCNでサブネット間のネットワークトラフィックが制限されており、バックアップ専用のサブネットを使用している場合は、データベースサブネットから作成したRecovery Serviceサブネットへのポート2484および8005のエグレスルール（送信ルール）を追加することを忘れないでください。

以下は、私のVCN構成の例です（この例では CIDR ブロックは 10.1.0.0/16 です）。

注意：この例ではVCN全体のCIDRブロックでセキュリティリストを設定しています。これにより、VCN内の任意のサブネットからバックアップトラフィックが許可されます。もしVCN内の特定のサブネットだけにトラフィックを制限したい場合は、Autonomous Recovery Serviceに登録されたサブネット（デフォルトのバックアップサブネットが含まれることもあります）のみが含まれるようCIDRブロックを絞り込むことも可能です。ただし、今後ほかのサブネットや追加のサブネットを利用する場合は、セキュリティリストを適宜変更する必要があります。

1.2 セキュリティリストをバックアップ用サブネットに割り当てる

Autonomous Recovery Serviceは、利用するデータベースサービスに基づいて、デフォルトのバックアップサブネットを自動的に利用・登録します。

  • Exadata Database Serviceの場合、バックアップサブネットがAutonomous Recovery Service用に使用されます。
  • Base Database Serviceの場合、データベースサブネットもAutonomous Recovery Service用に使用されます。

注意：多くのデータベースをバックアップする場合や、デフォルトのバックアップサブネットのCIDRブロックで利用可能なIP数が少ない場合は、このサービス専用に別のサブネットを作成することを検討してください。この内容については、後半のオプションセクションで説明しています。

以下は、私がBase Database Service用に利用しているネットワーク「dbsubnet」のスクリーンショットです。
セキュリティセクションから、「Recovery Service」と名付けたセキュリティリストをこのサブネットに追加しました。

1.3 Autonomous Recovery ServiceのサブネットからOracle Services Networkへのルートを確保する

デフォルトのRecovery Serviceサブネットのルーティングルールに、Oracle Services Networkへのルートが含まれていることを確認してください。
以下は、私が設定してサブネットに適用したルーティングルールのスクリーンショットです。
事前にService Gatewayを作成しており、このルールに含めています。

セクション 2 – マルチクラウドデータベース

注意：現時点では、AWSをパートナークラウドとして利用する場合、これらの一部の作業はAWS側で自動化されているため、そのステップを省略できます。

  • リカバリーサービス用のNSG（Network Security Group）を作成します。
  • 新しいNSGを適用したRecovery Serviceサブネットを作成します。
  • NSGのルールを設定します。
  • サブスクリプションに必要なIAMポリシーを追加します。

2.1 Recovery Service用のNetwork Security Group（NSG）を構成する

マルチクラウド環境では、VCN作成時に既定のNSGがすでに作成されています。Recovery Service用に新たにNSGを作成するというこの運用を継続するのが最善です。

Network Security GroupはRecovery Serviceサブネットへのトラフィックを制御し、宛先ポート8005および2484を許可するステートフルなインバウンド（Ingress）ルールを含める必要があります。

NSGにおけるセキュリティルールのチェックリスト

1. ルール1 – インバウンド: Database VCN内からのHTTPSバックアップトラフィックを許可

  • ステートレス：いいえ（すべてのルールはステートフルである必要があります）
  • ソースタイプ：CIDR
  • ソースCIDR：データベースが存在するVCNのCIDR
  • IPプロトコル：TCP
  • ソースポート範囲：すべて
  • 宛先ポート範囲：8005

2. ルール2 – インバウンド: Database VCN内からのSQLNetトラフィックを許可

  • ステートレス：いいえ（すべてのルールはステートフルである必要があります）
  • ソースタイプ：CIDR
  • ソースCIDR：データベースが存在するVCNのCIDR
  • IPプロトコル：TCP
  • ソースポート範囲：すべて
  • 宛先ポート範囲：2484

注意：VCNでサブネット間のネットワークトラフィックを制限しており、デフォルトのサブネットを使用していない場合は、データベースサブネットから作成したRecovery Serviceサブネットへのポート2484および8005のエグレスルール（送信ルール）を必ず追加してください。

以下は、私のVCN構成例です（CIDRブロックは10.1.0.0/16となっています）。

注意：この例では、VCN全体のCIDRブロックを対象にNSGを設定しています。これにより、VCN内の全てのサブネットからバックアップトラフィックが許可されます。特定のサブネットだけにトラフィックを制限したい場合は、Autonomous Recovery Serviceに登録したサブネット（デフォルトのバックアップサブネットが含まれる場合もあります）のみが含まれるようにCIDRブロックを絞り込むことができます。ただし、将来的に他のサブネットや追加サブネットに移行する場合は、NSGの設定を都度調整する必要があります。

以下は、Autonomous Recovery Serviceサブネット用に作成したNSG（Network Security Group）です。

2.2 Autonomous Recovery Serviceサブネットの登録

Autonomous Recovery Serviceは、利用しているデータベースサービスに応じてデフォルトのバックアップサブネットを自動的に使用します。

  • Exadata Database Serviceの場合、バックアップサブネットがAutonomous Recovery Service用に利用されます。
  • Base Database Serviceの場合、データベースサブネットがAutonomous Recovery Service用に利用されます。

注意：多くのデータベースをバックアップする場合や、デフォルトのバックアップサブネットに割り当てられているCIDRブロックのIP数が少ない場合は、このサービス専用のサブネットを作成することを検討してください。この内容は後半のオプションセクションで説明しています。

デフォルトのネットワークをバックアップに使用する場合は、このサブネットを登録します。別のサブネットを使用する場合は、Autonomous Recovery Serviceサブネットとして特定したサブネットを登録することになります。

以下は、バックアップサブネットを登録する画面の例です。

2.3 Recovery ServiceサブネットにNSGを登録する

Recovery Serviceサブネットを登録する際には、サブネットだけでなくNSGもあわせて登録することを忘れないでください。
下のスクリーンショットは、私のサブネットに関連付けられたNSGをRecovery Serviceに登録している様子を示しています。

2.4 バックアップの保存場所を決定する

デフォルトでは、マルチクラウド環境で作成されたバックアップは、データベースがホストされているOCIリージョンに保存されます。もしバックアップをOCIに保存する場合は、デフォルトの保護ポリシー（Protection Policies）を使用できます。

一方、Autonomous Recovery Serviceのバックアップをデータベースがホストされている同じクラウドプロバイダーに保存したい場合は、カスタム保護ポリシーを作成する必要があります。

下図はカスタム保護ポリシーの作成例です。画面下部で、バックアップをデータベースと同じクラウドプロバイダーに保存する設定ができることが分かります。この設定を変更してカスタムポリシーを作成してください。バックアップ構成時には、必ずこのカスタムポリシーをデータベースに適用することを確認してください。

セクション 3 – OCIとマルチクラウドデータベース共通の手順

3.1 テナンシのリソース制限が十分であることを確認する（マルチクラウドの場合も含む）

Recovery Serviceを導入する前に、まずデータベースが存在するリージョンのテナンシのリソース設定を確認しましょう。「Space Used for Recovery Window（GB）」と「Protected Database Count」が、利用予定のデータベース数やバックアップサイズに十分対応しているか確認する必要があります。

注意：有償テナンシにはデフォルトで設定されている制限値があります。

  • 保護対象データベース数：10
  • ストレージ容量：10TB

これにより、いくつかの小規模なデータベースでサービスを活用できます。

以下は、Autonomous Recovery Serviceのコンソール画面の例です。これはUS-EAST-1リージョンにおける、私のテナンシでの制限値を示しています。自身のテナンシでも、各リージョンごとに現在の制限値、利用状況、および利用可能なリソースを確認してください。
ルートコンパートメントを参照すると、そのリージョン内のテナンシ全体の制限値と使用状況を見ることができます。

テナンシの制限値を増やす必要がある場合は、増やしたい制限値の右側にある3つの点（メニュー）をクリックしてください。「サポートリクエストを作成（Open Support Request）」という選択肢が表示されます。これを選ぶと、テナンシの制限値引き上げをリクエストする画面が表示されます。

注意：3つの点をクリックした際に表示される2つ目の選択肢「Quota Policy Stubの作成（Create Quota Policy Stub）」を利用することで、特定のコンパートメントのクォータを制限することができます。たとえば「dev」コンパートメントの利用を制限し、本番用に十分なリソース枠を確保する、などの運用が可能です。

マルチクラウド環境での制限値について
マルチクラウド環境でAutonomous Recovery Serviceを構成する場合は、マルチクラウドサブスクリプションのリソース制限値も確認・必要に応じて引き上げ申請を行う必要があります。「Limits, Quotas and Usage」画面で「サブスクリプション（Subscription）」という項目を選ぶことで、マルチクラウドサブスクリプションの制限値も確認・調整できます。

下記に、マルチクラウド環境でサブスクリプションの制限値セクションが表示される場所の例を示します。

3.2 テナンシのポリシーを構成する

リカバリーサービス用のポリシーを追加する際は、ポリシービルダーの使用が推奨されます。これにより、最新かつ適切なポリシーが設定されていることを確認できます。

以下は、その手順を示す画面例です。

ポリシーの追加時、「ポリシー」の項目で「Autonomous Recovery Service」を選択してください。
その後、「共通ポリシーテンプレート（Common Policy Templates）」の中から、ご利用環境に合ったテンプレートを選んでください。

注意：マルチクラウド環境を使用している場合は、パートナークラウドのホスティング環境に適切なポリシーを必ず選択してください。

グループを割り当てた後に、ポリシーを作成してください。

3.3 Autonomous Recovery Serviceがご利用中のデータベースリリースでサポートされていることを確認する

Oracle Database Autonomous Recovery Serviceは、以下のOracle DatabaseリリースでプロビジョニングされたOracle Cloudデータベースのバックアップ先として利用可能です。

Oracle Databaseエディション／バージョン詳細情報
Oracle Database 19c Release 16 (19.16) 以降リアルタイムデータ保護機能を利用する場合は、<br>Oracle Database 19c Release 18 (19.18) 以降でプロビジョニングされている必要があります。
Oracle Database 21c Release 7 (21.7) 以降リアルタイムデータ保護機能を利用する場合は、<br>Oracle Database 21c Release 8 (21.8) 以降でプロビジョニングされている必要があります。
Oracle Database 23aiリアルタイムデータ保護機能を利用する場合は、<br>Oracle Database 23ai Release 4 (23.4) 以降でプロビジョニングされている必要があります。

3.4 COMPATIBLE初期化パラメータが最新であることを確認する

Autonomous Recovery Serviceを利用するには、COMPATIBLEパラメータが19.0.0以上に設定されている必要があります。このパラメータはアップグレード時に自動的に更新されないことが多いため、十分に高い値になっていることを必ず確認してください。

正しく設定されていない場合、以下のようなメッセージが表示されます。

Database job: Failure. DBAAS-10327 : Minimum required COMPATIBLE version is 19.0.0. Current database COMPATIBLE version is: 12.1.0.2.0.

3.5 データベースでTDEが完全に構成されていることを確認する

Autonomous Recovery Serviceを利用するには、データベースがTDE（透過的データ暗号化）で完全に暗号化されている必要があります。クラウド上で新規に作成されたデータベースであれば、基本的にこの要件は満たされています。しかし、OCIでスタブデータベースを作成し、オンプレミスや他環境からOracle Database Serviceにデータベースを移行する場合は、すべての要件を満たしていないことがあります。その場合は、リカバリーサービスへのバックアップのための前提条件を満たしているか事前に確認してください。
何をチェックすべきかをまとめたブログ記事もありますので、よろしければ参考にしてください。

大枠では、以下3つの条件をすべて満たしている必要があります。

  • データベースでWALLET_ROOTが構成されていること。もしまだsqlnet.oraを使用している場合は、下記のツールを使ってRecovery Serviceを利用するすべてのデータベースに対して正しくWALLET_ROOTを設定してください。
    注意：sqlnet.oraでENCRYPTION_WALLET_LOCATIONを設定する方法はサポートされておらず、非推奨となります。 dbaascli tde enableWalletRoot — 既存のデータベースに対して wallet_root のspfileパラメータを有効化します。
<tt>           Usage: dbaascli tde enableWalletRoot --dbname <value> [--dbRestart <value>] [--precheckOnly] 
                     Where:
                          --dbname - Oracle database name.
                          [--dbRestart - database restart option. Valid values : full|rolling ]
                          [ --precheckOnly - run the prerequisite checks and report the results. ]
                          [--resume - to resume the previous operation]

           <big><strong> NOTE: In order for this change to take effect you need to have a restart of the database.
                The default is a rolling bounce of the database.
</strong></big></tt>

  • データベース内のCDBおよびすべてのPDBに対して、暗号化キーが設定されている必要があります。
  • 最初のバックアップを実行する前に、すべての表領域がTDEで暗号化されている必要があります。

3.6 手動で実行している運用バックアップを停止する

OCIユーザーの中には、手動で運用バックアップを実行しているケースがあります。これらはツール以外で実行されるバックアップで、ポイントインタイムリカバリ（非KEEPバックアップ）をサポートしています。
このような運用バックアップを実施している場合は、この段階で必ず停止することが重要です。異なる場所に対して運用バックアップを2重で実行すると、両方のバックアップで問題が発生する可能性があります。

注意：Object Storageへのバックアップ用ツールを使用していて、Recovery Serviceへ切り替える場合は、ツールによって自動で切り替えが行われます。これまでのバックアップも引き続き利用可能です。

3.7 クラウドプロバイダーのDNSエントリが解決できることを確認する

Autonomous Recovery Serviceは各エンドポイントにDNSエントリを使用しています。DNS解決方法をカスタマイズしている場合、クラウドのDNSエントリも正しく解決できないと、Recovery Serviceがバックアップジョブを実行する際にエラーが発生する場合があります。
もしホスト名の解決時にTNSエラーが発生する場合は、DNS構成を確認し、クラウドのDNSエントリが確実に解決できるようになっていることを確認してください。

セクション 4 – オプション

4.1 Autonomous Recovery Service用にサブネットを作成する（オプション）

Autonomous Recovery Serviceは、利用しているデータベースサービスに応じてデフォルトのバックアップサブネットを自動的に利用します。

  • Exadata Databaseサービスの場合、バックアップサブネットがAutonomous Recovery Service用に利用されます。
  • Base Databaseサービスの場合、データベースサブネットがAutonomous Recovery Service用に利用されます。

注意：多数のデータベースをバックアップする場合や、デフォルトのバックアップサブネットで利用可能なIP数が少ない場合は、このサービス専用のサブネットを作成することを検討してください。

Autonomous Recovery Serviceはプライベートエンドポイントを使用して、データベースとリカバリーサービス間のバックアップトラフィックを制御します。下記がそのアーキテクチャ例です。

バックアップ用の専用サブネットを作成する手順

各Recovery Serviceのプライベートサブネットは、データベースが存在するVCN内に作成する必要があります。
注意：パブリックサブネットを使用することもできますが、セキュリティの観点から推奨されません。
推奨されるサブネットサイズは /24（256個のIPアドレス）です。新しくサブネットを作成することも、既存のサブネットをデータベースのVCN内で活用することも可能です。なお、このサブネットはIPv4である必要があります。

以下は、私が作成したRecovery Service専用サブネットのスクリーンショット例です。

補足説明

必要な空きIPアドレスの数や、複数のサブネットが利用できるかについて多くの質問があります。

  • Recovery ServiceにIPアドレスが割り当てられる際は、一度に「チャンク（Chunk）」として割り当てられます。これは、データベースやSCANリスナーで想定される挙動と似ています。現時点では1チャンクは6つのIPアドレスで構成されており、これらのIPは連続している必要もなく、同じサブネット内である必要もありません。なお、この「チャンク」サイズ（IPアドレス数）は今後のリリースで変更される可能性があります。
  • 必要な「チャンク」の数はリカバリーサービスが管理しており、バックアップ先の動的な管理に応じて変化する場合があります。
  • 新しいデータベースを追加する際にのみ、「チャンク」数が増えることがあります。次のチャンク分の空きIPアドレスが不足している場合、新規データベースの追加処理は失敗し、空きIPアドレスを追加するよう通知されます。
  • サブネットを追加することで、Recovery Serviceに追加のIPアドレスを割り当てることができます。複数のサブネットを利用可能であり、サブネットはパブリックルーティング可能である必要はありません。
  • サブネットを削除した場合、そのIPアドレスは他の既存サブネットに移動します。
  • 利用可能なIPアドレス数が限られている場合は、最低でも/27（32個のIPアドレス）CIDRブロックから始めることを推奨します。

バックアップが引き続き失敗する場合は、Recovery Serviceのために必要なポートが正しく開放されているか、Security ListやNSGの設定を再確認してください。リミットチェック等の事前チェックは多数行われますが、ポートの問題はバックアップ構成まで検出されません。

注意：このチェックリストに従って設定したにもかかわらず、Autonomous Recovery Serviceで最初のデータベースのオンボーディングに失敗した場合は、SR（サービスリクエスト）を作成する際に、以下の手順を参照してください。

  1. ご利用中のデータベースサービスに対してSRを作成してください
  • Oracle Cloud Infrastructure – Exadata Cloud Service
    問題のタイプは「Patching issues & Tools → Cloud Tools」を選択
  • Oracle Database Cloud Service
    問題のタイプは「DBCS Tools → Using Cloud Toolset」を選択
  • Autonomous Database Dedicated
    問題のタイプは「Database Administration → Backup and Recovery」を選択
  1. SR作成時には以下の情報を必ず添付してください。
    • コンソールに表示されたWorkrequestエラーのOCID
    • データベースのOCID
    • VMクラスタのOCID
    • エラー画面のスクリーンショット
    • リージョン

クローン作成時の注意点（Cloning Issues）

バックアップを別の環境にクローン（複製）する場合、対象は以下のいずれかとなります。

  • 同じリージョン内の別のVCN
  • 別リージョンのVCN

この場合、Autonomous Recovery Serviceが要求するポートが開放されていることを必ず確認しないと、データベースのリストアができません。

別環境ではAutonomous Recovery Serviceの設定がされていない場合もあるので、リストア時に必要な2484番ポートと5003番ポートの両方が開放されていることを確認してください。OCIバックアップの場合はセキュリティリストに、マルチクラウドの場合はNetwork Security Group（NSG）にこれらのポートを登録します。

バックアップと同様に、リストア時にも「バックアップサブネット」にエンドポイントが作成されて処理が行われます。そのため、バックアップ時に利用するサブネットに対し、必要なセキュリティリストやNSGの設定を行ってください。