12 Implementing Immutable Backups
"Immutable backups" are backups that cannot be deleted or modified. Some government regulations have specific rules for compliance retention and legal holds.
This section describes the different settings available in the Recovery Appliance to indicate which backups are immutable. By using these features, backups are prevented from being prematurely deleted by automated processes, by mistake, or by malicious users. Also, administrators and automated processes are prevented from adjusting downward the KEEP UNTIL
time.
An immutable backup uses space that cannot be freed until the backup's immutability period ends (KEEP UNTIL
) or the compliance condition (COMPLIANCE_HOLD
) is removed. This might prevent new backups from being created on the system.
Compliance retention is an ongoing retention window and protection policy level setting. Legal hold is a temporary suspension of retention and expiration rules on individual database backups.
The KEEP
and KEEP UNTIL
attributes are also used with Archival Backups, another option for archive to cloud or tape. An archival backup is a full backup that includes required archived logs to recover the data file backups to a specific point in time and has a defined retention period.
Note:
The Oracle Zero Data Loss Recovery Appliance only enforces backup immutability within its domain, within its storage. Recovery Appliance cannot enforce backup immutability on tape or in the cloud, where other services must take on the responsibility for enforcing immutability of backups.The Oracle Zero Data Loss Recovery Appliance addresses immutable backups through attributes for Enterprise Manager Cloud Control, the APIs, the protection policies, and the jobs for backup to tape and cloud.
Legal Holds
A "legal hold" is a process that an organization uses to preserve all forms of potentially relevant information when litigation is pending or reasonably anticipated. When initiated, a legal hold requires that the organization suspend the normal disposition of obsolete records.
The Recovery Appliance administrator can create a legal hold on existing disk backups for specific databases. Backups on legal hold cannot be deleted by internal processes or administrator commands, until the hold is disabled.
This is configured by enabling the COMPLIANCE_HOLD
attribute with UPDATE_DB
for a specified database. A starting date for the hold must be within the current recovery window available for the database. All backups from this date onwards are protected from being deleted. The metadata for those backups is assigned the COMPLIANCE_HOLD
attribute that prevents the backup from being deleted by automated processes or administrators. Legal hold backups are indefinitely retained until the hold is disabled. A legal hold is meant to be transitive and not permanent for a database.
COMPLIANCE_HOLD
applies to the storage of the Recovery Appliance. Compliance hold backups on the Recovery Appliance that are archived to cloud or tape are treated as normal archived backups along with deletion of obsolete backups (recovery_window_sbt
). Therefore, to ensure legal hold on cloud or tape, immutability settings must also be configured using the administrative interfaces for those locations. If a database is in COMPLIANCE_HOLD
and the Recovery Appliance attempts to delete the backup piece on tape or cloud, tape or cloud location grants or denies the request. If tape or cloud refuses to delete a piece, the pointer to the piece inside of the Recovery Appliance is preserved. In this manner, all cloud and tape backup records are preserved in the Recovery Appliance, because the destination blocks any delete operations issued by the Recovery Appliance.
Note:
COMPLIANCE_HOLD
can prevent the addition of new backups to the Recovery Appliance, when backups associated with the legal hold fill up the storage of the Recovery Appliance, because old backups aren't "expiring" and having their storage reclaimed.
Managing Recovery Window Compliance
The "Recovery Window Compliance" is a range of time that the Recovery Appliance will ensure databases can be recovered from their backups. This is specified with a RECOVERY_WINDOW_COMPLIANCE
attribute in the protection policy. When set in the protection policy, newly created backups of that policy are held on the Recovery Appliance for that period of time.
RECOVERY_WINDOW_COMPLIANCE
is different and more restrictive than RECOVERY_WINDOW_GOAL
, because the goal doesn't have to be met but the compliance does. The goal might be for the Recovery Appliance to recover a given database to any point in the last 30 days, if reserve storage is sufficient and not needed and overwritten by newer backups. Recovery window compliance might require the Recovery Appliance to recover a given database to any point in the past 7 days regardless of reserve storage constraints.
Note:
If the RECOVERY_WINDOW_COMPLIANCE
is too large, it can prevent the addition of new backups to the Recovery Appliance, because reserve storage isn't available. When RECOVERY_WINDOW_COMPLIANCE
consumption is near the reserved storage limit and an incoming backup piece would have the space used exceed that limit, RMAN fails immediately.
Because backups need space, you must estimate how much reserve space you believe is needed to store backups. The ESTIMATE_SPACE procedure can assist with determining reserved space. The target_window
used to estimate space should be the RECOVERY_WINDOW_COMPLIANCE
plus an extra day for edge conditions.
Changes can be made to the protection policy to keep backups longer or shorter for new backups. However, once RECOVERY_WINDOW_COMPLIANCE
is set for a given backup, it is strictly enforced and the backup is not deleted until the RECOVERY_WINDOW_COMPLIANCE
period expires.
The two main methods for creating and maintaining recovery window compliance are with an application, such as Enterprise Manager Cloud Control, or using the DBMS_RA API. In either case, the
The steps for setting and removing compliance hold on a database using Enterprise Manager Cloud Control are:
-
Log in to your Cloud Control page.
See Also:
"Accessing the Recovery Appliance Home Page" for more information.
-
From any Cloud Control page, use the Targets drop-down menu and select Recovery Appliances.
The Recovery Appliances page appears.
-
In the Name column, click the name of a Recovery Appliance.
The Home page for the selected Recovery Appliance appears.
-
From the Recovery Appliances drop-down menu, select Protection Policies.
This displays a table with all of the protection policies that the Recovery Appliance is currently enforcing.
-
Select the Protected Policy table and then on Edit to make change for its recovery window compliance or to turn on keep compliance.
This opens the Update Protection Policy dialog box.
Note:
Changes to the protection policy affect all databases that use that policy, which are listed below the Protected Policy table for the policy selected.
The Recovery Window Compliance is a time range to which the Recovery Appliance must ensure that all databases using that protection policy can be recovered. This should be smaller than Recovery Window Goal. The Recovery Window Compliance may be null. If too large, this can result in the Recovery Appliance rejecting new backups, because old backups for compliance purposes have not "expired" and made their storage space available for re-use with incoming backups.
The protection policy can also be used to establish Keep Compliance. When enabled in the protection policy, the Recovery Appliance keeps the backups of all of the associated databases until the "keep until time".
Later when a protection policy and its associated databases no longer require a compliance hold, be sure to remove.
PL/SQL Snippets on Setting Immutability Settings in Protection Policies
The protection policy has two new immutability settings and UPDATE_DB
has one.
If you are creating a new protection policy for compliance, refer to Creating a Protection Policy. You can set multiple compliance attributes at the same time, such as in the following snippet.
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’);
If you are modifying existing protection policies for compliance rules, here are PL/SQL snippets on updating a policy.
-
Set
RECOVERY_WINDOW_COMPLIANCE
settings for one or more protection policies.BEGIN DBMS_RA.UPDATE_PROTECTION_POLICY( PROTECTION_POLICY_NAME => '&pname', RECOVERY_WINDOW_GOAL => INTERVAL '92' DAY, RECOVERY_WINDOW_COMPLIANCE => INTERVAL '14' DAY); END;
Note:
Exercise caution in setting this value, because too large values forRECOVERY_WINDOW_COMPLIANCE
can result in the Recovery Appliance running out of storage with backups that can't be deleted (yet) to the point where new backups can't be stored and are rejected. This number forRECOVERY_WINDOW_COMPLIANCE
should be less than theRECOVERY_WINDOW_GOAL
.RESERVED_SPACE
needs to be large enough to support all needed backups for compliance retention, otherwise the space could fill and cause new backups to be rejected. -
Set
ALLOW_BACKUP_DELETION
attribute toNO
for one or more protection policies.BEGIN DBMS_RA.UPDATE_PROTECTION_POLICY( PROTECTION_POLICY_NAME => '&pname', ALLOW_BACKUP_DELETION => 'NO'); END;
ALLOW_BACKUP_DELETION
set toNO
means that the Recovery Appliance does not allow deletion of these backups, which is the requirement of a legal hold. .ALLOW_BACKUP_DELETION
set toYES
means that the Recovery Appliance allows deletion of these backups when they expire beyond their recovery window goals.Note:
ALLOW_BACKUP_DELETION
has to be set toNO
(disabled) beforeKEEP_COMPLIANCE
is enabled. -
Enable
KEEP_COMPLIANCE
immutable settings for one or more protection policies.Here is a pseudo snippet for PL/SQL that shows the
KEEP_COMPLIANCE
attribute being set in a given protection policy.BEGIN DBMS_RA.UPDATE_PROTECTION_POLICY( PROTECTION_POLICY_NAME => '&pname', KEEP_COMPLIANCE => 'YES'); END;
YES
: The Recovery Appliance prevents the deletion ofKEEP
backups.NO
: The administrator of the Recovery Appliance is permitted to removeKEEP
backups.The
KEEP_COMPLIANCE
attribute helps enable the archival backup by preventing its storage from getting overwritten when the backup would normally have expired according to its recovery window goals. However, once thekeep_time
is reached, the backup can be deleted.
Managing Compliance Holds
A "compliance hold" or "legal hold" is a process that an organization uses to preserve all forms of potentially relevant information when litigation is pending or reasonably anticipated. When initiated, a compliance hold requires that the organization suspend the normal disposition of obsolete records.
The Recovery Appliance administrator can create a compliance hold on existing disk backups for specific databases. Backups on compliance hold cannot be deleted by internal processes or administrator commands, until the compliance hold is disabled.
COMPLIANCE_HOLD
applies to the storage of the Recovery Appliance. Compliance hold backups on the Recovery Appliance that are archived to cloud or tape are treated as normal archived backups along with deletion of obsolete backups (recovery_window_sbt
). Therefore, to ensure legal hold on cloud or tape, immutability settings must also be configured using the administrative interfaces for those locations. If a database is in COMPLIANCE_HOLD
and the Recovery Appliance attempts to delete the backup piece on tape or cloud, tape or cloud location grants or denies the request. If tape or cloud refuses to delete a piece, the pointer to the piece inside of the Recovery Appliance is preserved. In this manner, all cloud and tape backup records are preserved in the Recovery Appliance, because the destination blocks any delete operations issued by the Recovery Appliance.
Note:
COMPLIANCE_HOLD
can prevent the addition of new backups to the Recovery Appliance, when backups associated with the legal hold fill up the storage of the Recovery Appliance, because old backups aren't "expiring" and having their storage reclaimed.
The two main methods for creating and maintaining compliance holds are with an application, such as Enterprise Manager Cloud Control, or using the DBMS_RA API.
The steps for setting and removing compliance hold on a database using Enterprise Manager Cloud Control are:
-
Log in to your Cloud Control page.
See Also:
"Accessing the Recovery Appliance Home Page" for more information.
-
From any Cloud Control page, use the Targets drop-down menu and select Recovery Appliances.
The Recovery Appliances page appears.
-
In the Name column, click the name of a Recovery Appliance.
The Home page for the selected Recovery Appliance page appears.
From this page you can see a snapshot of the entire Recovery Appliance, and also click links to obtain more information about a particular area.
-
From the Recovery Appliances drop-down menu, select Protected Databases.
This displays a table with all of the databases that the Recovery Appliance is currently protecting.
-
Select the row in the Protected Databases table for the database that needs compliance to be turned on. While highlighted, select the Set Compliance button from above the table.
This opens the Set Compliance Hold dialog box with the checkbox to set or remove a compliance hold on that database.
-
To set a compliance hold, specify a start date that is within the current recovery window for the database and mark the checkbox Compliance Hold.
All backups from the specified date onwards will not be deleted.
Later when a given database no longer requires a compliance hold, be sure to remove.
A "compliance hold" is configured by enabling the COMPLIANCE_HOLD
attribute with UPDATE_DB
for a specified database. A starting date for the hold must be within the current recovery window available for the database. All backups from this date onwards are protected from being deleted. The metadata for those backups is assigned the COMPLIANCE_HOLD
attribute that prevents the backup from being deleted by automated processes or administrators. Legal hold backups are indefinitely retained until the hold is disabled. A legal hold is meant to be transitive and not permanent for a database.
PL/SQL Snippets on Setting Immutability Settings in Protection Policies
The protection policy has two new immutability settings and UPDATE_DB
has one.
If you are creating a new protection policy for compliance, refer to Creating a Protection Policy. You can set multiple compliance attributes at the same time, such as in the following snippet.
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’);
If you are modifying existing protection policies for compliance rules, here are PL/SQL snippets on updating a policy.
-
Set
COMPLIANCE_HOLD
settings for one or more databases.BEGIN DBMS_RA.UPDATE_DB( DB_UNIQUE_NAME => '&dbname', COMPLIANCE_HOLD => SYSTIMESTAMP - NUMTODSINTERVAL(7, 'DAY'); END;
COMPLIANCE_HOLD
is the time from which backups may not be deleted from the Recovery Appliance. The database must be recoverable starting at the time specified by thisCOMPLIANCE_HOLD
. Specify the time as any validTIMESTAMP WITH TIME ZONE
expression.If an immutable cloud location is configured (via OCI Console) with an indefinite retention policy on the bucket, the
COMPLIANCE_HOLD
attribute on the database also prevents deletion of backups from the hold period that were archived to the cloud location, until theCOMPLIANCE_HOLD
is removed. -
Set
ALLOW_BACKUP_DELETION
attribute toNO
for one or more protection policies.BEGIN DBMS_RA.UPDATE_PROTECTION_POLICY( PROTECTION_POLICY_NAME => '&pname', ALLOW_BACKUP_DELETION => 'NO'); END;
ALLOW_BACKUP_DELETION
set toNO
means that the Recovery Appliance does not allow deletion of these backups, which is the requirement of a legal hold. .ALLOW_BACKUP_DELETION
set toYES
means that the Recovery Appliance allows deletion of these backups when they expire beyond their recovery window goals.Note:
ALLOW_BACKUP_DELETION
has to be set toNO
(disabled) beforeKEEP_COMPLIANCE
is enabled. -
Enable
KEEP_COMPLIANCE
immutable settings for one or more protection policies.Here is a pseudo snippet for PL/SQL that shows the
KEEP_COMPLIANCE
attribute being set in a given protection policy.BEGIN DBMS_RA.UPDATE_PROTECTION_POLICY( PROTECTION_POLICY_NAME => '&pname', KEEP_COMPLIANCE => 'YES'); END;
YES
: The Recovery Appliance prevents the deletion ofKEEP
backups.NO
: The administrator of the Recovery Appliance is permitted to removeKEEP
backups.The
KEEP_COMPLIANCE
attribute helps enable the archival backup by preventing its storage from getting overwritten when the backup would normally have expired according to its recovery window goals. However, once thekeep_time
is reached, the backup can be deleted.