Every morning the backup software sends a report with a green check mark. The disk is filling up, so something is being backed up. The person responsible for IT is calm, and so is the CEO. Then the accounting server fails, and it turns out the backups had been taken from a disk that had not held the database for half a year, because it was moved to another partition.
We have more than one story like this. What they share is that nobody ever tried to restore. A backup whose restore has not been tested is not protection, it is an assumption that protection exists. You learn the difference between the two at the worst possible moment.
The good news is that a restore test is not a week-long project. The core procedure fits in an hour, and its result is a document you can show to an executive, an auditor or an insurer. Below we describe how we do it.
Why a green check mark proves nothing
Backup software only confirms that the job finished without errors. It does not check whether:
- the right thing is being backed up (the database, not an empty folder for it);
- the backup is consistent (the database was not copied in the middle of a write);
- an operating system with all its drivers and licences will boot from the backup;
- the restore fits within the downtime the company can afford;
- anyone other than one administrator knows how to perform the restore.
In our practice each of these has at some point been the cause of a real incident. None of them is shown in the report.
There is another, less technical argument. Until a restore has been tested, one person knows about it, and only in theory. On the day of an incident that person may be on holiday, ill, or no longer with the company. A test forces the procedure to be written down and performed at least once by another member of the team, which is often more valuable than the result itself.
Three types of restore tests
Tests differ in scope, time and what they prove. You need all three, but not equally often.
File-level test
Pick a random file or email from last week’s backup, restore it to a separate folder and open it. It takes a few minutes. It proves that the backup chain works and the data is readable. It suits a weekly routine that any member of the IT team can perform.
Virtual machine test
A whole virtual machine (for example, the accounting server) is restored from the backup into an isolated network, started, logged in to, and checked: does the application start, and is the data from yesterday? It takes from 20 minutes to an hour depending on the size of the machine. It proves that a working system comes up from the backup, not just a set of files. This is the main test, and the one this article is about.
Full-system test
The entire infrastructure is restored: the domain controller, file server, accounting, email, and the connections between them. It takes half a day to a day. It proves that the company can operate from backups, not just that each machine comes up on its own. This is no longer a test but a recovery exercise, and companies in scope of NIS2 or DORA should run one at least once a year.
A procedure that fits in an hour
Here is the virtual machine test as we run it for our clients.
- Preparation (10 min). Choose one important system, ideally the one without which the company would stop first. Note the time you start. Prepare an isolated network: a separate virtual network with no connection to production, so that a restored domain controller or accounting server does not collide with the running one.
- Restore (20 to 30 min). Restore the virtual machine from yesterday’s backup into the isolated network. Veeam can do this directly from the backup repository, without waiting for the data to be moved to production storage. Record how long the restore itself took.
- Verification (10 to 15 min). Log in to the restored machine. Start the application. Open yesterday’s document or record. Check the status of services and the logs for startup errors. If it is a database server, run a simple query.
- Wrap-up (5 min). Destroy the restored machine in the isolated network. Write the report.
The result is not just a “works” or “does not work” answer, but a real restore time that you can compare with the downtime the company has defined as acceptable.
Why the environment must be isolated
A common mistake is to restore a server straight into the production network “just to check”. Two domain controllers with the same name, two DHCP servers, an accounting system restored with yesterday’s data that starts sending reminders to customers: we have seen all of it. A test that causes an incident is worse than no test at all.
An isolated network means a separate virtual network with no route to production, reachable only from the administrator’s workstation. In our cloud we keep such an environment permanently. It is the same place we use for PlanB infrastructure recovery, so the test also confirms that the recovery site works.
A report an audit will accept
A test without a document does not exist for an auditor. The report does not need to be long, but it must answer specific questions:
- Date, time, and who performed the test.
- Which system was tested, and from which day’s backup.
- Test type: file, virtual machine, or full system.
- How long the restore took and how long the verification took.
- What was checked and the result: passed, passed with remarks, or failed.
- Problems found and who is responsible for fixing them.
- When the next test is scheduled.
One page. We use the same template when preparing companies for NIS2 requirements. What matters most to an auditor is seeing that tests happen regularly and that problems found are addressed, not that every test succeeded.
How often to test
Our recommendation for a company with no separate regulatory requirements:
- File-level test: every week, rotating through systems.
- Virtual machine test: every month, a different system each time, so that all the important ones are covered within six months.
- Full-system exercise: once a year or after every major infrastructure change, such as a new server, a migration, or a change of backup solution.
For companies in scope of DORA, the frequency is dictated by their own ICT risk management policy, but an annual exercise is the minimum. If your backup solution supports automated restore verification (Veeam calls it SureBackup), turn it on. It does not replace a manual test, but every night it checks that a machine can boot from its backup at all.
What to do with the results
A failed test is not a failure but the best possible outcome: you found the problem, not the ransomware. Assign an owner and a deadline to each problem found, and repeat the test on the same system after the fix. Put the times from successful tests in a table. After a few months you will see which systems take longer to restore than the company can afford, and you can make an informed decision about more frequent backups or faster storage.
Where to start
- Choose one system without which the company would stop, and this week restore it into an isolated network using the procedure above.
- Record the result on one page and put the next test in the calendar.
- If the test failed, or you have nowhere to restore in isolation, do not delay: that is already a finding, not a routine.
- If you would like us to run and document the tests, this is a standard part of the Veeam backup service. Get in touch through the contact form and we will run the first test together.
