ZDLRA software 23.1 is out and you are most likely wondering “Where should I start to take advantage of the new space-efficient encrypted backup features”?

Below are some items to know before I get into the recipes.

1) Let’s go through a few of the pre-requisites to make sure you are ready.

You must be using release 19.18+ on your protected database to utilize the new features.
You need to make sure your client has the latest copy of the ZDLRA client library (libra.so).
Only Linux is supported at this point in time
You need to be on software relased RA 21.1 April 2022 PSU (21.1.202204-PSU) or higher.

Pro Tip : Starting in 21.x, most database specific files have been moved from $ORACLE_HOME to $ORACLE_BASE. Now is a good time to manage the library, and the wallet file under $ORACLE_BASE for all databases sharing a node.

2) With this software release there is a new parameter that should be included on the channel configuration, RA_FORMAT.

To leverage the new feature you need to add “RA_FORMAT=TRUE” to the channel parameters for the ZDLRA library.

RA_FORMAT – This parameter will tell the ZDLRA library to format the backup in the new client compressed format. What is different about this format is that it compresses the data within the blocks AND is able to combine this with encryption. Typically RMAN compression compresses the backupset (not the blocks themselves), and when combined with encryption would encrypt the backupset. Because the compression and/or encryption is done at the block level, it is compatible with the ZDLRA ability to create virtual full backups and validate stored backupsets.

3) After setting RA_FORMAT=TRUE, each subsequent incremental L1 backups will send the block backups in this new format. Because compression is handled at the block level, you can have a mix of blocks in the original format, and blocks in the new format. This allows you to take advantage of this feature over time, controlling when a new L0 backup is taken and plan for temporary increases in space utilization.

4) Taking advantage of this compressed format does not require the ACO license. Also, if you choose to encrypt the backups prior to sending it to the ZDLRA, you are not required to have the ASO license.

5) Enabling AUTOTUNE_RESERVED_SPACE at the policy level will adjust the reserved as this feature is implemented. I would HIGHLY RECOMMEND implementing autotune especially if you have a acompliance window set on your protection policies.

Recipe #1 – Databases are TDE and you want to take advantage of compression and encryption at rest

If you have implemented TDE you can take advantage of this new format to compress your backups, and ensure that all pieces of your backup are encrypted. Fully encrypting all backup pieces is the MAA (Maximum Avalability Architecture) best practices for protected backups from exfiltration. Fully encrypting your backups can be done without requiring the ASO license.

1) In order to compress the contents of new blocks, even for TDE tablespaces you need to set

RA_FORMAT=TRUE

Any datafiles that are members of an encrypted tablespace will format new backups with compressed/encrypted blocks.

Any datafiles that are members of a non-TDE tablespace will format new backups with compression

2) To ensure that all backup pieces are fully encrypted (even for non-TDE tablespaces) you need to

RMAN> Set encryption on;

Any datafiles that are members on a non-TDE tablespace will also format new backups with compressed/encrypted blocks.

This will affect ALL other backupsets. Archive log backups,spfile backups, and controlfile backups will all be encrypted backupsets.

3) Encrypt Real-time redo

set ENCRYPTION=ENABLE on the destination for ZDLRA.

This will ensure that the archive logs which are received through real-time redo are stored encrypted.

PROS of Recipe #1

This allows all backup pieces to be considered encrypted at rest following MAA best practices.
All datafile backups sent from the protected database are compressed using less bandwidth, and will be encrypted
Any datafile backups for non-TDE tablespaces will also be encrypted.
Datafile backups on the ZDLRA are stored compressed, even for datafile backups of TDE encrypted data. This will better optimize space utilization.
Datafile backups are replicated in the compressed format. This uses much less WAN traffic when replicating backups to another datacenter, or into a Cyber Vault.
Datafile backups are restored in the compressed format. This uses less bandwidth during a restore operation. This is especially useful for concurrent DB restores when the network could become a bottleneck.

NOTES:

1. If you are implementing this feature and want to ensure that your backups are fully “encrypted at rest” you will need to perform a new L0 backup of any non-TDE datafiles.

2. If you are implementing this feature and want to perform a copy-to-cloud process without OKV, you need to perform a new L0 backup of any non-TDE datafiles, and you need to ensure that any archive log backupsets being sent to the cloud are created during a log sweep. Real-time redo, even though it is encrypted is NOT considered encrypted by the copy-to-cloud process.

3. If you have both TDE and non-TDE tablespaces, you can also take advantage of RMAN compression of archive logs. Changes to data in non-TDE tablespaces will compress.

When performing log sweeps, you can create compressed backupsets of archive logs. Using any algorithm other than basic requires ACO.

Recipe #2 – Databases are TDE and you want to take advantage of compression

If you have implemented TDE you can take advantage of this new format to compress your backups. It is not mandatory to full encrypt your backups when utilizing the new compessed format, though fully encrypting your backups follows MAA best practives.

I would recommend to follow recipe #1 and fully encrypt your backups.

1) In order to compress the contents of new blocks, even for TDE tablespaces you need to set

RA_FORMAT=TRUE

NOTE: Many times, the database will have both TDE tablespaces and non-TDE tablespaces.

Any datafiles that are members of an encrypted tablespace will format new backups with compressed/encrypted blocks.
Any datafiles that are members of a non-TDE tablespace will format new backups with compressed blocks, but will NOT encrypt them unless RMAN encryption is explicitly turned on.

This recipe does not ensure that all backups are encrypted, the archive log, spfile, and controlfile backups are not encrypted. Also the backup of any non-TDE tablespaces are not encrypted.

PROS of recipe #2

All datafile backups sent from the protected database are compressed using less bandwidth.
Datafile backups on the ZDLRA are stored compressed, even for datafile backups of TDE encrypted data. This will better optimize space utilization.
Datafile backups are replicated in the compressed format. This uses much less WAN traffic when replicating backups to another datacenter, or into a Cyber Vault.
Datafile backups are restored in the compressed format. This uses less bandwidth during a restore operation. This is especially useful for concurrent DB restores when the network could become a bottleneck.
If most of your data in tablespaces are not TDE encrypted, this allows for compression of real-time redo on the ZDLRA without an ACO license.

OPTIONAL

If you have both TDE and non-TDE tablespaces, you can also take advantage of RMAN compression of archive logs.

When performing log sweeps, you can create compressed backupsets of archive logs. Using any algorithm other than basic requires ACO
When using real-time redo, you can utilize any compression algorithm without requiring ACO.

Recipe #3 – Databases are not TDE and you want to take advantage of compression and encryption at rest

If you have not implemented TDE you can still take advantage of this new format to compress your backups, and ensure that all pieces of your backup are encrypted at rest. This can be done without requiring the ASO license, and fully encrypting your backups follows MAA best practices.

1) You must create an encryption wallet (or use OKV) to store the encryption keys, and create a master encryption key for the CDB and each PDB.

2) You need to turn the new feature on in the channel settings

RA_FORMAT=TRUE

The library will format new backups with compressed/encrypted blocks.

3) You need to enable encryption

RMAN> Set encryption on;

Setting encryption on will cause the ZDLRA library to encrypt all datafile backups, It will also affect ALL non-datafile backup sets. Archive log backups,spfile backups, and controlfile backups will all be encrypted backupsets.

4) Encrypt real-time redo – ENCRYPTION=ENABLE on the destination for ZDLRA.

This will ensure that the archive logs that are received through real-time redo are stored encrypted.

PROS of recipe #3

All datafile backups sent from the protected database are compressed using less bandwidth, and will be encrypted even though the tablespaces are not.
Datafile backups on the ZDLRA are stored compressed, and encrypted. This will better optimize space utilization.
Datafile backups are replicated in the compressed/encrypted format. This uses much less WAN traffic, and ensures encryption in transit when replicating backups to another datacenter, or into a Cyber Vault.
Datafile backups are restored in the compressed format. This uses less bandwidth during a restore operation. This is especially useful for concurrent DB restores when the network could become a bottleneck.

OPTIONAL

You can also take advantage of RMAN compression of archive logs.

When performing log sweeps, you can create compressed backupset of archive logs. Using any algorithm other than basic requires ACO

NOTE:

1. If you are implementing this feature and want to ensure that your backups are fully “encrypted at rest” you will need to perform a new L0 backup of all datafiles.

2. If you are implementing this feature and want to perform a copy-to-cloud process without OKV, you need to perform a new L0 backup of all datafiles, and you need to ensure that any archive log backupsets being sent to the cloud are created during a log sweep. Real-time redo, even though it is encrypted is NOT considered encrypted by the copy-to-cloud process.

3. If you are using real-time redo, since the redo is received (and stored) encrypted on the ZDLRA, the ZDLRA will not be able to RMAN compress those backupsets.

Recipe #4 – Databases are NOT TDE and you want to take advantage of client compression

Even if you have not implemented TDE you can take advantage of this new format to compress your backups on the client, and keep them compressed throughout their lifecycle.

Best practice is to fully encrypt your backups, and is recommended to implement recipe #3.

1) In order to compress the contents of new blocks you need to set

RA_FORMAT=TRUE

The library will format new backups with compressed blocks, but the backups will NOT be encrypted

PROS of Recipe #4

All datafile backups sent from the protected database are compressed using less bandwidth.
Datafile backups are replicated in the compressed format. This uses much less WAN traffic when replicating backups to another datacenter, or into a Cyber Vault.
Datafile backups are restored in the compressed format. This uses less bandwidth during a restore operation. This is especially useful for concurrent DB restores when the network could become a bottleneck.
Does not require the creating of encryption keys (encryption is MAA best practice).

OPTIONAL

You can also take advantage of RMAN compression of archive logs.

When performing log sweeps, you can create compressed backupsets of archive logs. Using any algorithm other than basic requires ACO
When using real-time redo, you can utilize any compression algorithm without requiring ACO.

NOTE: If you are currently sending RMAN compressed backupsets to the ZDLRA because of bandwidth issues, this is a better alternative because the backupsets remain compressed throughout their lifecycle.

To summarize: