不変バックアップの実装

12 不変バックアップの実装

不変バックアップとは、削除も変更もできないバックアップです。一部の政府規制には、コンプライアンス保持および法定保留に関する特定のルールがあります。

この項では、どのバックアップが不変であるかを示すためにリカバリ・アプライアンスで使用可能な様々な設定について説明します。これらの機能を使用して、自動処理によって、誤って、または悪意のあるユーザーによってバックアップが早期に削除されることを防ぎます。また、管理者および自動処理は、KEEP UNTILの時間を先へ調整できなくなります。

不変バックアップでは、バックアップの不変性期間が終了するまで(KEEP UNTIL)、またはコンプライアンス条件(COMPLIANCE_HOLD)が削除されるまで解放できない領域が使用されます。これにより、システム上に新しいバックアップが作成されない場合があります。

コンプライアンス保持は、継続的な保存期間および保護ポリシーのレベル設定です。法定保留は、個々のデータベース・バックアップの保存ルールと有効期限ルールを一時的に停止します。

KEEPおよびKEEP UNTIL属性は、アーカイブ・バックアップ(クラウドまたはテープにアーカイブする別のオプション)でも使用されます。アーカイブ・バックアップは、データ・ファイル・バックアップを特定のポイント・イン・タイムにリカバリし、保存期間が定義されている必要なアーカイブ・ログを含む完全バックアップです。

ノート:

Oracle Zero Data Loss Recovery Applianceは、ドメイン内、記憶域内のバックアップのみの不変性を維持します。リカバリ・アプライアンスはテープまたはクラウドでバックアップの不変性を維持できません。他のサービスで、バックアップの不変性を維持する必要があります。

Oracle Zero Data Loss Recovery Applianceでは、Enterprise Manager Cloud Control、API、保護ポリシーおよびテープとクラウドへのバックアップのジョブの属性を通じて不変のバックアップに対応します。

法定保留

法定保留は、訴訟が保留中であるか当然予期される場合に、関連する可能性があるすべての形式の情報を保持するために組織が使用するプロセスです。開始時に、法定保留では組織が不要なレコードの通常の処理を一時停止する必要があります。

リカバリ・アプライアンスの管理者は、特定のデータベースの既存のディスク・バックアップに法定保留を作成できます。法定保留のバックアップは、保留が無効になるまで内部プロセスまたは管理者コマンドによって削除できません。

これは、指定されたデータベースに対してUPDATE_DBを持つCOMPLIANCE_HOLD属性を有効にすることで構成されます。保留の開始日は、データベースで使用可能な現在のリカバリ・ウィンドウ内である必要があります。この日付以降のすべてのバックアップは、削除されないように保護されています。これらのバックアップのメタデータには、自動プロセスまたは管理者がバックアップを削除できないようにするCOMPLIANCE_HOLD属性が割り当てられます。法定保留のバックアップは、保留が無効になるまで無期限に保持されます。法定保留は、データベースに対して推移的であり、永続的ではありません。

COMPLIANCE_HOLDは、リカバリ・アプライアンスの記憶域に適用されます。クラウドまたはテープにアーカイブされたリカバリ・アプライアンスのコンプライアンス保持バックアップは、不要なバックアップ(recovery_window_sbt)の削除とともに通常のアーカイブ・バックアップとして扱われます。したがって、クラウドまたはテープに法定保留を適用する場合、それらの場所の管理インタフェースを使用して不変性の設定も構成する必要があります。データベースがCOMPLIANCE_HOLDであり、リカバリ・アプライアンスがテープまたはクラウド上のバックアップ・ピースを削除しようとした場合、テープまたはクラウドの場所でリクエストが付与または拒否されます。テープまたはクラウドがピースの削除を拒否した場合、リカバリ・アプライアンス内のピースへのポインタは保持されます。この方法では、リカバリ・アプライアンスによって発行されたすべての削除操作が宛先でブロックされるため、すべてのクラウドおよびテープ・バックアップ・レコードがリカバリ・アプライアンスに保持されます。

ノート:

COMPLIANCE_HOLDでは、法定保留に関連付けられたバックアップでリカバリ・アプライアンスの記憶域が一杯になると、リカバリ・アプライアンスへの新しいバックアップを追加できません。古いバックアップが期限切れにならず、その記憶域が再利用されるためです。

リカバリ・ウィンドウ・コンプライアンスの管理

リカバリ・ウィンドウ・コンプライアンスは、リカバリ・アプライアンスがデータベースをバックアップからリカバリできることを保証する時間範囲です。これは、保護ポリシーのRECOVERY_WINDOW_COMPLIANCE属性で指定されます。保護ポリシーで設定すると、そのポリシーの新しく作成されたバックアップがその期間のリカバリ・アプライアンスに保持されます。

RECOVERY_WINDOW_COMPLIANCEはRECOVERY_WINDOW_GOALとは異なり、より多くの制限があります。goalを満たす必要はありませんが、complianceを満たす必要があるためです。目標は、予約記憶域が十分で必要なく、新しいバックアップによって上書きされる場合、リカバリ・アプライアンスが過去30日間の任意の時点に特定のデータベースをリカバリするためのものです。リカバリ・ウィンドウ・コンプライアンスでは、予約記憶域の制約に関係なく、特定のデータベースを過去7日間の任意の時点にリカバリするためにリカバリ・アプライアンスが必要になる場合があります。

ノート:

RECOVERY_WINDOW_COMPLIANCEが大きすぎると、予約記憶域が使用できなくなるため、リカバリ・アプライアンスへの新しいバックアップを追加できません。RECOVERY_WINDOW_COMPLIANCEの消費量が予約済記憶域制限に近づき、受信バックアップ・ピースの使用量がこの制限を超えると、RMANは即時に失敗します。

バックアップで領域が必要なため、バックアップを格納するために必要な予約領域を予測する必要があります。ESTIMATE_SPACEプロシージャは、予約済領域の決定に役立ちます。領域を見積もるために使用するtarget_windowを、周辺条件に対してRECOVERY_WINDOW_COMPLIANCEと追加の1日にする必要があります。

新しいバックアップのバックアップをより長くまたは短く保持するために、保護ポリシーを変更できます。ただし、特定のバックアップにRECOVERY_WINDOW_COMPLIANCEを設定すると、これは厳密に実行され、RECOVERY_WINDOW_COMPLIANCE期間が期限切れになるまでバックアップは削除されません。

リカバリ・ウィンドウ・コンプライアンスを作成および保持するための主な2つの方法は、Enterprise Manager Cloud Controlなどのアプリケーションを使用するか、DBMS_RA APIを使用します。どちらの場合も、次のように操作します

CloudControl
API

Enterprise Manager Cloud Controlを使用してデータベースのコンプライアンス保持を設定および削除するステップは、次のとおりです:

Cloud Controlページにログインします。

関連項目:

詳細は、「リカバリ・アプライアンス・ホームページへのアクセス」を参照してください。
Cloud Controlの任意のページで、「ターゲット」ドロップダウン・メニューを使用して、「リカバリ・アプライアンス」を選択します。

リカバリ・アプライアンス・ページが表示されます。
「名前」列にある、リカバリ・アプライアンスの名前をクリックします。

選択したリカバリ・アプライアンスのホームページが表示されます。
「リカバリ・アプライアンス」ドロップダウン・メニューから、「保護ポリシー」を選択します。

これにより、そのリカバリ・アプライアンスによって現在適用されているすべての保護ポリシーを含む表が表示されます。
保護されたポリシー表を選択してから、「編集」で、そのリカバリ・ウィンドウ・コンプライアンスを変更するか、保持コンプライアンスをオンにします。

これにより、保護ポリシーの更新ダイアログ・ボックスが開かれます。

ノート:
保護ポリシーに対する変更は、そのポリシーを使用するすべてのデータベースに影響します。それらは、選択したポリシーの「保護ポリシー」表の下にリストされます。

リカバリ・ウィンドウ・コンプライアンスとは、そのリカバリ・アプライアンスで、その保護ポリシーを使用するすべてのデータベースをリカバリできることが保証されている必要がある時間範囲です。これは、リカバリ・ウィンドウ目標よりも小さくする必要があります。リカバリ・ウィンドウ・コンプライアンスはnullにできます。大きすぎる場合は、コンプライアンス目的のための古いバックアップが"期限切れ"になっておらず、それらの記憶領域が受信バックアップでの再使用のために確保されていないため、リカバリ・アプライアンスで新しいバックアップが拒否される可能性があります。

保護ポリシーは、保持コンプライアンスの確立にも使用できます。保護ポリシーにおいて有効にすると、リカバリ・アプライアンスにより、関連するすべてのデータベースのバックアップが、"keep until time"まで保持されます。

後で、保護ポリシーとそれに関連付けられたデータベースでコンプライアンスの保持が不要になったときは、必ず削除してください。

保護ポリシーでの不変性設定に関するPL/SQLスニペット

保護ポリシーには2つの新しい不変性設定があり、UPDATE_DBには1つあります。

コンプライアンスのための新しい保護ポリシーを作成する場合は、「保護ポリシーの作成」を参照してください。同時に複数のコンプライアンス属性を設定できます。たとえば、次のスニペットで行います。

dbms_ra.CREATE_PROTECTION_POLICY (
PROTECTION_POLICY_NAME => ‘Policy 1’, 
STORAGE_LOCATION_NAME => ‘DELTA’, 
RECOVERY_WINDOW_GOAL = INTERVAL '14' DAY, 
RECOVERY_WINDOW_COMPLIANCE => INTERVAL '7' DAY, 
KEEP_COMPLIANCE => ‘YES’, 
ALLOW_BACKUP_DELETION => ‘NO’);

コンプライアンス・ルールの既存の保護ポリシーを変更する場合、ポリシーの更新に関するPL/SQLスニペットを次に示します。

1つ以上の保護ポリシーのRECOVERY_WINDOW_COMPLIANCE設定を設定します。
```
BEGIN
DBMS_RA.UPDATE_PROTECTION_POLICY(
    PROTECTION_POLICY_NAME =>  '&pname', 
    RECOVERY_WINDOW_GOAL => INTERVAL '92' DAY,
    RECOVERY_WINDOW_COMPLIANCE => INTERVAL '14' DAY);
END;
```
ノート:
RECOVERY_WINDOW_COMPLIANCEの値が大きすぎると、リカバリ・アプライアンスでバックアップの記憶域が不足し、バックアップは削除できず、新しいバックアップは格納できず拒否される可能性があるため、この値の設定には注意が必要です。RECOVERY_WINDOW_COMPLIANCEのこの番号は、RECOVERY_WINDOW_GOAL未満にする必要があります。RESERVED_SPACEは、コンプライアンス保持に必要なすべてのバックアップをサポートするのに十分な大きさにする必要があります。そうしないと、領域が一杯になり、新しいバックアップが拒否される可能性があります。
1つ以上の保護ポリシーに対してALLOW_BACKUP_DELETION属性をNOに設定します。
```
BEGIN
DBMS_RA.UPDATE_PROTECTION_POLICY(
    PROTECTION_POLICY_NAME =>  '&pname', 
    ALLOW_BACKUP_DELETION =>  'NO');
END;
```
ALLOW_BACKUP_DELETIONをNOに設定することは、リカバリ・アプライアンスではこれらのバックアップの削除が許可されないことを意味します。これは法定保留の要件です。

ALLOW_BACKUP_DELETIONをYESに設定することは、リカバリ・アプライアンスがリカバリ・ウィンドウの目標を超えて期限切れになった場合に、これらのバックアップを削除できることを意味します。

ノート:

KEEP_COMPLIANCEを有効にする前に、ALLOW_BACKUP_DELETIONをNO (無効)に設定する必要があります。
1つ以上の保護ポリシーのKEEP_COMPLIANCE不変設定を有効にします。

特定の保護ポリシーで設定されているKEEP_COMPLIANCE属性を示すPL/SQLの疑似スニペットを次に示します。
```
BEGIN
DBMS_RA.UPDATE_PROTECTION_POLICY( 
  PROTECTION_POLICY_NAME =>  '&pname',
  KEEP_COMPLIANCE => 'YES');
END;
```
YES: リカバリ・アプライアンスでは、KEEPバックアップを削除できなくなります。NO: リカバリ・アプライアンスの管理者は、KEEPバックアップを削除できます。

KEEP_COMPLIANCE属性は、リカバリ・ウィンドウ目標に従ってバックアップの期限が切れると記憶域が上書きされないようにすることで、アーカイブ・バックアップを有効にするのに役立ちます。ただし、keep_timeに到達すると、バックアップを削除できます。

コンプライアンス保持の管理

"コンプライアンス保持"または"法定保留"は、訴訟が保留中であるか当然予期される場合に、関連する可能性があるすべての形式の情報を保持するために組織が使用するプロセスです。開始時に、コンプライアンス保持では組織が不要なレコードの通常の処理を一時停止する必要があります。

リカバリ・アプライアンスの管理者は、特定のデータベースの既存のディスク・バックアップにコンプライアンス保持を作成できます。コンプライアンス保持のバックアップは、コンプライアンス保持が無効になるまで内部プロセスまたは管理者コマンドによって削除できません。

ノート:

コンプライアンス保持を作成および保持するための主な2つの方法は、Enterprise Manager Cloud Controlなどのアプリケーションを使用するか、DBMS_RA APIを使用します。

CloudControl
API

Enterprise Manager Cloud Controlを使用してデータベースのコンプライアンス保持を設定および削除するステップは、次のとおりです:

Cloud Controlページにログインします。

関連項目:

詳細は、「リカバリ・アプライアンス・ホームページへのアクセス」を参照してください。
Cloud Controlの任意のページで、「ターゲット」ドロップダウン・メニューを使用して、「リカバリ・アプライアンス」を選択します。

リカバリ・アプライアンス・ページが表示されます。
「名前」列のリカバリ・アプライアンスの名前をクリックします。

選択したリカバリ・アプライアンスのホームページが表示されます。

このページで、リカバリ・アプライアンス全体のスナップショットを確認できます。また、リンクをクリックして特定の内容の詳細を参照できます。
「リカバリ・アプライアンス」ドロップダウン・メニューから、「保護されたデータベース」を選択します。

これにより、リカバリ・アプライアンスが現在保護しているすべてのデータベースを含む表が表示されます。
コンプライアンスをオンにする必要があるデータベースの「保護されたデータベース」表の行を選択します。強調表示されている状態で、表の上にあるコンプライアンスの設定ボタンを選択します。

これにより、コンプライアンス保持の設定ダイアログ・ボックスが開き、そのデータベースのコンプライアンス保持を設定または削除するためのチェック・ボックスが表示されます。
コンプライアンス保持を設定するには、データベースの現在のリカバリ・ウィンドウ内の開始日を指定し、コンプライアンス保持チェック・ボックスを選択します。

指定した日付以降のすべてのバックアップが削除されるわけではありません。

特定のデータベースでコンプライアンス保持が不要になった場合は、必ず削除してください。

"コンプライアンス保持"は、指定されたデータベースに対してUPDATE_DBを持つCOMPLIANCE_HOLD属性を有効にすることで構成されます。保留の開始日は、データベースで使用可能な現在のリカバリ・ウィンドウ内である必要があります。この日付以降のすべてのバックアップは、削除されないように保護されています。これらのバックアップのメタデータには、自動プロセスまたは管理者がバックアップを削除できないようにするCOMPLIANCE_HOLD属性が割り当てられます。法定保留のバックアップは、保留が無効になるまで無期限に保持されます。法定保留は、データベースに対して推移的であり、永続的ではありません。

保護ポリシーでの不変性設定に関するPL/SQLスニペット

保護ポリシーには2つの新しい不変性設定があり、UPDATE_DBには1つあります。

dbms_ra.CREATE_PROTECTION_POLICY (
PROTECTION_POLICY_NAME => ‘Policy 1’, 
STORAGE_LOCATION_NAME => ‘DELTA’, 
RECOVERY_WINDOW_GOAL = INTERVAL '14' DAY, 
RECOVERY_WINDOW_COMPLIANCE => INTERVAL '7' DAY, 
KEEP_COMPLIANCE => ‘YES’, 
ALLOW_BACKUP_DELETION => ‘NO’);

コンプライアンス・ルールの既存の保護ポリシーを変更する場合、ポリシーの更新に関するPL/SQLスニペットを次に示します。

1つ以上のデータベースに対してCOMPLIANCE_HOLD設定を設定します。
```
BEGIN
DBMS_RA.UPDATE_DB(
    DB_UNIQUE_NAME =>  '&dbname', 
    COMPLIANCE_HOLD => SYSTIMESTAMP - NUMTODSINTERVAL(7, 'DAY');
END;
```
COMPLIANCE_HOLDは、リカバリ・アプライアンスからバックアップを削除できなくなる時間です。データベースは、このCOMPLIANCE_HOLDで指定された時間からリカバリ可能になる必要があります。時間を有効なTIMESTAMP WITH TIME ZONE式として指定します。

不変のクラウドの場所が(OCIコンソールを介して)バケットの無期限保護ポリシーを使用して構成されている場合、COMPLIANCE_HOLDが削除されるまで、データベースのCOMPLIANCE_HOLD属性もクラウドの場所にアーカイブされたバックアップを保持期間からの削除を防止します。
1つ以上の保護ポリシーに対してALLOW_BACKUP_DELETION属性をNOに設定します。
```
BEGIN
DBMS_RA.UPDATE_PROTECTION_POLICY(
    PROTECTION_POLICY_NAME =>  '&pname', 
    ALLOW_BACKUP_DELETION =>  'NO');
END;
```
ALLOW_BACKUP_DELETIONをNOに設定することは、リカバリ・アプライアンスではこれらのバックアップの削除が許可されないことを意味します。これは法定保留の要件です。

ALLOW_BACKUP_DELETIONをYESに設定することは、リカバリ・アプライアンスがリカバリ・ウィンドウの目標を超えて期限切れになった場合に、これらのバックアップを削除できることを意味します。

ノート:

KEEP_COMPLIANCEを有効にする前に、ALLOW_BACKUP_DELETIONをNO (無効)に設定する必要があります。
1つ以上の保護ポリシーのKEEP_COMPLIANCE不変設定を有効にします。

特定の保護ポリシーで設定されているKEEP_COMPLIANCE属性を示すPL/SQLの疑似スニペットを次に示します。
```
BEGIN
DBMS_RA.UPDATE_PROTECTION_POLICY( 
  PROTECTION_POLICY_NAME =>  '&pname',
  KEEP_COMPLIANCE => 'YES');
END;
```
YES: リカバリ・アプライアンスでは、KEEPバックアップを削除できなくなります。NO: リカバリ・アプライアンスの管理者は、KEEPバックアップを削除できます。

KEEP_COMPLIANCE属性は、リカバリ・ウィンドウ目標に従ってバックアップの期限が切れると記憶域が上書きされないようにすることで、アーカイブ・バックアップを有効にするのに役立ちます。ただし、keep_timeに到達すると、バックアップを削除できます。