Backup and disaster recovery: 3-2-1, ransomware, and the restore you never tested

Disaster recovery is a technology recovery discipline tied to business impact. It identifies critical systems, dependencies, recovery sequence, recovery time objective, recovery point objective, backup architecture, identity dependencies, and validation steps before returning service to users.

Backups support DR but are not the same thing. A nightly database dump, storage snapshot, SaaS recycle bin, immutable object copy, and warm standby all create different recovery options. The right mix depends on business tolerance for downtime and data loss, not on what the storage platform makes easy.

DR planning should include dependency order, not only system priority. A customer portal may depend on identity, DNS, certificates, secrets, databases, message queues, object storage, monitoring, and support tooling. Restoring the application without those dependencies is not recovery, so test plans need to prove the chain can be rebuilt in the right sequence. The same dependency map should identify manual workarounds, customer communication triggers, and finance or support processes that continue while systems are unavailable. Otherwise a technically successful restore can still leave the business unable to operate.

The checklist cannot choose honest RTO and RPO values. The business must decide how long each process can be down and how much data can be lost. Technology teams then need to show whether current backup frequency, replication, staffing, and dependencies can meet those numbers.

It also cannot decide how much isolation is enough. Separate credentials, immutable copies, offline storage, separate accounts, and restricted backup administration all reduce ransomware risk, but they add cost and operational complexity. Leadership must choose the resilience target.

The checklist will not decide whether SaaS-native recovery is sufficient. Many SaaS platforms offer retention, recycle bins, or point-in-time features that do not equal full business recovery. Teams must decide when exports or third-party backups are needed.

The most common failure is never restoring. Reports show successful backup jobs, but no one has rebuilt a service, recovered a tenant, restored a database to a clean environment, or validated application integrity. Until restore is tested, the backup is an assumption.

Ransomware exposes identity coupling. Backup administrators use the same Active Directory, SSO, privileged accounts, and management network as production. When the attacker owns identity, they can delete, encrypt, or disable recovery paths before defenders understand the blast radius.

Teams also forget SaaS data and make impossible promises. They claim minute-level RPO while running nightly backups, or they assume a SaaS vendor can export usable data quickly during an outage. DR credibility depends on reconciling promises with actual mechanics.

Restore tests fail when nobody defines acceptance. A database may restore but lose recent transactions, an application may start with broken integrations, or a SaaS export may be readable only by engineers. Business owners should validate whether recovered data is complete enough to operate, not merely whether an IT job completed.

Start with business services, not backup tools. List critical processes, systems, dependencies, owners, RTO, RPO, recovery order, and manual workarounds. Then use the checklist to validate whether backup design and restore procedure support those targets.

Run restore tests that prove the important paths. Include identity recovery, clean-room restoration, database consistency, application dependencies, SaaS exports, privileged access, and user validation. Record timing and gaps rather than only pass or fail.

Use the checklist after major architecture changes, new SaaS adoption, identity redesign, and ransomware exercises. DR is perishable because dependencies change faster than annual continuity documents. Keep restore evidence with timestamps, owners, defects, and retest results so leadership can see whether resilience is improving or simply being asserted. Include the business validation result, because technical restoration is incomplete until users can perform the critical process under realistic pressure with current data. The best tests also record what manual workaround kept customers served while restoration was underway and who approved the temporary operating mode.