Backups that were never restored: how to find out if yours work

Most backup consoles report one thing: the job finished. It says nothing about whether the archive can be read, whether the right folders were inside it, or whether the accounts file was closed cleanly when it was copied. Plenty of offices have a tick beside every night for two years, yet nobody has ever opened one backed up file to prove the copy reads back.

The usual failures are dull. A new shared drive was never added to the job, and after a service password changed the job skipped one volume every night since spring without anyone noticing. The accounts database was copied while open. Without a volume shadow copy, a running database is copied half written and will not mount. The NAS volume filled up long ago. The console shows a disk full warning that nobody reads.

A restore drill finds these in an afternoon. It also gives you a restore time. The owner needs that figure on the morning the server will not start, with ten staff idle and customers waiting on quotations nobody can reach.

Do not try to restore everything. Choose three items that fail in different ways, so one afternoon exercises the whole chain: mailbox, shared folder and accounts data file, each copied by a separate backup task. Each breaks in its own way.

Choose a mailbox that holds real mail with attachments, and a folder that many people write to, such as the quotations or jobs folder. For the accounts file, ask whoever keeps the books which company file or database they would miss first, because their answer is rarely the one the installer assumed.

Ask the item’s owner to attend, because they know what a correct result looks like and will spot a missing quarter of invoices faster than a tool.

Never restore over the live copy; use a spare laptop, a scratch folder on the server or a test mailbox that nobody else touches while the drill runs. Start a stopwatch when you click restore. Stop it when the item opens.

Then open it the way a user would. Read the newest mail and the oldest. Check that attachments download and that a calendar entry from last year is still there, then open ten random files, including a large spreadsheet and a CAD drawing. Compare file counts and, if the tool offers one, a checksum of the biggest file with the live folder, then load the accounts file and compare its closing balance.

Write down each result on one sheet. A log turns a feeling into evidence. Next quarter’s drill can then be compared line by line, so a slow restore or a growing gap shows up as a trend, not a surprise.

Look at the gaps first. Missing folders point to a job scope problem. A missing nightly link stops the chain. Files that exist but will not open mean the copy was taken while the program held them open, a typical fate for accounting data. A mailbox that returns only the last thirty days points to a retention setting that nobody ever chose on purpose, and that nobody has read since the first week.

Then look at the clock. If the accounts file took four hours to come back and your accountant needs it by nine, that is a finding, even if every byte was intact. Recovery time is part of the backup. It is not an extra.

Do not let the person who set up the job quietly tidy a failed drill away, because a failure found now costs an afternoon. The same failure after ransomware costs weeks.

Give every gap an owner and a date. Add the missing drive to the job, move the accounts copy to run after closing time, extend the mailbox retention or shift the archive to a faster disk. Then repeat the failed restore. Keep going until the log shows a pass.

Book the next drill before closing this one. Rotate the items, so that a different mailbox and a different folder are tested each time and none stays unchecked for a year. This week, restore one file you deleted last month.