ZDLRA Validation is your best protection against Ransomware

 Validation of Oracle backups on ZDLRA is often one the most overlooked features of the product. With the rise of ransomware, the question "how to I ensure that I have validated Oracle backups" is critical.

I know there are a lot of vendors out there that provide a great solution for most generic backups. But, as you probably know, Oracle Database backups are different from other system backups and they provide unique challenges which include

• The backup of a large database consists of 100s, if not 1000s of backup pieces. All of which are necessary to successfully restore the database.
• Oracle Database backups won't contain "ransomware signatures" or any easy way of determining if the backup pieces are tainted.
• Oracle Database backups are in a proprietary format that can only be validated by performing a "restore validate" which reads, and validates  the contents of Oracle database backup pieces.

How ZDLRA provides superior validation

Backups land on flash during ingest

When backup pieces are sent to the ZDLRA during backup, they land on Flash Storage and are quarantined  within the ZDLRA waiting to be validated.  

Backup pieces are validated

The ZDLRA will then examine arriving backup pieces.  The internal metadata is read and the contents of the backup pieces are validated block-by-block.  This ensures that before storing the backup pieces, they are confirmed to be Oracle Database backup pieces, containing valid Oracle Blocks.

 Backup pieces are stored and virtual full created

Once the backup piece is examined, and the metadata is read, the individual validated blocks are stored on disk compressed.  The blocks are indexed, and a virtual full backup is built.  The final step in the process is to update the RMAN catalog on the ZDLRA with an entry pointing to the virtual full.

Weekly validation for both block content, and restore continuity

On a weekly basis all backups on the ZDLRA undergo a "restore validate" which will validate that all the backup pieces are valid, usable backup pieces. This is critical with an "incremental forever" strategy to ensure that unchanged blocks are valid.  Along with checking for the integrity of the backup piece, the ZDLRA also checks for "Restore Continuity". I know this a term I made up. The idea is that whatever time/SCN you choose within the recovery window, the ZDLRA ensures that ALL backup pieces needed to recover are available.  This is similar to performing a "restore preview" of all time periods to ensure that all backup pieces are available for recovery.

Validation during replication

Replication of backup pieces from one ZDLRA to another takes this process one step further.

Along with all the same validation that  occurs when the ZDLRA receives backups from databases,  the upstream ZDLRA also catalogs the replicated copy of the backup pieces.

ZDLRA in a Cyber vault

This is where all the pieces come together. The ZDLRA not only utilizes it's validated, incremental forever strategy to keep replication traffic to a minimum, but it also ensures that backups pieces are validated PRIOR to cataloging them.

The ZDLRA has a number of advantages in a Cyber vault scenario

• Replication traffic is much smaller than most solutions which require a Weekly Full backup. The ZDLRA uses incremental forever.
• Backup pieces are quarantined after arrival in the vault to ensure tainted backups are not included in restore plans. This process is similar to what other vendors do to check for ransomware. The ZDLRA goes one step further by using the proprietary knowledge of Oracle Blocks to ensure all backup, and blocks within the backups are valid.
• Backups stored within the ZDLRA in the vault are validated on a weekly basis for both content, and continuity to ensure a restore will be successful.
• The upstream sending the backup pieces catalogs what backups are in the vault, and can resend any backup pieces if necessary.

I hope this helps you understand better why the ZDLRA provides superior ransomware protection.