Test your restore: why an untested backup is not enough

Many people discover that their backup does not work at the worst possible moment: when they need it. The program appeared to be running, the icon was green, yet the files they need are not there, or they are there but in a version from months ago, or the external drive is no longer recognized. A backup is only worth something if it lets you restore, and the only way to know is to try it before you really need it.

What can go wrong without you noticing

The most insidious failures are silent ones. Some examples that come up often:

• Excluded folders. The backup copies «Documents», but the important files ended up on the desktop or in a folder created later, not included in the selection.
• Backup stopped for months. The external drive was left unplugged, the cloud service reached its storage limit, the account password changed and the program can no longer authenticate.
• Open or locked files. Databases, mail archives or program files open during the backup may be copied incompletely.
• Degraded media. An old external drive may have unreadable sectors exactly where the file you need is stored.
• Forgotten password or encryption key. An encrypted backup without its key is unusable.
• Unreadable format. Some programs save backups in proprietary formats: without the software, or with an incompatible version, the data will not open.

Three levels of verification

1. Checking the logs

The quickest check is to look at the backup program's log: date of the last successful run, any warnings, number of files copied. It takes a minute and should be done often, for example during the weekly review. Many programs can also send a notification when something fails: turn it on.

2. Restoring single files

Once a month, pick two or three files at random, of different types and in different folders, and restore them to a separate folder, not over the originals. Then open them: a photo, a text document, a spreadsheet. Check that:

• the file exists in the backup;
• the version is recent;
• it opens correctly and its content is intact.

Also try to recover a previous version of a recently modified file: that is what you will need after a human error or an attack that encrypts files.

3. The full restore

Once or twice a year it is worth simulating the worst-case scenario: the computer is gone. The questions to ask:

• On a different computer, can I access the backup?
• Do I remember the cloud service credentials and the encryption key, or know where to find them?
• How long does it take to download or copy everything?
• If I use a system image, do I have a working boot medium?

You do not need to actually restore everything onto another computer every time: it is enough to check that access is possible, restore a meaningful folder and estimate the time.

A written procedure

In an emergency you are under stress and mistakes come easily. A written page, kept outside the computer you are backing up, for example printed or on another device, makes the difference. It should contain:

Logging your tests

Keep a short log of the tests you run: date, files restored, outcome, any problems. It reminds you when you last checked and helps you spot recurring problems. It can be a simple note or a row in a spreadsheet.

After a problem

If a test fails, it is not a failure: it is exactly why you run tests. Fix the cause, for example by adding the missing folder, replacing the drive or updating the credentials, run a new full backup and repeat the test.

In short

• A backup is only worth something if it lets you restore, and it must be tested before you need it.
• The most dangerous failures are silent: excluded folders, stopped backups, lost keys.
• Check logs often, restore single files monthly, simulate a full restore once or twice a year.
• Keep a written procedure outside the computer being protected.
• Log your tests and fix any problem you find right away.