11 クラウドへのバックアップのアーカイブ

archive-to-cloud用のこのプロシージャは、copy-to-tapeに使用される手法に基づいて構築されています。違いは、長期保存のためにクラウド・リポジトリにバックアップを送信する点です。

このプロシージャには、TDEマスター・キーを格納するための資格証明ウォレットの構成ステップが含まれます。これは、クラウド・リポジトリにアーカイブされる前にバックアップが暗号化されるためです。初期構成タスクは、ウォレットを準備するためにOracle Key Vaultで実行されます。RACLIコマンドは、archive-to-cloud用のリカバリ・アプライアンスの構成とウォレットの使用を支援するために開発されました。最後に、ジョブ・テンプレートが作成され、archive-to-cloudに対して実行されます。

バックアップ・ピースのグループ化

copy-to-tapeおよびarchive-to-cloudのパフォーマンスは、保護されたデータベースのリアルタイムREDOからより少ない数のバックアップ・セットにアーカイブ・ログをグループ化することで向上します。

保護されたデータベースは、リカバリ・アプライアンスへのリアルタイムREDOトランスポートを有効にすることで、リアルタイム保護を実現できます。アプライアンスで受信した各REDOログは圧縮され、個々のアーカイブ・ログ・バックアップとして記憶域の場所に書き込まれます。これらのログ・バックアップをテープまたはクラウドにアーカイブして、長期保存のニーズに応じてアーカイブされる全体バックアップおよび増分バックアップをサポートできます。

• テープへ: Oracle Secure Backup (OSB)モジュールまたはリカバリ・アプライアンスにインストールされているサードパーティのバックアップ・ソフトウェア・モジュールを使用します。

• クラウドへ: クラウド・バックアップSBTモジュールを使用します。

copy-to-tape操作中に、各バックアップ・ピースの書込み間でジョブ間待機時間が発生する可能性があります。バックアップ・ピースの数が多い場合、この一時停止はテープ・ドライブが使用できない時間の大部分を占めます。これは、5個の10GBピースが50個の1GBピースよりも速くテープに格納されることを意味します。

リカバリ・アプライアンスでは、アーカイブ・ログのバックアップ・ピースをグループ化して単一のバックアップ・ピースとしてコピーすることで、ジョブ間待機時間に対処します。したがって、テープ記憶域上のバックアップ・ピースが以前のリリースよりも大きくなります。この機能は、デフォルトでは有効化されています。DMBS_RA CONFIGには、テープにコピーされるバックアップ・ピース当たりの最大アーカイブ・ログを設定するためのパラメータgroup_log_max_countがあります。デフォルトは1です。group_log_backup_size_gbパラメータは、これらの大きなバックアップ・ピースのサイズを制限するために使用されます。デフォルトは256GBです。

archive-to-cloudの前提条件

クラウド・ストレージをリカバリ・アプライアンスで使用する前に、次の前提条件を満たす必要があります。

• 保護されたデータベースがすでに登録され、バックアップがリカバリ・アプライアンスに送信されていること。

  これは、「保護されたデータベース・アクセスのためのリカバリ・アプライアンスの構成」で説明します。概要の確認:

  • 仮想プライベート・カタログ・ユーザーを作成します。
  • 保護されたデータベースを登録します。
  • 保護されたデータベースについてプロパティを更新します。

• リカバリ・アプライアンスが登録済で、Oracle Key Vaultに登録されていること。

• archive-to-cloudの機能は、スモール・エンディアン・データベースでのみサポートされています。LinuxおよびWindowsのみ。

  archive-to-cloudを試みたビッグ・エンディアン・データベースでは、「ビッグ・エンディアン・プラットフォームでは暗号化バックアップを作成できません」というORA-64800エラーが発生します。これは、ビッグ・エンディアン・プラットフォームの場合はこの操作で暗号化バックアップを作成できないためです。

archive-to-cloudストレージのフロー

クラウド・ストレージにアーカイブされたすべてのバックアップ・オブジェクトが、ランダム・データ暗号化キー(DEK)を使用して暗号化されます。保護された各データベース用の透過的データ暗号化(TDE)マスター・キーが、DEKの暗号化に使用されます。暗号化されたDEKはバックアップ・ピースに格納されます。Oracle Key Vault (OKV)にはTDEマスター・キーが含まれ、テープまたはクラウドに書き込まれたバックアップを暗号化するために使用される個々のDEKは含まれていません。保護されたデータベースは、時間とともに多くのTDEマスター・キーを取得する可能性があるため、個々のアーカイブ・オブジェクトを復元するには、バックアップ時に保護されたデータベースのマスター・キーを使用する必要があります。

次の図は、クラウド・ストレージにアーカイブするリカバリ・アプライアンスにバックアップするフローを示しています。リストア操作は、このバックアップおよびアーカイブ・フローに基づいています。

図11-1 クラウド・ストレージへのバックアップのフロー

「図11-1 クラウド・ストレージへのバックアップのフロー」の説明

1. データベースの増分バックアップは、リカバリ・アプライアンスに対して定期的に実行されます。これは、次のアーカイブ操作とは異なる間隔で発生します。

2. スケジュールされたarchive-to-cloud操作が開始すると、リカバリ・アプライアンスは保護されたデータベースのマスター・キーをOKVサーバーに要求します。

3. OKVは、保護されたデータベースのマスター・キーを返します。保護されたデータベースにマスター・キーがない場合は、新しいマスター・キーが生成されます。(新しいマスター・キーは必要なときに生成できます。)

   1. バックアップ・オブジェクトに対してDEKが生成されます。

   2. バックアップ・オブジェクトは、DEKを使用して暗号化されます。

   3. マスター・キーを使用して、リカバリ・アプライアンスはDEKを暗号化し、これをバックアップ・オブジェクトとともに格納します。

4. 特定のデータベースのライフサイクル・ポリシーは、そのバックアップ・オブジェクトがテープまたはクラウド・ストレージに書き込まれるかどうかと、いつ書き込まれるかを決定します。

5. オブジェクト・ストレージ・バケットのライフサイクル・ポリシーは、クラウド・ストレージ内のバックアップ・オブジェクトがオブジェクト・ストレージからアーカイブ・ストレージに移動するかどうかと、いつ移動するかを決定します。リカバリ・アプライアンスは、これを制御しません。

Oracle Key Vaultとリカバリ・アプライアンス

Oracle Key Vault (OKV)はTDEマスター・キーを格納し、格納されたすべてのエンドポイントの追跡も実行します。

エンドポイントは、暗号化や復号化などの実際の暗号化操作が実行されるデータベース・サーバー、アプリケーション・サーバーおよびコンピュータ・システムです。エンドポイントが、セキュリティ・オブジェクトを格納および取得するようOKVに要求します。

Oracle Key Vault (OKV)構成の簡単な概要は次のとおりです。

• リカバリ・アプライアンスのすべての計算ノードが登録され、OKVエンドポイントとして登録されます。

• 単一のOKVエンドポイント・グループに、リカバリ・アプライアンスのすべての計算ノードに対応するすべてのエンドポイントが含まれます。

• リカバリ・アプライアンスのすべての計算ノードに対応するすべてのエンドポイントに対して、単一のウォレットがデフォルト・ウォレットとして共有および構成されます。

• OKVエンドポイント・グループは、共有仮想ウォレットへの読取り/書込み/管理アクセス権で構成されます。

• 複数のリカバリ・アプライアンスが関与している場合、各リカバリ・アプライアンスに独自のエンド・ポイント・グループおよびウォレットがあります。

• 各エンドポイントの登録プロセス中に、各ノードのステージング・パスにホスト固有のokvclient.jarが作成および保存されます。rootユーザーが操作を実行している場合、/radumpはステージング・パスです。指定されたユーザー(raadminなど)が操作を実行している場合、ステージングは/tmpにある必要があります。ステージング済ファイルには、現状のままのokvclient.jarまたは<myHost>-okvclient.jarのいずれかの名前を付ける必要があります。ここで<myHost>は、hostnameが返す内容と一致します。

ノート:

詳細は、Oracle Key Vault管理者ガイドを参照してください。

• Oracle Key Vaultの概念の概要
• Oracle Key Vaultエンドポイントの管理

レビュー: Oracle Key Vault

この参照項では、Oracle Key Vault管理者ガイド (OKV)に記載された概念を使用しています。

OKV管理者は次に示したタスクを実行します。これらのタスクがリカバリ・アプライアンス管理者が実行する操作の前提条件です。OKV管理者は、OKVエンドポイントを構成します。

エンドポイントの作成

エンドポイントを作成するための次の操作は、Key Vault Server Webコンソールから実行されます。

1. Oracle Key Vault Serverにログインします。
2. 「エンドポイント」タブをクリックします。
3. エンドポイント・ページの右側にある「追加」ボタンをクリックします。
4. エンドポイントが関連付けられるリカバリ・アプライアンスのノードに固有の情報を入力します。(名前/タイプ/プラットフォーム/説明/電子メール)
   
   図okv_01_endpoints.jpgの説明
5. 右側の「登録」ボタンをクリックします。
6. 前述のステップを繰り返して、すべてのリカバリ・アプライアンス・ノードのエンドポイントを作成します。

エンドポイント・グループの作成

エンドポイント・グループを作成するための次の操作は、Key Vault Server Webコンソールから実行されます。

1. 「エンドポイント」タブをクリックします。
2. 左側のエンドポイント・グループオプションをクリックします。
   
   図okv_11_endpoitngroup.jpgの説明
3. 右上のエンドポイント・グループの作成ボタンをクリックします。
4. 名前と説明を入力し、前の操作で作成されたすべてのエンドポイントを選択します。
5. 右側の「保存」ボタンをクリックします。

ウォレットの作成

ウォレットを作成するための次の操作は、Key Vault Server Webコンソールから実行されます。

1. キーとウォレットタブをクリックします。
   
   図okv_21_keywallet.jpgの説明
2. 右上にある「作成」ボタンをクリックします。
3. 最初のノード/エンドポイントに固有の名前と説明を入力します。
4. 右側の「保存」ボタンをクリックします。

デフォルトのウォレットとエンドポイントの関連付け

仮想ウォレットとエンドポイントを関連付けるための次の操作は、Key Vault Server Webコンソールから実行されます。

1. 「エンドポイント」タブをクリックします。
   
   図okv_03_endpoitns.jpgの説明
2. ウォレットと関連付けられているエンドポイントの特定の名前をクリックします。
   
   図okv_24_endpointchoosewallet.jpgの説明
3. デフォルト・ウォレットセクションで、ウォレットの選択ボタンをクリックします。
4. 上で作成したウォレットの名前をクリックし、「選択」をクリックしてエンドポイントを割り当てます。
5. 右側の「保存」ボタンをクリックします。
6. 他のエンドポイントに対してウォレットの割当てを繰り返します。同じウォレットがそれらのエンドポイントに割り当てられます。

登録トークンの取得

登録トークンを取得するための次の操作は、Key Vault Server Webコンソールから実行されます。

1. 「エンドポイント」タブをクリックします。

   ページに、各エンドポイント/ノードに固有の登録トークンが表示されるようになります。

   
   図okv_03_endpoitns.jpgの説明
2. 各エンドポイントに固有の登録トークンを(ファイル内に)コピーして保持します。これは、後の登録ステップで使用されるためです。
3. Webインタフェースからログアウトします。このステップは、他のステップで更新された情報を表示するために必要です。

OKVクライアント・ソフトウェアのダウンロード

OKVクライアント・ソフトウェアをダウンロードするための次の操作は、Key Vault Server Webコンソールから実行されます。

次のステップは、リカバリ・アプライアンスの各ノードに対して繰り返されます。次のステップでは、リカバリ・アプライアンス・ノードに固有のJARファイルをダウンロードします。

図okv_04_login.jpgの説明

1. 管理コンソールのエンドポイント登録とソフトウェア・ダウンロードリンクをクリックします。このリンクは、ログイン・セクションの下にあります。
2. 前のステップから保存された登録トークンを使用して、登録トークンフィールドに貼り付けます。
3. トークンの発行ボタンをクリックします。
   入力されたエンドポイント情報が表示されます。
   図okv_06_enrollment.jpgの説明
4. 右上にある「登録」をクリックします。進捗バーに、「処理中」というテキストが表示されます。
   要求が処理されると、ソフトウェア・ダウンロード・ウィンドウが表示されます。
5. okvclient.jarの名前は、ホスト固有の方法で再指定し、ローカルに保存し、各リカバリ・アプライアンス・ノードの/radumpディレクトリにコピーする必要があります。

   /radumpのステージング済ファイルには、次のいずれかの名前を付ける必要があります。

   • 現状のままのokvclient.jarまたは
   • <myHost>-okvclient.jar。ここで<myHost>は、hostname -sが返す内容と一致します。

   ファイル<myHost>-okvclient.jarの名前を変更することで、混乱や、生成されたノード以外の他のノードでokvclient.jarを使用したくなるという誘惑を回避できます。

6. リカバリ・アプライアンスの各ノードに対して前述のステップを繰り返します。

ノート:

この時点ではJARファイルをインストールしないでください。インストールは、他のリカバリ・アプライアンスの構成ステップの後に実行されます。

JARファイルは、OKVエンドポイントの登録が完了するまでのみ有効です。

リカバリ・アプライアンスのクラウド・アーカイブ構成

この項では、archive-to-cloudに必要なウォレットとクラウド・オブジェクトを使用できるようにリカバリ・アプライアンスを構成します。

資格証明ウォレットおよび暗号化キーストアの構成

すべてのデータベース・バックアップ・ピースは、copy-to-tape操作またはarchive-to-cloud操作の前にDEK暗号化されます。

次のステップでは、リカバリ・アプライアンスのすべてのノードで使用される共有ウォレットを作成します。ウォレットには、個別のDEKキーを暗号化するTDEマスター・キーが格納されます。

1. リカバリ・アプライアンスの資格証明ウォレットを作成します。キーストアの新しいパスワードの入力とウォレットの入力を求められます。リカバリ・アプライアンス暗号化キーストアにアクセスするための資格証明は、このウォレットに保存されます。

   [root@myComputeNodeX ~]# racli add credential_wallet
   
   Fri Jan 1 08:56:27 2018: Start: Add Credential Wallet
   Enter New Keystore Password: <OKV_endpoint_password>
   Confirm New Keystore Password:
   Enter New Wallet Password: <ZDLRA_credential_wallet_password> 
   Confirm New Wallet Password:
   Re-Enter New Wallet Password:
   Fri Jan 1 08:56:40 2018: End: Add Credential Wallet
   

   コマンドのオプションの詳細は、racli add credential_walletを参照してください。

2. リカバリ・アプライアンス暗号化キーストアを構成します。このキーストアには、リカバリ・アプライアンス・クライアント・データベースごとに1つ以上のTDEマスター・キーと、リカバリ・アプライアンスのTDEマスター・キーが含まれています。クライアントごとのTDEマスター・キーは、クラウドにコピーされるバックアップ・ピースを暗号化するために使用されます。

   注意:

   キーストアをアクティブ化するためにリカバリ・アプライアンス・データベースが再起動され、短い停止が計画されます。

   [root@myComputeNodeX ~]# racli add keystore --type hsm --restart_db
   
   Updating log /opt/oracle.RecoveryAppliance/log/racli.log
   Fri Jan 1 08:57:03 2018: Start: Configure Wallets
   Fri Jan 1 08:57:04 2018: End: Configure Wallets
   Fri Jan 1 08:57:04 2018: Start: Stop Listeners, and Database
   Fri Jan 1 08:59:26 2018: End: Stop Listeners, and Database
   Fri Jan 1 08:59:26 2018: Start: Start Listeners, and Database
   Fri Jan 1 09:02:16 2018: End: Start Listeners, and Database

   コマンドのオプションの詳細は、racli add keystoreを参照してください。

リカバリ・アプライアンスのすべてのノードが使用する共有ウォレットが作成されます。ここには、個々のDEKキーを暗号化するTDEマスター・キーが格納されています。

OKVクライアント・ソフトウェアのインストール

リカバリ・アプライアンスの各ノードには、Oracle Key Vault (OKV)の適切なクライアント・ソフトウェアが必要です。これは、RACLIを使用して1つのステップで実行されます。

ユーザーが、/radumpへのアクセス権があるadmin_userまたはrootでない場合は、両方のノードでokvclient.jarファイルを/tmp内にステージングします。

1. リカバリ・アプライアンスのプライマリ・ノードから、次のコマンドを1回のみ実行します。リカバリ・アプライアンスに関連付けられたすべてのOKVエンドポイントが追加されます。これは、~すべての~ノードに適用されます。

   [root@myComputeNodeX ~]# racli install okv_endpoint 
   
   Wed August 23 20:14:40 2018: Start: Install OKV End Point [node01]
   Wed August 23 20:14:43 2018: End: Install OKV End Point [node01]
   Wed August 23 20:14:43 2018: Start: Install OKV End Point [node02]
   Wed August 23 20:14:45 2018: End: Install OKV End Point [node02]
   

   コマンドのオプションの詳細は、racli install okv_endpointを参照してください。

2. Oracle Key Vaultエンドポイント・ソフトウェアが適切にプロビジョニングされていることを確認します。

   [root@myComputeNodeX ~]# racli status okv_endpoint
   
   Node: node02
   Endpoint: Online
   Node: node01
   Endpoint: Online
   

すべてのノードにOKVのクライアント・ソフトウェアが含まれている必要があります。

暗号化キーストアの有効化とTDEマスター・キーの作成

このタスクによって、キーストアが有効になり、最初のTDEマスター・キーが作成されます。

OKVエンドポイント・キーストアは、OKV共有ウォレットとも呼ばれます。キーストアが作成された後、そのキーストアを有効にして、最初のTDEマスター・キーを作成する必要があります。

1. キーストアを開いて使用できるようにします。

   [root@myComputeNodeX ~]# racli enable keystore

   コマンドのオプションの詳細は、racli enable keystoreを参照してください。

2. リカバリ・アプライアンスのTDEマスター・キーを作成します。

   [root@myComputeNodeX ~]# racli alter keystore --initialize_key

archive-to-cloud用のクラウド・オブジェクトの作成

このタスクでは、archive-to-cloudで使用するためのOCIオブジェクトCloud_KeyおよびCloud_Userを作成します。

1. Cloud_Keyを追加します。このオブジェクトは、OCI Cloud Archiveのサポートに固有のものです。

   [root@myComputeNodeX ~]# racli add cloud_key --key_name=example_key
   
   Thu Sep  1 18:11:23 2022: Using log file
   /opt/oracle.RecoveryAppliance/log/racli.log
   Thu Sep  1 18:11:23 2022: Start: Add Cloud Key example_key
   Thu Sep  1 18:11:25 2022: Start: Creating New Keys
   Thu Sep  1 18:11:25 2022: Oracle Database Cloud Backup Module Install Tool,
   build 19.9.0.0.0DBBKPCSBP_2022-05-02
   Thu Sep  1 18:11:25 2022: OCI API signing keys are created:
   Thu Sep  1 18:11:25 2022:   PRIVATE KEY -->
   /raacfs/raadmin/cloud/key/example_key/oci_pvt
   Thu Sep  1 18:11:25 2022:   PUBLIC  KEY -->
   /raacfs/raadmin/cloud/key/example_key/oci_pub
   Thu Sep  1 18:11:25 2022: Please upload the public key in the OCI console.
   Thu Sep  1 18:11:25 2022: End: Creating New Keys
   Thu Sep  1 18:11:26 2022: End: Add Cloud Key example_key

   コマンドのオプションの詳細は、racli add cloud_keyを参照してください。

2. OCIコンソールを開いてサインインします。コンソールはhttps://console.<region>.oraclecloud.comにあります。コンソールのログインおよびパスワードがない場合は、管理者に連絡してください。
3. OCIコンソールから、キーのフィンガープリントを取得します。

   1. キー・ペアを使用してAPIをコールするユーザーの詳細を表示します。

      • このユーザーとしてサインインしている場合、コンソールの右上隅にあるユーザー名をクリックし、「ユーザー設定」をクリックします。
      • 別のユーザーのかわりに管理者としてこの操作を行う場合、「アイデンティティ」をクリックし、「ユーザー」をクリックして、リストからユーザーを選択します。

   2. 公開キーの追加をクリックします。

   3. ダイアログ・ボックスにPEM公開キーの内容を貼り付けて、「追加」をクリックします。

   4. 重要: キーのフィンガープリントをコピーします。これは、後のステップで必要となるためです。

   キーのフィンガープリントが表示されます(たとえば、12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef)。

4. (オプション)最初の公開キーをアップロードした後、追加のキーをアップロードできます。ユーザー当たり最大3つのAPIキー・ペアを持つことができます。APIリクエストには、リクエストの署名に使用しているキーを示すためにキーのフィンガープリントを指定します。
5. フィンガープリントを追加してCloud_Keyを変更します。

   [root@myComputeNodeX ~]# racli alter cloud_key 
   --key_name=example_key
   --fingerprint=12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef
   
   Tue Jul  2 05:40:06 2019:   Start: Alter Cloud Key example_key
   Tue Jul  2 05:40:08 2019:   End: Alter Cloud Key example_key

6. Cloud_Userオブジェクトを追加します。

   [root@myComputeNodeX ~]# racli add cloud_user 
   --user_name=sample_user
   --key_name=example_key
   --user_ocid=ocid1.user.oc1..abcedfghijklmnopqrstuvwxyz0124567901
   --tenancy_ocid=ocid1.tenancy.oc1..abcedfghijklmnopqrstuvwxyz0124567902
   --compartment_ocid=ocid1.compartment.oc1..abcedfghijklmnopqrstuvwxyz0124567903
   
   Tue Jun 18 13:28:45 2019: Using log file /opt/oracle.RecoveryAppliance/log/racli.log
   Tue Jun 18 13:28:45 2019: Start: Add Cloud User sample_user
   Tue Jun 18 13:28:46 2019: End: Add Cloud User sample_user

   --user_name

   この特定のクラウド・ユーザーに関連付けられる名前。これはリカバリ・アプライアンスの論理名であり、リカバリ・アプライアンスのcloud_locationで使用されます。これは、実際のZFSユーザー名と一致する必要はありません。

   --key_name

   このクラウド・ユーザーに関連付けられる特定のクラウド・キー。これは、ステップ1で作成したcloud_keyオブジェクトです。

   --tenancy_ocid

   Oracle Bare Metal CloudアカウントのテナンシOCID。これは、使用される値であり、変化しません。

   --user_ocid

   Oracle Bare Metal CloudアカウントのユーザーOCID。これは、ZFS上のオブジェクト・ストレージ・ユーザーのOCIDです。必ずocid1.user.oc1..<zfs_username>という形式です。

   --compartment_ocid

   Oracle Bare Metal Cloudアカウントのテナンシ内のコンパートメントOCID。コンパートメントOCIDは必ずZFS共有名です。

   コマンドのオプションの詳細は、racli add cloud_userを参照してください。

7. Cloud_Userが作成されたことを、リストして確認します。

   [root@myComputeNodeX ~]# racli list cloud_user --user_name=sample_user
   
   Tue Jul  2 06:45:13 2019: Using log file /opt/oracle.RecoveryAppliance/log/racli.log
   Tue Jul  2 06:45:13 2019: Start: List Cloud User
                 Cloud User:  sample_user
                  User Name: sample_user
                    User ID: 3
                  User OCID: ocid1.user.oc1..abcedfghijklmnopqrstuvwxyz0124567901
               Tenancy OCID: ocid1.tenancy.oc1..abcedfghijklmnopqrstuvwxyz0124567902
           Compartment OCID: ocid1.compartment.oc1..abcedfghijklmnopqrstuvwxyz0124567903
             Cloud Key Name: hk_key_1
   
   Tue Jul  2 06:45:14 2019: End: List Cloud User

クラウドの場所の追加

このタスクでは、archive-to-cloud用のクラウド・バケットの場所を構成します。

cloud_locationを作成するには、cloud_userオブジェクトが作成済である必要があります。cloud_locationの作成は、それぞれ単一の指定されたcloud_userに関連付けられます。この結果、オブジェクト名はクラウドのsbt_library名(bucket_cloud_userなど)に変換されます。このモデルでは、各クラウドの場所は1対1でcloud_userからcloud_locationです。

RACLIに指定されたオプションがインストーラに渡され、バケットのライフサイクル管理の設定を処理します。

完了すると、Oracle Cloud Infrastructureへの自動アーカイブの構成に従って、バックアップをアーカイブ・ストレージに移動する権限がオブジェクト・ストレージに付与されます。

1. クラウドの場所をリカバリ・アプライアンスに追加します。これにより、archive-to-cloud用のsbt_libraryが作成されます。

   [root@myComputeNodeX ~]# racli add cloud_location 
   
   --cloud_user=CLOUD_USER_NAME
   --host=HOST_URL 
   --bucket=OCI_BUCKET_NAME 
   [--enable_archive |  --disable_archive]
   [--archive_after_backup=NUMBER:{DAYS|YEARS}  --streams=NUMBER --proxy_host=HTTP_SERVER
   --proxy_port=HTTP_PORT  --proxy_id=HTTP_USER --proxy_pass=HTTP_PASS
   --import_all_trustcert=X509_CERT_PATH  --retain_after_restore=NUMBER:HOURS]
   [-guaranteed={yes|no}] 
   [--immutable
   --temp_metadata_bucket=METADATA_BUCKET_NAME]
   
   
   Tue Jun 18 13:30:51 2019: Using log file /opt/oracle.RecoveryAppliance/log/racli.log
   Tue Jun 18 13:30:51 2019: Start: Add Cloud Location <OCI_BUCKET_NAME>_<CLOUD_USER_NAME>
   Tue Jun 18 13:30:57 2019: End: Add Cloud Location <OCI_BUCKET_NAME>_<CLOUD_USER_NAME>

   --bucket

   バックアップが移動されるバケットの名前。指定されたバケットが存在しない場合は、インストール・ツールによって作成されます。

   バケット名は、ステップ2で--compartment_ocidのZFS共有内に作成されるディレクトリです。

   バケット名では、大文字と小文字が区別され、使用できる文字は英数字、/、-、_およびピリオド(.)であり、その他の特殊文字は使用できません。バケット名の最大長は255文字です(OCIの256より1少ない)。

   --cloud_user

   すべての認証要件を満たす、以前に構成されたcloud_userオブジェクト。これは、ステップ2でcloud_userの作成に使用したのと同じ論理名です

   --host

   Oracle Bare Metal Cloudアカウントのホスト名。これは、ZFSのホスト名またはIPアドレスの後に必ず/ociが続いたものです。httpsを使用しないでください。

   --streams

   ZFSとリカバリ・アプライアンスの間のデータ送信/受信操作中に使用されるストリームの最大数。以降のステップでコピー・ジョブ・テンプレートを定義するときに、特定のストリーム数が構成されます。単一のZFSアプライアンスでオブジェクト・ストレージへのオープン接続の合計数が256を超えないようにしてください。

   • OCIパブリック・クラウド・バケットと同様に、cloud_locationは、ZDLRAでメディア管理ライブラリ(MML)として使用されます。MMLは、<bucket_name>_<user_name>として表されます。

   • 属性セットは、前述の--steamsの数に基づいてリカバリ・アプライアンス上に作成されます

   ノート:

   クラウド・オブジェクトが適切に作成されたことを検証することが重要です。--enable_archive=TRUE (Archive: TRUEとしてリストされます)の場合、クラウド・バケットでarchive-to-cloud操作を実行できます。--enable_archiveが指定されていない場合、デフォルトはFALSEになります。これは、作成されたクラウドの場所がarchive-to-cloud操作を実行できず、コールド・ストレージになることを意味します。
2. cloud_locationオブジェクトをリストして、正しく作成されたことを確認します。

   [root@myComputeNodeX ~]# racli list cloud_location --location_name=<CLOUD_LOCATION_NAME>
   Fri Oct 25 06:27:18 2019: Using log file /opt/oracle.RecoveryAppliance/log/racli.log
   Fri Oct 25 06:27:18 2019: Start: List Cloud Location
   Cloud Location <CLOUD_LOCATION_NAME>
              Location Name: <CLOUD_LOCATION_NAME>
                    Archive: TRUE
       Archive After Backup: 7:Days
                       Host: https://<HOST_URL>
                     Bucket: <OCI_BUCKET_NAME>
                Location ID: 21
                 Proxy Host: 127.0.0.1
                 Proxy Port: 80
       Retain After Restore: 1:Hours
                    Streams: 6
                    User ID: 1
                SBT Library: <CLOUD_LOCATION_NAME>
         Attribute Set Name: <CLOUD_LOCATION_NAME>_1
              Backup Stream: 1
         Attribute Set Name: <CLOUD_LOCATION_NAME>_2
              Backup Stream: 2
         Attribute Set Name: <CLOUD_LOCATION_NAME>_3
              Backup Stream: 3
         Attribute Set Name: <CLOUD_LOCATION_NAME>_4
              Backup Stream: 4
         Attribute Set Name: <CLOUD_LOCATION_NAME>_5
              Backup Stream: 5
         Attribute Set Name: <CLOUD_LOCATION_NAME>_6
              Backup Stream: 6
   Fri Oct 25 06:27:18 2019: End: List Cloud Location
   

   この検証ステップに基づいてクラウドの場所が不適切に作成された場合、racli remove cloud_locationを使用し、適切な引数を指定してracli add cloud_locationを実行します。

この後のステップでは、sbt_job_templateを作成するために属性セットの名前が必要です。これは、"racli list cloud_location --long"出力から導出できます。racliによって作成されたSBTライブラリおよび属性セットは、dbms_raを使用して表示できますが、変更はできません。

不変のクラウドの場所の追加

このタスクでは、archive-to-cloud用の不変のクラウド・バケットの場所を構成します。

不変のバケットとは、バックアップのKEEP UNTIL属性で指定された期間、クラウド・ストレージにバックアップを保存するバケットです。不変のクラウドの場所には2つのバケットが必要で、これらはOCIコンソール、ZFSコンソールまたはOCIコマンドライン・インタフェースを使用して事前に作成する必要があります。クラウド・バケットは次のとおりです。

• 規制コンプライアンス・バケットには、保存ルール・セットがあり、ロックされています。

• 保存ルールのない一時メタデータ・バケット。

保存ルールはバケット全体に適用されます。したがって、Deleteをトリガーする自動ライフサイクル・ルールを使用しないでください。不変のクラウドの場所ごとに1つのデータベースにすることをお薦めします。

1. リカバリ・アプライアンスを使用してデータベース・クライアントを構成し、クライアント上でバックアップを実行します。
2. OKVエンドポイントをリカバリ・アプライアンスにインストールします。
3. OCIコンソールで不変のバケットを作成します。OCIコンソールにバケットを追加し、バケットの保存ポリシーを作成します。
4. OCIコンソールを使用して一時メタデータ・バケットを作成します。
5. ステップ3で作成した不変のバケットを追加します。

   [root@myComputeNodeX ~]# racli add cloud_location 
   --cloud_user=<CLOUD_USER_NAME> 
   --host=https://<OPC_STORAGE_LOCATION> 
   --bucket=<OCI_BUCKET_NAME> 
   --proxy_port=<HOST_PORT> 
   --proxy_host=<PROXY_URL> 
   --proxy_id=<PROXY_ID>
   --proxy_pass=<PROXY_PASS>
   --streams=<NUM_STREAMS> 
   [--enable_archive=TRUE]
   --archive_after_backup=<number>:[YEARS | DAYS]
   [--retain_after_restore=<number_hours>:HOURS]
   --import_all_trustcert=<X509_CERT_PATH>
   --immutable 
   --temp_metadata_bucket=<metadata_bucket> 
   [--enable_archive=true --archive_after_backup=2:DAYS --retain_after_restore=8:HOURS]
   

6. クラウドへのアーカイブ用にSBT_JOB_TEMPLATEを作成します。

ジョブ・テンプレートの作成

このタスクでは、archive-to-cloud用のジョブ・テンプレートを作成します。

RACLIに指定されたオプションがインストーラに渡され、バケットのライフサイクル管理の設定を処理します。

1. admin db_userユーザーでSQL*Plusにログインします。
2. archive-to-cloud用のSBT_JOB_TEMPLATEを作成します。サポートされているアルゴリズムは、'AES 128'、'AES192'および'AES256 'です。属性セット名は、1ストリームの場合は<CLOUD_LOCATION_NAME>_1、またはパラレルの2ストリームの場合は<CLOUD_LOCATION_NAME>_2のいずれかです。

   SQL> exec dbms_ra.create_sbt_job_template(template_name=>'<COPY_TO_CLOUD_TEMPLATE_NAME>', 
   protection_policy_name=>'BRONZE', 
   attribute_set_name=>'< Attribute Set Name >', 
   backup_type=>'ALL', 
   full_template_name=>'<COPY_TO_CLOUD_TEMPLATE_NAME>', 
   from_tag=>NULL, 
   priority=>100, 
   copies=>1, 
   window=>NULL, 
   compression_algorithm=>'<SUPPORTED_COMPRESSION>',
   encryption_algorithm=>'<SUPPORTED_ALGO>');

   ノート:

   コンプライアンスを使用する場合、Oracleでは、データベースごとに1つのバケットを持つことをお薦めします。コンプライアンス環境でジョブ・テンプレートを作成する場合は、単一のデータベースで保護ポリシーが使用されていないかぎり、ジョブ・テンプレートでprotection_policy_nameのかわりにdb_unique_nameを使用します。

   SQL> exec dbms_ra.create_sbt_job_template(template_name=>'<COPY_TO_CLOUD_TEMPLATE_NAME>', 
   db_unique_name=> '< Database Name>', 
   attribute_set_name=>'< Attribute Set Name >', 
   backup_type=>'ALL', 
   full_template_name=>'<COPY_TO_CLOUD_TEMPLATE_NAME>', 
   from_tag=>NULL, 
   priority=>100, 
   copies=>1, 
   window=>NULL, 
   compression_algorithm=>'<SUPPORTED_COMPRESSION>',
   encryption_algorithm=>'<SUPPORTED_ALGO>');

   コマンドのオプションの詳細は、CREATE_SBT_JOB_TEMPLATEを参照してください。

3. archive-to-cloudジョブを実行します。

   SQL> exec dbms_ra.queue_sbt_backup_task('<COPY_TO_CLOUD_TEMPLATE_NAME>');
   
   PL/SQL procedure successfully completed.

4. バックアップの開始を確認します。

   SQL> SELECT task_type, state, TRUNC(last_execute_time), COUNT(*)
   FROM ra_task
   WHERE state IN ('RUNNING','EXECUTABLE','WAITING','LIBRARY_WAIT')
   AND archived = 'N'
   GROUP BY task_type, state, TRUNC(last_execute_time);
    
   
   TASK_TYPE      STATE         TRUNC(LAS  COUNT(*)
   -------------- ------------- ---------  ----------
   BACKUP_SBT     EXECUTABLE    18-JUN-18  18
   BACKUP_SBT     RUNNING       18-JUN-18  2

保護されたデータベースのTDEマスター・キーの作成または再作成

このステップでは、保護されたデータベースで使用されるDEKキーを暗号化するために、そのポイント以降に使用されるTDEマスター・キーを作成または再作成します。

セキュリティ・ポリシーでは、保護されたデータベースの新しいTDEマスター・キーを作成する頻度または状況を指定します。この操作は「キーの更新」と呼ばれ、リカバリ・アプライアンスのPL/SQLでユーザーrasysとして実行されます。

次のキーの更新のオプションを使用できます。

• ~すべての~保護されたデータベースのキーの更新を実行します。

  SQL> exec dbms_ra.key_rekey;

• 特定の保護されたデータベースのキーの更新を実行します。

  SQL> exec dbms_ra.key_rekey (db_unique_name=>'< DB UNIQUE NAME >');

• 特定の保護ポリシーについて、~すべての~保護されたデータベースのキーの更新を実行します。

  SQL> exec dbms_ra.key_rekey (protection_policy_name=>'< PROTECTION POLICY >>');

キーの更新により、その時点以降に使用される新しいTDEマスター・キーが作成されます。キーの更新によってキーストア内の古いマスター・キーの可用性が影響を受けることはありません。