Backup Ran Successfully Last Night? Five Checks That Prove It Would Actually Restore

The green checkmark on a backup dashboard reports one thing only: that a process ran to completion without throwing an error it recognized. It does not report that the files are readable, that the encryption key still exists, that the copy was not silently overwritten by an infected version, or that anyone left at the organization knows the password. Every one of those failures produces a successful-looking job. People who have run restores for a living tend to develop the same small set of habits, and they all amount to converting an assumption into a test performed on a calendar, in advance, by someone who writes down what happened.

One: restore a real file and open it in the real application

A verification pass inside backup software usually compares checksums, which proves the bytes on the destination match the bytes that were read. That is worth having, and it is not the same as proving the file works. The test that matters is pedestrian: pick a file that someone actually depends on, a payroll workbook, a client database, a folder of scanned closing documents, restore it to a scratch location, and open it in the program that created it. If it is a database, attach it and run a query. If it is a virtual machine image, boot it and log in.

Do this on a schedule rather than when you feel uneasy, and do it with files from different ages: one from last night, one from a month ago, one from the oldest retention point you claim to hold. Older restore points fail more often than recent ones, because the software version that wrote them has moved on, because the storage aged, or because a retention policy quietly pruned what someone believed was being kept. Write down the date, the file, and the result. Three lines in a shared document is enough, and it is the only evidence that will survive staff turnover.

Two: prove one copy is genuinely out of reach

The rule most practitioners still work from is three copies of the data, on two different kinds of media, with one copy held somewhere else. Ransomware pushed a fourth clause into common practice: one copy that cannot be modified or deleted by the credentials used on the production network. That means immutable object storage with a retention lock, a tape or drive physically disconnected between runs, or a provider-side vault with delete protection that requires a separate authorization. A network share that the file server can write to is a copy, but it is not protection, because anything that can encrypt the server can encrypt the share.

The test is to take the account your backup software uses and try to delete a recovery point with it. If it succeeds, so would anything that steals those credentials. The National Institute of Standards and Technology is responsible for the cybersecurity framework that most American organizations map their controls to, and recovery sits in it as its own function rather than as an afterthought to prevention. That structure is useful even for a two-person firm, because it forces the question of what happens after the defenses fail, which is the only condition under which a backup is ever read.

Three: time the restore, then compare it to what the business can absorb

Two numbers decide everything about a recovery plan, and most people who have not lived through one have never written either down. The first is how much data you can afford to lose, which is set by how often the backup runs. The second is how long you can afford to be down, which is set by how fast the data comes back and how much of it there is. A nightly job means a worst case of nearly a full day's work gone. That may be perfectly acceptable for a design studio and completely unacceptable for a medical practice with same-day charting.

Measure the second number with a clock rather than an estimate. Restoring four terabytes over a consumer uplink from a cloud vault takes as long as the arithmetic says it takes, which is often several days, and nobody discovers this pleasantly. Providers that will ship a physical drive have effectively solved that arithmetic for large data sets, and it is worth confirming that the option exists, what it costs, and how it is requested, before the request is urgent. A local copy for speed plus a remote copy for survival is the ordinary answer, and timing each separately tells you which one you will reach for.

Four: find out who holds the key and what happens when they leave

Encrypted backups are correct practice and they are also the most common cause of a restore that cannot proceed. The encryption passphrase, the recovery code for the storage account, and the multifactor device that unlocks the console are three separate items, and in a lot of small organizations all three live with one person. When that person resigns, is hospitalized, or is simply on a flight, the data is still there and still unreachable. Key custody is a governance question rather than a technical one, which is why it is so often nobody's job.

Handle it the way you would handle a safe deposit box. Write down which credentials exist, where each one is stored, and who is authorized to retrieve it, then put a sealed copy somewhere physically separate, a home safe or an attorney's file. Test the retrieval path once a year by having the second authorized person, not the administrator, perform a restore start to finish. If the point of a backup is that the household or the firm recovers without depending on one individual's availability, then the person who is not the usual operator is exactly who should be running the drill.

Five: know the export format and the exit, before the vendor needs one

Backup products fail in a way ordinary software does not, because the value sits in an archive that only that product can read. A vendor that is acquired, discontinues a tier, or shuts down entirely leaves customers holding a proprietary container and a notice period. The question to ask during evaluation, and again at each renewal, is what a full export produces: plain files and folders, standard virtual disk images, or a blob that requires a live license to open. Providers that publish an export path and a documented file format have answered the question already, and that answer is worth paying a little more for.

Alongside format, check retention against whatever rules apply to the records themselves. Tax records, employment files, patient charts, and contracts each carry their own required holding periods, and litigation or an audit can freeze deletion entirely. A backup system configured to purge everything after ninety days is quietly out of step with a seven-year obligation, and the mismatch only surfaces when someone asks for a document from four years ago. Aligning retention to the record, not to the default in the software, closes the gap while it is still a settings change.

None of this takes long once the schedule exists. An hour a quarter, one restored file opened in its own application, one deletion attempt that fails as it should, one timed recovery, one drill run by the backup person rather than the usual one, and one look at the export page. The organizations that come back quickly after a bad week are almost always the ones holding a short document showing when each of those was last confirmed, and by whom.