Ransomware Recovery: Testing Backups and DR Drills

A backup is useful only when you can restore it under pressure. Ransomware operators target reachable backup servers, credentials, and management consoles, so critical copies need a different trust boundary from production. A locked object store or an immutable repository helps, but retention locks, deletion permissions, and recovery credentials still need testing. Offline and immutable copies solve different problems; use both where the data justifies the cost.

Start with a 3-2-1 plan: three copies, on two kinds of storage, with one copy off site. For a more resilient design, add a logically isolated copy and document who can release it. Restic, Borg, Veeam, and native database tools can all produce valid backups, though their restore workflows differ. A repository check is not a database restore. Test files, permissions, a complete database, and a bootable system image in an isolated network.

Write a Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for each service. If the RPO is 15 minutes, a nightly archive is not a solution. Map dependencies such as DNS, identity, secrets, storage, and licensing. A web application may restore cleanly while its database, object store, or authentication provider remains unavailable. Record the order of operations and the person authorized to make a failover decision.

A useful drill has two parts. Run a tabletop exercise that starts with a compromised administrator account, then perform a hands-on restore without production credentials. For example, restore a PostgreSQL dump into a quarantined network, verify row counts and application logins, and measure the elapsed time. For VM backups, boot a restored copy with network access blocked and check that services, certificates, and scheduled jobs behave as expected.

Keep the runbook beside an offline copy, not only in the system ransomware might encrypt. CISA and CERT-EU both stress recovery testing rather than backup-success dashboards. Record every missing permission, slow transfer, and undocumented dependency. Fix the runbook, rotate the drill credentials, and schedule the next restore before the incident fades from memory.