For databases that require encrypted backups, the effect on compression, deduplication, and key access must also be considered. RMAN creates compressed encrypted backup sets, but the database host performs the work and the resulting backup format is largely opaque to storage compression and deduplication processes, increasing overall storage consumption.

Why backup encryption changes backup usage

Ransomware operators target backups because disabling recovery increases leverage. CISA** recommends offline, encrypted backups and regular restore testing, while the UK NCSC*** expects AI-assisted reconnaissance, exploit development, and social engineering to increase attack frequency and intensity. Encryption protects confidentiality after exfiltration, but it changes the backup data path and must be designed together with recovery.
**CISA StopRansomware Guide
***UK NCSC Impact of AI on Cyber Threat to 2027

Oracle Zero Data Loss Recovery Appliance (ZDLRA) is an Oracle-engineered, database-aware backup and recovery platform that extends RMAN into a centralized protection architecture. The focus is continuous recovery readiness at enterprise scale & not simply the storage and retention of backup copies. For encrypted data, ZDLRA integrates with RMAN to achieve space-efficient encrypted backups, preserving database-aware protection and encryption keys without inflating backup storage needs.

Let’s explore three common data protection patterns and see how architecture choices – with and without ZDLRA – shape data storage & security outcomes.

Protection pattern A – Fully TDE encrypted database

Without ZDLRA. TDE datafile blocks remain encrypted in conventional RMAN backup pieces. RMAN can compress before encryption, but compression and encryption consume database-host CPU, and the resulting encrypted backup format limits any storage-based compression benefits.

With ZDLRA. Use RA_FORMAT with RMAN encryption and compressed backup sets. RMAN decrypts TDE blocks in memory, compresses them, re-encrypts them with a data encryption key (DEK), and constructs a backup compatible with ZDLRA’s unique incremental-forever and virtual full technologies.

CONFIGURE ENCRYPTION FOR DATABASE ON; -- persistent
-- or, inside a single RMAN job:
SET ENCRYPTION ON;
BACKUP DEVICE TYPE SBT INCREMENTAL LEVEL 0 CUMULATIVE FILESPERSET 1 DATABASE PLUS ARCHIVELOG NOT BACKED UP FILESPERSET 32;
  • Redo and keys. Set ENCRYPTION=ENABLE on the Recovery Appliance LOG_ARCHIVE_DEST_n. Preserve every historical TDE master key needed by retained backups; rekeying does not make old keys disposable.
  • Secure-mode set on protection policies enables ZDLRA to reject unencrypted backups and redo, enforcing consistent encrypted backup strategy for all database files.

Protection pattern B – Non encrypted database with encrypted backups

Without ZDLRA. Use RMAN transparent, password, or dual-mode backup encryption. Add AS COMPRESSED BACKUPSET when network or destination capacity justifies the CPU cost; the source datafiles stay clear. 

With ZDLRA. Create and open a TDE keystore even though the datafiles are not TDE encrypted, then combine RA_FORMAT with whole-database RMAN encryption. RA_FORMAT compresses and encrypts all data file blocks

CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE DEVICE TYPE SBT_TAPE BACKUP TYPE TO COMPRESSED BACKUPSET;
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
  • Secure-mode protection policies enables ZDLRA to reject unencrypted backups and redo, enforcing consistent encrypted backup strategy for all database files.

Protection pattern C – Partially encrypted database

A mixed database should not inherit a mixed backup policy. 

Without ZDLRA, TDE protects only encrypted tablespace blocks; use whole-database RMAN backup encryption if every backup piece must be confidential. 

With ZDLRA, combine CONFIGURE ENCRYPTION FOR DATABASE ON with RA_FORMAT. Encrypted blocks are decrypted, compressed, and re-encrypted; clear blocks are compressed and encrypted. The result is an auditable encrypted backup with space-efficient processing.

CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS '... ENV=(RA_FORMAT=true, ...)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_n='SERVICE=... ENCRYPTION=ENABLE ...';
  • Recommendation. Avoid using tablespace-only RMAN backup encryption as the enterprise control: new or clear tablespaces can fall outside the intended boundary. 
  • Secure-mode protection policies enables ZDLRA to reject unencrypted backups and redo, enforcing consistent encrypted backup strategy for all database files.

Comparing Traditional RMAN with ZDLRA space efficient backups

ZDLRA value for encrypted data

  • Smaller encrypted payloads: With RA_FORMAT, Oracle blocks are compressed before encryption, reducing network and replication traffic. Traditional encrypted RMAN pieces provide little opportunity for downstream compression or deduplication.
  • Space-efficient protection: ZDLRA stores a level 0 seed and subsequent level 1 changes, creating virtual full backups without repeatedly storing physical encrypted fulls.
  • Oracle-aware recovery: Block metadata remains available for validation, incremental-forever processing, replication, and recovery, even though the backup data remains encrypted.
  • Centralized enforcement: SECURE_MODE rejects unencrypted backups or redo, while real-time redo provides transaction-level protection, reducing data loss exposure between scheduled backups.

To sum up

Encryption strengthens data protection but changes backup storage, performance, redo, and key-management requirements – this calls for re-thinking of overall backup strategies and goals. Traditional RMAN encrypts backup sets, while ZDLRA adds space efficiency, virtual fulls, database-level policy enforcement, and continuous transaction-level protection. With the RMAN and ZDLRA combination, databases can leverage compressed encrypted backups without compromising RTO and RPO, resulting in more secure and reliable recovery.