In this post I will explain what typically happens when RMAN either compresses, or encrypts backups and how the new space efficient encrypted backup feature of the ZDLRA solves these issues.
TDE - What does a TDE encrypted block look like ?
In the image above you can see that only the data is encrypted with TDE. The header information (metadata) remains unencrypted. The metadata is used by the database to determine the information about the block, and is used by the ZDLRA to create virtual full backups.
Normal backup of TDE encrypted datafiles
First let's go through what happens when TDE is utilized, and you perform a RMAN backup of the database.
In the image below, you can see that the blocks are written and are not changed in any way.
NOTE: Because the blocks are encrypted, they cannot be compressed outside of the database.
Compressed backup of TDE encrypted datafiles
Next let's go through what happens if you perform an RMAN backup of the database AND tell RMAN to create compressed backupsets. As I said previously, the encrypted data will not compress., and because the data is TDE the backup must remain encrypted.
Below you can see that RMAN handles this with series of steps.
RMAN will
- Decrypt the data in the block using the tablespace encryption key.
- Compress the data in block (it is unencrypted in memory).
- Re-encrypt the whole block (including the headers) using a new encryption key generated by the RMAN job
You can see in the image below, after executing two RMAN backup jobs the blocks are encrypted with two different encryption keys. Each subsequent backup job will also have new encryption keys.
Compression or Deduplication
This leaves you with having to chose one or the other when performing RMAN backup jobs to a deduplication appliance. If you execute a normal RMAN backup, there is no compression available, and if you utilize RMAN compression, it is not possible to dedupe the data. The ZDLRA, since it needs to read the header data, didn't support using RMAN compression.
How space efficient encrypted backups work with TDE
So how does the ZDLRA solve this problem to be able provide both compression and the creation of virtual full backups?
The flow is similar to using RMAN compression, BUT instead of using RMAN encryption, the ZDLRA library encrypts the blocks in a special format that leaves the header data unencrypted. The ZDLRA library only encrypts the data contents of blocks.
- Decrypt the data in the block using the tablespace encryption
- Compress the data in block (it is unencrypted in memory).
- Re-encrypt the data portion of the block (not the headers) using a new encryption key generated by the RMAN job
In the image below you can see the flow as the backup is migrating to utilizing this feature. The newly backed up blocks are encrypted with a new encryption key with each RMAN backup, and the header is left clear for the ZDLRA to still create a virtual full backup.
This allows the ZDLRA to both compress the blocks AND provide space efficient virtual full backups
How space efficient encrypted backups work with non-TDE blocks
So how does the ZDLRA feature work with non-TDE data ?
The flow is similar to that of TDE data, but the data does not have to be unencrypted first. The blocks are compressed using RMAN compression, and are then encrypted using the new ZDLRA library.
In the image below you can the flow as the backup is migrating to utilizing this feature. The newly backed up blocks are encrypted with a new encryption key with each RMAN backup, and the header is left clear for the ZDLRA to still create a virtual full.
I hope this helps to show you how space efficient encrypted backups work, and how it is a much more efficient way to both protect you backups with encryption, and utilize compression.
NOTE: using space efficient encrypted backups does not require with the ACO or the ASO options.
