One of the best features of the Zero Data Loss Appliance software release 23.1 is Space-efficient encrypted backups.  Most of the announcements, presentations and blog posts around this feature talk about the advantages for databases that are TDE encrypted.

NOTE: This feature is only available on Linux RDBMS version 19.18+ environments

Encrypting your Oracle Database by utilizing TDE is the MAA best practice,and because of this, the use of TDE is included in our cloud offerings without additional licensing. But what about customers who are not leveraging TDE or are not using Exadata Cloud@Customer, but want to ensure their backups are fully encrypted? Prior to now, the best solution for Oracle Database backup encryption was to implement TDE in the protected database which would ensure that the backups were encrypted. But, the use of TDE requires the Advanced Security Option and removes the ability for backup appliances to compress Oracle Database backups.

The 23.1 software release solves these issues with the new Space-efficient encrypted backup feature, especially if you are not using TDE today.

The image below shows the end-to-end flow of data as it is sent to the ZDLRA.

Software release 23.1 includes a new library for the client (libra.so) that makes this magic happen.  Using both Datafile compression, and RMAN encryption do not require either the ACO (Advanced Compression Option) or ASO (Advanced Security Option) when sending the backups to the ZDLRA.

To implement this feature you need to make the following 2 changes to your backup script.

1) RA_FORMAT = true

This is a new parameter that you will set on the channel configuration.  This tells the library to format ALL new datafile backups (incremental or full) in the new compressed format.  This will compress the contents of each block in the datafile backups leaving the block headers metadata intact to be read by the ZDLRA.

In the past, the only compression option was to turn RMAN compression on and RMAN compression would compress the backupset containing the datafile backups.  If the datafiles were TDE encrypted, RMAN compression would leave the resulting backup both compressed and encrypted, making it unreadable by the ZDLRA. If the datafiles were not TDE encrypted, RMAN compression would send the backupsets to the ZDLRA, where they would be uncompressed, and then stored on the ZDLRA compressed.

2) CONFIGURE ENCRYPTION FOR DATABASE ON;

Setting the RA_FORMAT=true on the channel configuration only tells the library to compress the block contents, and it will encrypt the block contents only for TDE datafiles.  If the source datafiles are not TDE encrypted, then you need to turn on backup encryption to have the library also encrypt the contents of the blocks in the datafile backups.  There are a number of items to note with setting encryption on in RMAN and using this feature.

• You must use have encryption keys set for the database, which includes keys for the CDB and all PDBs if your database is multi-tenant.  Those keys must be stored in a wallet or in an external keystore like OKV (Oracle supported Key management vault product).
• Setting encryption keys requires a database bounce, which can be done instance by instance when RAC is implemented. Keep this in mind when implementing this feature.
• If you only set backup encryption on, and set RA_FORMAT=true, and you have any datafiles that are not TDE encrypted, this will RMAN encrypt the entire datafile backupset, and it will not be readable by the ZDLRA.  ALWAYS include RA_FORMAT=TRUE when setting RMAN encryption on.
• When backing up, archive logs, the spfile, and the contolfile, these backup sets will be encrypted.  If you are not using TDE, and you own the ACO license you should also RMAN compress the archive logs for better storage utilization.  Keep decryption in mind when performing a full restore of the database. You must have the wallet open prior to restoring the spfile and controlfile backups.

NOTE: If utilizing Real-time redo

If utilizing Real-time redo, the redo associated with objects stored in non-TDE tablespaces will not be encrypted. Setting the ENCRYPTION attribute to ENABLE  on the LOG_ARCHIVE_DEST_x that points to the ZDLRA ensures that all redo data is encrypted before transmitting to the ZDLRA. The redo will stay encrypted on the ZDLRA and will be restored back to the database host encrypted.  The ZDLRA library will decrypt the archive logs during media recovery using the encryption key(s) maintained by the protected database.

You can find more information on this feature within the “Data Encryption Techniques” section of the ZDLRA administors guide.

Advantage of using Space-efficient backups with non-TDE databases

• Data is encrypted at the DB client with a unique encryption key for each database (including each CDB and PDB).  The keys are managed by the protected database and data stays encrypted throughout its lifecycle.  Having unique encryption keys ensures that any comprise of keys is isolated to single database
• Backups are both compressed and encrypted.  This gives you both advantages compared to deciding between 
  • TDE encrypt              – TDE encryption ensures that the database and backups are encrypted throughout their lifecycle.  Encrypted data does not compress and further compression of backups is not possible. Also this requires the purchase of the ASO license for non-cloud databases.
  • RMAN Compress       – The backupsets are compressed, but this leaves each backup unique.  When utilizing RMAN compression, the backups can not take advantage of any deduplication, and you need the ACO license to use the more efficient compression algorithms.
• The backups are stored, replicated, and restored compressed. This uses less storage, less bandwidth and reduces transfer times.

This provides a huge space savings advantage, reduces replication traffic, and can reduce restore times.

In the architecture below you can see that backups begin as both compressed, and encrypted and stay compressed and encrypted throughout their lifecycle.