Guide · Recovery
Testing restores: only the test makes a backup
In short: “backup successful” only means that data was written – not that a system will start from it again. Only a regular, documented restore test shows whether a backup holds up in an emergency. It is most reliable when it runs automatically.
Why backups fail in an emergency
Most failed restores have unspectacular causes that no success message reveals:
- A new hard disk or a new drive was never added to the backup.
- The database was backed up in the middle of writing and does not start cleanly.
- The key for an encrypted backup can no longer be found.
- A folder has shrunk unnoticed over months because an application stores its data elsewhere.
- The virtual machine starts but hangs at an error screen.
- Nobody remembers in which order the systems have to start.
What a good restore test checks
| Stage | What is checked | What it finds |
|---|---|---|
| Data readable | Every stored object is read and compared with its checksum | Damaged or missing data in the store |
| Restorable | The backup is restored in full to a test area | Missing parts, wrong keys, too little space |
| File system intact | Every file system is checked and mounted | Inconsistent backups, defective partitions |
| Content plausible | Every file is read, files and data volumes are counted and compared with the last test | Unreadable or unnoticed changed files, shrunken, empty or outdated areas |
| Free of ransomware traces | Files are examined for signs of encryption: content does not match the extension or looks random, typical extensions and ransom notes | Backups that already contain encrypted data |
| System starts | The virtual machine boots in an isolated environment | Systems that do not boot, error screens |
| Service responds | A service such as the directory, mail or database accepts connections | Systems that start but do not work |
How often to test?
There is no statutory interval, but laws such as NIS2 and the GDPR require regular testing of the measures. The following has proven itself:
- Daily to weekly: a check of the stored data, for large stores only of the newly added data.
- Weekly: a spot check – a few randomly chosen backups are restored in full and started.
- At least once a year: a test of the most important systems in the right order, with the time until they are working again measured.
More important than the frequency is that every test is documented: when, which backup, which result. A test without evidence does not count in an audit.
Testing without risk to operations
A restored machine must never talk to the real network: a second domain controller or mail server with the same name can cause great damage during live operation. That is why check restores belong in an isolated environment – without a network or in a network of their own with no connection to the outside. Dependent systems start there in the right order, for example first the domain controller, then the mail server.
How AegisGrid automates this
The AegisGrid backup server runs the check restore as a workflow, for example every Saturday morning on three randomly chosen backups: restore, check the file systems read-only and mount them, read every file and compare with the last check, start virtual machines in an isolated QEMU/KVM environment, check whether they show a picture, write to their disks or their services respond, and clean up afterwards. The check report arrives by email with a traffic light per disk and partition and screenshots of the started machines; every test is recorded with its result in the signed evidence log and in the monthly report.
Frequently asked questions about restore tests
Is it enough to verify the backup's checksums?
No. A checksum check shows that the stored data is unchanged. Whether the backup is complete and a system starts from it is shown only by a restore.
Does a check restore need its own test environment?
It needs storage space for the restored data and, to start virtual machines, a computer with hardware virtualisation. The AegisGrid backup server brings the isolated environment with it; a separate test infrastructure is not needed.
Can encrypted backups be tested as well?
Yes, the testing server needs the key for that. Without the key, checking the stored data, mirroring and cleaning up remain possible.
See a check restore on your systems
In a pilot project we restore your backups as a test – with a report and screenshots.