Backup and recovery checklist: will you actually get your data back?

Decide what “recovered” means

• For each system, agree on two numbers with whoever owns it: how much data you can afford to lose (RPO, e.g. the last 24 hours) and how long it can be down (RTO, e.g. one working day). They decide how often you back up and how you restore.
• Write down the order of recovery. Usually identity and network first, then the systems people need to work, then the rest.

Keep enough copies, in enough places

• Follow 3-2-1: three copies of the data, on two different kinds of storage, one of them off-site.
• Make one copy immutable or offline (object lock, immutable repositories, or media that is disconnected). Ransomware looks for backups to delete first.
• Aim for zero errors in the last check of every job, not “mostly green”.

Back up everything you would miss

• Servers and virtual machines, with application-aware backups for databases so they restore in a consistent state.
• Microsoft 365 and other SaaS: mail, OneDrive, SharePoint and Teams. The provider keeps the service running; the data, and recovering it from a deletion or an attack, is your side of the deal.
• Laptops if files live only there.
• Configuration: firewall and switch configs, DNS zones, and the documentation you would need to rebuild.

Protect the backups themselves

• Separate credentials for the backup system, with MFA, and not accounts from the same domain as the servers it protects.
• Alerts on risky changes: a job deleted, retention shortened, a repository removed.
• Keep the backup console off the general network where you can, and patch it like any other server.

Test restores on a schedule

• Restore something small often (a file, a mailbox item) and a whole system now and then, into an isolated network.
• Time it and compare with the RTO you agreed. A restore that takes three days doesn’t meet a one-day target, however good the backup is.
• Write down what you had to look up during the test and add it to the runbook.

Have a runbook you can reach in a crisis

Who decides to start a recovery, who to call, where the credentials are and the step-by-step for each system. Keep a copy outside the systems you are recovering: a runbook stored on the file server that is down doesn’t help.