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

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およびarchive-to-cloud操作中に、各バックアップ・ピースの書込み間でジョブ間待機時間が発生する可能性があります。

• テープへ: 各バックアップ・ピースが書き込まれるたびに一時停止します。バックアップ・ピースの数が多い場合、この一時停止はテープ・ドライブが使用できない時間の大部分を占めます。これは、5個の10GBピースが50個の1GBピースよりも速くテープに格納されることを意味します。

• クラウドへ: 操作はパブリックWAN帯域幅によって制約されます。リカバリ・アプライアンスからのcopy-to-cloudストリームの数を増やすと、全体的なパフォーマンスの向上に役立ちますが、ログのグループ化は、コピーするバックアップ・ピースが少なくなるため、ラウンドトリップ・リクエストの数が減少することを意味します。

リカバリ・アプライアンスリリース19.2.1.1.2では、アーカイブ・ログのバックアップ・ピースをグループ化して単一のバックアップ・ピースとしてコピーすることで、ジョブ間待機時間に対処します。したがって、これにより、クラウドまたはテープ・ストレージ上のバックアップ・ピースが以前のリリースよりも大きくなります。この機能はデフォルトで有効になっており、クラウドまたはテープにコピーされるバックアップ・ピースごとに最大64のアーカイブ・ログをグループ化します。

archive-to-cloudの前提条件

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

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

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

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

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

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

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

「図8-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エンドポイント・グループは、共有仮想ウォレットへの読取り/書込み/管理アクセス権で構成されます。

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

• 各エンドポイントの登録プロセス中に、各ノードのステージング・パス/radumpにホスト固有のokvclient.jarが作成および保存されます。ステージング済ファイルには、現状のままの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つのステップで実行されます。

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=sample_key
   
   Tue Jun 18 13:22:07 2019: Using log file /opt/oracle.RecoveryAppliance/log/racli.log
   Tue Jun 18 13:22:07 2019: Start: Add Cloud Key sample_key
   Tue Jun 18 13:22:08 2019: Start: Creating New Keys
   Tue Jun 18 13:22:08 2019: Oracle Database Cloud Backup Module Install Tool, build 19.3.0.0.0DBBKPCSBP_2019-06-13
   Tue Jun 18 13:22:08 2019: OCI API signing keys are created:
   Tue Jun 18 13:22:08 2019:   PRIVATE KEY --> /raacfs/raadmin/cloud/key/example_key/oci_pvt
   Tue Jun 18 13:22:08 2019:   PUBLIC  KEY --> /raacfs/raadmin/cloud/key/example_key/oci_pub
   Tue Jun 18 13:22:08 2019: Please upload the public key in the OCI console.
   Tue Jun 18 13:22:08 2019: End: Creating New Keys
   Tue Jun 18 13:22:09 2019: End: Add Cloud Key example_key

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

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=sample_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 sample_key
   Tue Jul  2 05:40:08 2019:   End: Alter Cloud Key sample_key

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

   [root@myComputeNodeX ~]# racli add cloud_user 
   --user_name=sample_user
   --key_name=sample_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

   コマンドのオプションの詳細は、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=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>
   
   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>

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

   ノート:

   クラウド・オブジェクトが適切に作成されたことを検証することが重要です。--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用のジョブ・テンプレートを作成します。

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

1. sqlplusにRASYSとしてログインします。
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>');

   コマンドのオプションの詳細は、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マスター・キーが作成されます。キーの更新によってキーストア内の古いマスター・キーの可用性が影響を受けることはありません。