Never Restored It? Then What You Have Is a Backup Job, Not a Backup

Every small office that has ever lost data had a backup, which is the part people find hardest to believe about the way these failures go. There was a green light on a dashboard, a nightly job reporting success, and an external drive filling up on schedule, and what there was not was any evidence that the contents of that drive could be turned back into a working office. The distance between a backup running and a backup working is where the losses live, and closing it costs one afternoon a year.

What a Successful Job Actually Verifies

Usually less than anybody would hope. Most backup software confirms that it read the source files and wrote something to the destination without throwing an error, which is a genuine check and is not the same as confirming that what was written is complete, uncorrupted and readable by any program other than the backup software itself. The common failures all sail through that check without difficulty.

A database backed up while running produces a file that copies perfectly and will not open. A folder excluded from the job three years ago by somebody who no longer works there stays excluded forever. Encrypted files get backed up faithfully with the key stored in the same place they were. And a cloud sync mistaken for a backup replicates a deletion within minutes of it happening, which is the modern version of the problem and the one people are least prepared for.

The Test, Which Is a Rehearsal Rather Than a Check

Pick a quiet day and treat it as a drill, because the point is not to prove the backup exists but to find out how long a real recovery takes and who in the building can perform one. Choose the things that matter rather than the things that are easy: the client database, the accounting file, the shared folder holding current jobs, the email archive. Restoring one document proves nothing useful about any of those.

Restore to somewhere else, meaning a spare machine, a separate folder or a temporary cloud instance, and never over the live copy, since a bad restore then destroys the working data as well. Open what you restored in the real application, launch the accounting program against the restored file, run a report, look at last month, because a file that exists and will not open is a failed restore and this is the step that catches it. Time the whole thing from the decision to restore through to having something usable, and have somebody other than the usual person do the work.

The Three Numbers a Rehearsal Gives You

Write them down afterward, since these are the things actually being managed. How much work would be lost, which is determined by how often the job runs, so a nightly backup means up to a day of work gone and for an office where the day's data is the business, nightly may not be sufficient. How long recovery takes, which is the number you just measured rather than the one somebody guessed. And whether anything cannot be restored at all, which is the unpleasant finding and the entire reason to run the exercise on a quiet Tuesday rather than during an emergency.

What These Tests Usually Turn Up

The same handful of problems, in practice. Something important was never in the job, usually because it moved at some point and nobody updated the selection. The backup destination is permanently connected, which means anything that encrypts the live files reaches the backup too. There is no offsite copy at all, so a fire or a theft takes both. Retention is set so short that a problem noticed three weeks later has already aged out of every copy that exists.

The last one deserves its own space, because it is the failure that turns a recoverable event into a total loss. Credentials and encryption keys stored only inside the system being backed up amount to a locked box with the key sealed inside it. Whoever runs the restore needs the account credentials and the encryption passphrase from somewhere other than the machine that just failed, and printing them and keeping them in a safe is not old fashioned in this context. It is the correct answer.

Why Rehearsal Is Treated as a Control of Its Own

Keep more than one copy, on more than one kind of storage, with at least one of them somewhere else and not permanently connected. Cloud backup handles the offsite part for most small offices, while a rotating external drive living at somebody's house handles it for those who prefer physical control. Whichever arrangement you pick, the disconnected copy is the one that survives the modern failure mode, since software encrypting everything it can reach cannot reach a drive sitting in a drawer.

An untested recovery procedure is an assumption rather than a control, which is precisely why restoration testing appears as a requirement in its own right in the security frameworks the National Institute of Standards and Technology maintains for federal systems, instead of being folded quietly into the line about keeping backups. The same logic scales down to a four person office without any modification at all.

Put it in the calendar twice a year, name the person responsible, and keep a one page record of each rehearsal: the date, what was restored, how long it took, what failed and what was changed afterward. That page takes ten minutes to write and it is what makes the following test faster. Offices that do this stop worrying about backups, which is the real benefit and a larger one than it sounds. Not that nothing will go wrong, but that when something does, the recovery is a procedure the office has already walked through rather than one it is attempting for the first time with everybody watching.