How to verify your backups really work, not just run
- Author
- ESQRD team
- Published
- 20 Oct 2026
- Updated
- 5 Nov 2026
- Reading time
- 6 min read
- Available in
- EN · PL
Many companies make backups and consider the matter closed. The problem is that you find out a backup doesn't work on the day of an outage. Here's how to check in advance.
- 01Store copies on isolated media with separate credentials.
- 02Perform quarterly test restorations to measure actual downtime.
- 03Include settings, encryption keys, and SSL certificates in backup scope.
- 04Retain multiple historical versions to safeguard against ransomware encryption.
- 05Assign explicit ownership for backup oversight.
01Where your backups are stored
A backup stored on the same server as the data won't save you in a hardware failure or a breach. Keep at least one copy separate from the main system and with separate access, so that anyone who gets into your production servers can't delete it too.
02Try a restore
Once a quarter, restore your data in a test environment: check that the system starts and the data is all there. Write down how long it took. That way you know your actual downtime, not an estimate.
03Is everything you need being backed up?
Besides databases and client files, you need settings, email, keys, and certificates. These are the things most often forgotten, and without them a restored system won't work.
04How many versions to keep
Don't overwrite your only copy. Keep several versions so you can roll back to the state before a mistake or an infection, not just to yesterday.
05Who is responsible for checking
Assign an owner, decide how often to check, and set up an alert for when a backup fails. Without an owner, these checks stop happening over time.
NIST SP 800-34 Rev. 1: contingency planning for IT systems; CISA: backup guidance and the 3-2-1 rule; CERT Polska: ransomware protection recommendations.