Test a backup by restoring one real system into a separate environment, timing it, and checking that the data is usable. Do it twice a year. A small team can finish a first test in about two hours. Also check that at least one copy sits where malware on your network cannot reach it.
Why test
The FTC small business guidance on ransomware says to restore from offline backups. That works only if the offline copy exists and works. Many teams find out during an incident that backups were failing silently, were missing a database, or needed a key nobody can find.
Pick the scope
Start with the system you could not live without: your production database, your source code, your identity provider export, your key documents. Do not start with everything.
The two hour test
- Choose one backup, ideally an older one, such as last week's.
- Spin up a clean environment, separate from production.
- Restore from the backup using the documented steps. If steps do not exist, write them as you go.
- Check the data: row counts, a sample customer record, the latest file date, application starts and can log in.
- Time the whole thing from start to usable.
- Write down the problems and fix the top two.
What to measure
How long recovery took, and how much data was missing compared with the moment of failure. These two numbers tell you how much downtime and data loss you could suffer, and lets you decide if that is acceptable.
Protect the backup itself
Keep at least one copy offline or immutable, in a different account or location. Use separate credentials from your production admin. Limit who can delete backups, and alert when a backup job fails or when backups are deleted. Keep encryption keys somewhere you can reach even if production is gone.
SaaS data is not backed up for you
Many teams assume their SaaS tools hold their data safely. Check each provider's retention and export options, and export critical data on a schedule where you can.
Document the runbook.
A one page restore runbook with commands, locations and who holds the keys turns a stressful day into a checklist. Store a printed or offline copy.
Common pitfalls.
Common mistakes: backing up only the database and not the files, config and secrets needed to run it; keeping the only copy in the same account an attacker would control; and writing the runbook after the incident. Another is testing only the backup tool's success message. A green status means the job ran, not that the data is usable. Finally, do not restore into production for a test. Use a separate environment, and delete it afterwards so that test data does not linger.
Write the result in one paragraph: what you restored, how long it took, what failed and who will fix it by when. That paragraph is the evidence you show a customer who asks about backups.
Quick check
How often should we test?
Twice a year is a reasonable start for a small team, and after any major infrastructure change.
Sources
Last reviewed: 19 October 2026.
