Introduction

A successful RMAN backup job does not automatically mean that the database can be recovered.

A backup strategy should answer two questions:

  1. Did the backup complete?

  2. Can the backup actually be used for recovery?

RMAN provides several commands for validating backup files, database blocks, archived redo logs, and recovery operations.

Check RMAN Backups

Start by reviewing the backups known to the RMAN repository.

LIST BACKUP SUMMARY;

This provides a high-level view of available backup sets and pieces. For more detailed information:

LIST BACKUP;

Useful information includes:

  • Backup type
  • Completion time
  • Backup piece
  • Datafile
  • Archived redo
  • Status
  • Checkpoint information The RMAN repository tells you what RMAN knows about the backups. It does not by itself prove that every backup file is currently accessible.

Crosscheck Backups

RMAN can compare the repository information with the physical backup files.

CROSSCHECK BACKUP;

For archived redo logs:

CROSSCHECK ARCHIVELOG ALL;

If RMAN cannot find a backup file that the repository expects, the backup may be marked as EXPIRED. You can review expired backups with:

LIST EXPIRED BACKUP;

Expired backups should be investigated before relying on them for recovery.

Validate the Database

RMAN can validate database blocks without performing a restore.

VALIDATE DATABASE;

This checks the database files for physical corruption. You can also validate specific datafiles:

VALIDATE DATAFILE 1;

Multiple datafiles can be specified when required. Validation is useful for detecting corruption before a recovery operation is required.

Validate Backup Sets

Existing backup sets can also be validated.

VALIDATE BACKUPSET ALL;

This checks whether RMAN can read the backup data. It is useful when you want to verify the integrity of existing backup sets without performing a full restore.

Check Archived Redo

Archived redo logs are an important part of database recovery. A database backup may be unusable for a required recovery point if the necessary archived redo is missing. RMAN can validate archived logs with:

VALIDATE ARCHIVELOG ALL;

You should also review the archived redo known to RMAN:

LIST ARCHIVELOG ALL;

The recovery chain depends on having the required archived redo available.

Backup Completion Is Not Recovery Validation

Consider a backup job that reports:

Backup completed successfully

This confirms that the backup operation completed. It does not necessarily confirm:

  • The backup files are still available
  • The backup pieces are readable
  • Required archived redo exists
  • The recovery chain is complete
  • The backup can be restored within the required recovery time This distinction is important. Backup success and recovery readiness are different things.

Validate Restore Operations

For important databases, validation should go beyond checking backup metadata. A restore test can be performed in a suitable test environment. For example:

RESTORE DATABASE VALIDATE;

This checks whether RMAN can identify and read the backups required to restore the database. It does not actually restore the database. This makes it useful for testing restore feasibility without replacing the existing database files.

Restore and Recovery Testing

A stronger form of validation is an actual restore and recovery test. A typical recovery test can include:

Backup
   |
   v
Restore
   |
   v
Recover
   |
   v
Open / Validate
   |
   v
Application Check

The exact procedure depends on the database architecture and recovery requirements. A test restore should verify that the backup can be converted into a usable database within the required recovery time.

Recovery Point

Recovery validation should also consider the required recovery point. For example, if the business requires recovery to within a few minutes of failure, the available archived redo must support that requirement. Questions to consider include:

  • How frequently are archived logs generated?
  • Are all required logs available?
  • Are logs being backed up?
  • Are backups stored separately from the database host?
  • How much data can be lost according to the recovery requirement? A backup without the required redo may not provide the expected recovery point.

Recovery Time

Recovery capability is not only about whether the database can be restored. It is also about how long recovery takes. Consider:

  • Database size
  • Backup location
  • Network bandwidth
  • Storage throughput
  • Number of datafiles
  • Incremental backup strategy
  • Archived redo volume
  • Recovery processing time A restore that works but takes significantly longer than the required recovery window may not satisfy the recovery requirement.

TDE and Recovery

Encrypted databases require additional consideration during recovery. For databases using Transparent Data Encryption, the required wallet or keystore must be available as part of the recovery process. A database backup alone may not be sufficient if the required encryption keys cannot be accessed. Recovery procedures should therefore include the dependencies required to access encrypted data.

A Simple RMAN Validation Flow

A regular validation process can follow this sequence:

LIST BACKUP
     |
     v
CROSSCHECK BACKUP
     |
     v
VALIDATE BACKUPSET
     |
     v
VALIDATE DATABASE
     |
     v
RESTORE DATABASE VALIDATE
     |
     v
Test Restore and Recovery

Each step provides a different level of confidence.

Example Validation Commands

A DBA can use the following commands as a starting point:

LIST BACKUP SUMMARY;
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
LIST EXPIRED BACKUP;
VALIDATE DATABASE;
VALIDATE BACKUPSET ALL;
VALIDATE ARCHIVELOG ALL;
RESTORE DATABASE VALIDATE;

The exact commands used should be adapted to the backup strategy and database architecture.

Keep Evidence of Recovery Tests

A recovery test should be documented. Record information such as:

  • Backup used
  • Backup completion time
  • Restore start time
  • Restore completion time
  • Recovery start time
  • Recovery completion time
  • Archived redo used
  • Errors encountered
  • Final database state This creates evidence that the recovery procedure has actually been tested.

Conclusion

RMAN backup validation is more than checking whether a backup job completed successfully. A reliable recovery strategy should verify: Backup → Integrity → Availability → Restore → Recovery CROSSCHECK helps verify backup availability. VALIDATE checks backup and database integrity. RESTORE DATABASE VALIDATE helps confirm that RMAN can identify the backups required for a restore. An actual restore and recovery test provides an even stronger level of confidence. The real test of a backup is not whether RMAN created it. It is whether the database can be recovered when it is needed.