Guide · Backup

When did you last test a restore?

A backup that has never been restored is an assumption. A test procedure you can carry out in two hours.

By Dipl.-Ing. Mohamed Khater, Founder and Managing Director, since 1992 · 7 April 2026 · 7 min read

Why untested backups fail

A backup that has never been restored is not a backup but an assumption. You notice the difference on exactly one day – and on that day it can no longer be fixed.

The reasons restores fail are rarely spectacular. Usually it is one of five things: part of the data was never included in the backup. The database was copied while in use and is unusable. The encryption key is stored on the system that needs restoring. The backup job has been failing for months, but nobody reads the notifications. Or the restore works, but takes four days – and the business can only last two.

You can find out about all five in two hours. Finding out after an incident takes weeks.

Procedure

A test you can carry out in two hours

Not a full restore of the data centre, but a test that answers the crucial questions – and that can be repeated every quarter.

Restore a file from last week
The simplest case, and it fails more often than you would expect. Deliberately choose something from an area that is rarely touched – not what gets used every day anyway.
Restore a file from last month
This checks whether retention really goes back as far as you assume. The most common finding: the backup overwrites itself sooner than expected.
Restore a mailbox or a folder from Microsoft 365
The area most often not backed up at all. If you discover here that there is no backup, the test has already paid off.
Restore a database to a test system
The most important step for businesses with inventory management or other business applications. Don't just restore it – start the application afterwards and check that it accepts the data.
Time it
How long did each step take? Extrapolated to all your data, that gives you your actual recovery time. It is usually longer than assumed.
Record it in writing
Date, what was tested, how long it took, what didn't work. When you have to provide evidence, or deal with insurers, this log is the document that counts.

Decide in advance

Two figures you should know

They determine your entire backup strategy – and they are a business decision, not a technical one.

How much work can you afford to lose? If you back up at night, in the worst case you lose one working day. Work it out: hours times people affected times hourly rate. If the figure is acceptable, a daily backup is enough. If not, you need shorter intervals.
How long can it take to get back up and running? One day? Four hours? Two weeks? This determines whether a simple backup is enough or whether you need replacement hardware and a prepared procedure.
Both figures belong to management, not to IT. The technical implementation follows from them – not the other way round.
Check them against the most expensive week of the year, not the quietest month. An outage during year-end closing or peak season costs many times more.

Frequently asked questions

What we are often asked about this

How often should you test?

The short test described here every quarter, and a full restore to replacement hardware once a year. In addition, whenever something significant has changed: a new server, a new business application, a move to the cloud.

Regularity matters more than the interval. A test that is in the calendar happens – one that is supposed to happen when there's time doesn't.

Isn't it enough if the backup software reports success?

No. The success message only says that data was written – not that it is complete and can be restored. We have taken over environments where the job reported green for months while not capturing a key folder at all, because it had moved to a different location after a migration.

The success message is a necessary condition, not a sufficient one.

Does the test have to be done on real hardware?

Not for the quarterly test – that is about completeness and readability, which can be checked on a test system or in a virtual machine.

For the annual full restore, yes, because that is about time. How long does it take until you have a working system on new hardware? You can only measure that by actually doing it once.

Who should carry out the test?

Not only the person who set up the backup. Whoever built a system unconsciously checks the things they thought of.

Ideally, someone else works through it using the documentation. That way you test two things at once: the backup, and whether the instructions work for someone who wasn't involved.

What belongs in the log?

Date, who tested, what was restored, how long it took, what didn't work and what was changed as a result. One page is enough.

When you have to provide evidence under NIS2 or to clients, this log is exactly what is asked for – not the backup strategy on paper.

Dipl.-Ing. Mohamed Khater

Dipl.-Ing. Mohamed Khater founded INFONET Computer GmbH in Cologne in 1992. When we take over an IT environment and ask when a restore was last tested, we almost never get an answer with a date.