Why audit backups regularly

A backup that is not periodically verified can fail for silent reasons: the backup process ended with an error but the script didn't check the exit code; the file was saved to a path with almost no space; the encryption key changed and it can no longer be decrypted; retention deleted files before the expected period; or extensions or versions between source and destination changed.

A backup audit doesn't look for a snapshot of system state; it looks for evidence that the backup will work when needed.

Signs that backups have problems

  • The last successful backup is more than 24 hours old for critical databases
  • The backup script doesn't check the exit code and has never generated an alert
  • Backup files have abnormally small or uniform sizes (sign of empty backups)
  • No alerts are configured for when a backup fails
  • Nobody on the team remembers the last time a real restoration was tested
  • Transaction logs (SQL Server, Oracle) are not included in the backup strategy

Audit checklist — PostgreSQL

  • 1. Verify success of the last backup and its size
  • 2. Verify backup file integrity
  • 3. Verify WAL archiving status (for PITR)
  • 4. Verify that archive_mode is enabled if PITR is required

Audit checklist — SQL Server

  • 5. Verify recent backups per database
  • 6. Verify transaction log backups (for low RPO)
  • 7. Verify integrity of the last backup
  • 8. Verify if any backup is marked as damaged

Audit checklist — Oracle

  • 9. Verify recent RMAN backups
  • 10. List and validate backups from RMAN

General audit aspects (all engines)

  • 11. Verify storage location and physical separation The backup must not be on the same server as the database. Confirm there is at least one remote destination (cloud, external NFS, tape).
  • 12. Verify backup encryption Especially critical if backup storage is shared or in the cloud with broad access. Verify the decryption key is available in a location separate from the backup.
  • 13. Verify retention: not too short or too long without justification A 1-day retention may be insufficient to detect silent data corruption. A 1-year retention without an archival policy can grow to occupy terabytes without control.
  • 14. Confirm an automatic alert exists for failed backups A failed backup that nobody detects can leave the company without protection for days or weeks. The alert must be sent by email or monitoring channel with sufficient urgency to generate immediate action.
  • 15. Perform a monthly test restoration on an isolated server The only real test is to restore and verify that the data is correct and recovery time meets the RTO. Document the result of each test.
TERMINAL 
# Age of the latest full backup on disk
find /backups -name "*.dump" -mtime -1 -ls

Warning signs requiring immediate action

  • The last successful backup is more than 48 hours old for a production database
  • The backup process has been silently failing for days without generating alerts
  • A recent restoration test failed and there is no alternative valid backup
  • Backup storage space is above 90% and retention is not being applied correctly
  • Transaction logs (SQL Server) or WAL files (PostgreSQL) are not being archived, making PITR impossible

Frequently asked questions

What is the difference between verifying a backup and testing it?

Verifying a backup means checking that the file is not corrupted and can be read correctly (pg_restore --list, RESTORE VERIFYONLY, RMAN VALIDATE). Testing it means doing a complete real restoration on an isolated server and confirming that the database starts, the data is correct and the total recovery time meets the RTO. Only the real test guarantees the backup is useful when needed. Integrity verification is the minimum; restoration testing is the standard.

How often should I verify backup integrity?

Automatic file integrity verification should be done immediately after each backup. Complete restoration testing on an isolated server should be done at least monthly for critical systems. If time and resources allow, a weekly restoration in a staging environment is the best practice for business-critical systems.

Should backups be encrypted?

Yes, especially if they contain personal, financial or regulated data (Habeas Data, GDPR, PCI-DSS or SOC 2). An unencrypted backup stored on a shared file system or in the cloud exposes data to anyone with storage access. Encryption must be applied before transfer to the external destination, and the decryption key must be stored in a different place from the backup (secrets manager, HSM, or at least a separate repository).

How many days of retention are sufficient?

It depends on the RPO, regulatory requirements and error detection capability. For most systems: 7 days of daily backups allows recovering from an error detected up to a week later; 4 weeks covers monthly reporting cycles. Some regulators require retention of 1 to 7 years for financial or medical data. The policy must be defined with the legal and compliance teams, not just the technical team.

Related resources