Backups aren’t enough: how to prepare a restore test

The question nobody asks until it’s too late

“Yes, we have backups.” The answer reassures until the day they are needed and you discover the backup was incomplete, nobody knows how to restore it, or the last good one is three months old. The only way to know whether a backup is usable is to restore it.

What a restore test is

It is a planned exercise in which you take a real backup and restore it in an environment separate from production to verify that the system works again with the expected data. The UK NCSC recommends in its small organisations guide not only making backups but also checking that you can recover the data. NIST, in its contingency planning guide, includes testing as part of the plan.

Preparing the test

Isolation

A restored site can send emails, run scheduled tasks or connect to payment gateways. Before powering it on, disable outbound sending and external connections, or use test credentials. Restrict access to the environment: it contains real data.

Validate

• The system boots and the homepage loads.
• You can log in with a test user.
• The most recent records from the backup are present.
• Files and images are visible.
• A key operation works in test mode.

Measure the total time, from the moment the backup is requested until the system is validated. That number tells you how long it would take to resume operations.

Procedure

1. Choose the system and the specific backup to test.
2. Prepare an isolated environment.
3. Disable outbound sending and external connections.
4. Restore and note the time taken.
5. Validate using the agreed criteria.
6. Record evidence and findings.
7. Securely delete the test environment or restrict its access.
8. Schedule the next test.

Applied example

Limits

A successful test demonstrates that that particular backup could be restored at that moment. It does not guarantee that all future backups will work: that is why it should be repeated periodically.

How to use the downloadable log

1. One row per test.
2. Confirm the isolation.
3. Record times and criteria met.
4. Schedule the next test.

Criteria for a valid test

Complete synthetic example

Synthetic example. A fictitious service company has daily backups of its booking system. It schedules its first restore test on a temporary server with no public access and email sending disabled.

Restoring the database takes 40 minutes; restoring attachments fails because the backup did not include them. The system boots, but bookings do not show their documents. The company adjusts the backup to include attachments and repeats the test two weeks later: everything restores in 65 minutes and an operations person completes a test booking from start to finish.

They record both tests, determine that a full restore takes about an hour and schedule the next one for the following quarter. Example invented.

Common mistakes, explained

Restoring over the real environment to “save time” can overwrite current data. Restoring without disabling outbound sending can send duplicate emails or charges to real customers. And accepting a restore as good just because the system booted leaves unverified whether the data are complete. The test is only valid if it is checked against criteria defined before starting.

How to know if it worked

• The restore completed in an isolated environment.
• The validation criteria were met.
• The real restore duration is known.

Plan for the first four weeks

1. Week 1: define scope and criteria.
2. Week 2: prepare the isolated environment.
3. Week 3: restore and validate.
4. Week 4: fix findings and schedule the next one.

Diagnostic before starting

• Ask where backups are stored and how often they are taken.
• Ask when a backup was last restored.
• Define which system would be worst to lose.

A second example, by contrast

Synthetic example. A fictitious company restores its informational site without issues in 15 minutes. Its billing system, however, depends on an external provider that has never shown a restore. The test becomes a written request to the provider. Unlike the first example, this test did not depend on their team. Example invented.

What to do when something fails

• If the restore fails, do not touch the real environment: document the error and fix the backup.
• If it takes longer than tolerable, review the backup method.
• If data are missing, adjust what is backed up and repeat.

How to measure it with your own data

• Record the date, duration and outcome of each test.
• Note what was missing in each restore.
• Compare restore time with what your operation can tolerate without the system.
• Check whether corrections from the previous test were applied.

The comparison between successive tests is your best indicator. If each test restores more completely and in less time, the process is improving. If the time exceeds what your operation tolerates, the conversation is no longer about backups but about the recovery method, and that should be discussed with your provider with these records in hand.

Common mistakes

• Testing on production.
• Not disabling emails or charges in the restored environment.
• Validating only that “the page loads.”
• Not measuring time.
• Leaving the test environment open with real data.

Checklist

• Isolated environment.
• Outbound sending disabled.
• Validation criteria defined.
• Time measured.
• Next test scheduled.