Guide
How to test a backup restore: a checklist for businesses
A backup job that reports success shows that software finished running. It does not show that you can get a working system back. A restore test is how you find out, while there is still time to fix what you learn.
Government cyber security agencies give the same advice on this point. The Canadian Centre for Cyber Security’s guidance on backing up your information says to test your backups regularly and to include recovery procedures and roles in your plans. The U.S. Cybersecurity and Infrastructure Security Agency’s #StopRansomware Guide recommends regularly testing the availability and integrity of backups in a disaster recovery scenario. This checklist turns that advice into steps a small or medium-sized business can actually follow.
Before you start: decide what the test is for
A restore test can answer different questions, so pick one for each exercise. Can a single file or folder be recovered? Can a whole server or virtual machine be brought back? Can an application be used again by real staff? The first is quick and worth doing often. The last is the one that tells you whether the business could keep running, and it takes more preparation.
Start with the system the business would miss first. If you have not ranked your systems yet, our guide to RTO and RPO explains how to describe how fast a system must return and how much recent work you can afford to lose.
The checklist
1. Restore somewhere safe
Never restore over the live system. Use a separate server, a spare virtual machine host or an isolated network segment, so that a mistake in the test cannot damage production data or leave a restored copy running beside the original.
2. Restore from a real, older recovery point
Choose a copy that is not the one made an hour ago. An older recovery point shows that retention works the way you think it does, and it is closer to what you would face after an incident that went unnoticed for a few days.
3. Confirm the data is usable, not just present
Seeing files on disk is not enough. Open the application, sign in as a normal user and check that recent records are there and that a few transactions or documents look right. For a database, confirm that the application can connect and read it.
4. Time it
Write down how long each stage took: finding the right copy, restoring it, and getting the application to a usable state. This is the evidence behind any recovery time target you have set. If the real number is longer than the target, the target was an assumption.
5. Check who and what the restore depends on
Note which credentials, encryption keys, licences, network settings and people were needed. A restore that only works because one person knew a password stored on the server being restored is a gap, not a pass.
6. Record the result and fix the gaps
Keep a short record: date, system, recovery point used, time taken, what failed and what changed afterwards. Then repeat the test after the fix. A test with no follow-up is only a report.
What actually goes wrong: notes from supporting Arcserve SPX
We have spent a long stretch resolving Arcserve SPX problems for customers, and the same few situations came up again and again. None of them show up as a failed headline status until you look closely.
- Backups that do not run. A specific disk error, or a system state or VSS (Volume Shadow Copy) error on the protected machine, stops the job from completing.
- Backups that run but cannot be trusted. The backup finishes, then verification fails, or consolidation of the incremental chain fails. A chain that cannot be verified or consolidated is a restore risk, even if yesterday’s job looked green.
- Restores that fail when you need them. The error appears only at restore time, which is the worst moment to meet it. Finding it in a test is the whole point of this checklist.
- Encrypted backups and a lost password. Many people set a password on the backup, which encrypts it. Without the correct password the backup cannot be unlocked. We always tell customers this up front: if the key is lost, the backup is gone. Store it somewhere other than the machine being protected, and make sure your restore test uses the password you actually have on record, not one someone remembers.
The other pattern worth naming is the virtual boot. Backup software can boot a backup image as a virtual machine, which is a very useful way to check that a system comes up. Some customers, though, booted the image, assumed it had been restored, and kept working inside it. Some time later they would come back, still running from that image, while the real system was down or had crashed. Their ongoing work lived in a virtual machine that was never meant to be the production system. In our experience a virtual boot is a test and a stopgap, not a reliable restore. Treat it as proof that the image boots, then do the actual restore.
What the backup design itself should look like
Testing can only prove the copies you actually have, so check the design as well. The Canadian Centre for Cyber Security recommends keeping at least one backup offline and disconnected from your network, storing a copy offsite, and following the 3-2-1 rule: three copies of your data, on two types of media, with one copy offsite. Its ransomware guidance adds that backups should be encrypted and stored offline without a connection to the Internet or local networks, because connected backups can be reached and damaged by the same attack.
That is guidance to design toward, not a guarantee that any particular setup will survive any particular incident. Immutable or air-gapped storage, for example, is configured differently by each vendor, and CISA cautions that cloud immutability options may not meet every compliance requirement and can be costly if misconfigured. Ask exactly how a copy is protected and who can delete it.
How often to test
The agencies above say “regularly” without fixing a number, because the right rhythm depends on the business. As a practical starting point, run a quick file-level restore on a routine schedule, and run a fuller system or application restore after any significant change, such as a new server, a major software upgrade, a change of backup product or a change of who is responsible for restores. Put the schedule in writing and give it an owner.
Next step
If you are not sure when your last real restore happened, that is a useful answer in itself. Excelytech’s recovery readiness review looks at critical systems, protection, dependencies, objectives and validation, and our Backup & Restore service covers on-site systems within an agreed scope. If you are in the GTA, see business backup in Mississauga, or talk to our team.
Sources: Canadian Centre for Cyber Security, Tips for backing up your information (ITSAP.40.002), June 2024; Canadian Centre for Cyber Security, Ransomware: How to prevent and recover (ITSAP.00.099), January 2026; CISA, #StopRansomware Guide.