Backup and Disaster Recovery: Key Points

Backup and disaster recovery: key points

Core principle

High availability (cross-site clustering, replication, automatic failover) is not disaster recovery. Replication answers “one site died while the other is alive.” It does not answer “both sites are gone” or “the data was corrupted or encrypted, and that state replicated to the second site in under a minute.” Replication moves mistakes just as fast as it moves legitimate data. DR needs a copy outside the reach of both sites, one that production cannot overwrite.

Recommended approach

• Third in-country location holding an immutable copy. Not a third live datacenter, a backup vault with its own credentials and administration. Any modern backup platform with object-lock or WORM-style immutability works, regardless of vendor.

• Backup in layers, since no single layer is enough:

  • Fast rollback of a server or a whole site, for quick recovery from small issues.

  • Clean application backups per database and system, so a restore is consistent, not a snapshot frozen mid-transaction.

  • Platform-level backup, so application configuration can be restored, not just data.

  • Recordings and file storage backup, versioned so a deletion is recoverable.

  • An immutable copy in the third location, using credentials production does not hold.

  • A periodic offline copy, as a last resort, with ransomware detection on the backup tier itself.

• Recovery targets set per data type, not once for everything. Transactional data needs the fastest recovery. Recordings can tolerate more delay but need long retention. Reporting is usually rebuildable and can wait longest. Configuration should have near-zero loss since it is managed as code.

Key points for the customer

1. A snapshot alone is not a database backup. Pair every fast snapshot with a proper application-level backup.

2. The second site is high availability, not a backup. Corruption and ransomware reach it just as fast as legitimate data.

3. Backup and restore credentials must live outside the systems they protect, so a compromised production environment cannot reach or disable them.

4. Encryption keys must be backed up separately, under different custody, since a restored dataset without its keys is unrecoverable.

5. Immutable retention needs to outlast detection time. Breaches often surface weeks later, so recommend 90 days as a floor.

6. Recordings dominate storage volume and drive the sizing of the third location. Decide upfront whether to store all recordings or metadata plus a recent window.

7. The third location must stay in-country, since local data residency rules apply to backups the same way they apply to production.

8. Configuration should be backed up as code, not as images, so it can be redeployed by pipeline. Rebuilding beats restoring wherever possible.

9. Backups need their own monitoring, alerting on failed jobs, stale restore points and any change to protection policy.