Backup Ran Green Last Night? The Four Checks That Prove It Would Actually Restore

The moment that decides whether your backup was any good arrives long after you set it up, usually on a weekday morning, usually with someone standing behind you asking how long this will take. By then the configuration is fixed, the retention window has already discarded whatever it was going to discard, and the only variable left is whether the copy you have been paying for can be turned back into working files. People who have done this many times stop asking whether the backup ran. They ask when it was last restored, by whom, and onto what.

A green checkmark measures copying, not recovery

Backup software reports on the task it was given, which is reading source files and writing them somewhere else. It does not report on whether the destination is readable by anything other than itself, whether the encryption key still exists in a place a human can reach, or whether the version it kept is the version from before the corruption rather than after. A job can succeed every night for two years and still produce nothing usable, because success was defined at the wrong end of the process. The definition that matters is a file open on a screen.

This is where adequate and good separate cleanly. An adequate setup has a schedule, a destination, and email alerts that nobody reads until they stop arriving. A good one has all of that plus a record of restores: a date, the item restored, the time it took, and what went wrong on the way. The record is the whole difference. It converts an assumption into a measurement, and it tends to surface the same three problems every time, which is exactly why running it more than once is worth more than running it well once.

The rehearsal that counts, and the one that only feels like work

Restoring a single document to the same machine it came from proves the least interesting part of the chain. It confirms the software can talk to the destination, which you already suspected. The rehearsal that earns its time is a restore performed onto different hardware, by someone who does not have the original setup memorized, using only credentials stored somewhere they can be retrieved during an outage. That last constraint catches more failures than any other, because recovery credentials are habitually stored inside the thing being recovered, and nobody notices until the day it is gone.

Time the rehearsal. Not because speed is the goal, but because the number is the only honest input into your own planning. If pulling back a year of accounting files takes nine hours over a residential upload link, that is your real recovery window, and every decision downstream should assume it. People discover this figure in one of two settings: a quiet Saturday, or a Tuesday emergency with a payroll deadline. The figure is the same either way. What differs is whether anyone can absorb it calmly.

Run the rehearsal on a schedule that survives busy quarters, which for most households and small offices means twice a year rather than monthly. A twice-yearly test that actually happens beats a monthly one that lapsed in March. Tie it to something already on the calendar: a tax filing, a renewal date, the week the clocks change. The National Institute of Standards and Technology is responsible for the federal cybersecurity framework that treats recovery as its own function rather than an afterthought to protection, and the separation is the useful part. Protection and recovery fail independently.

Three copies, and the one that has to be out of reach

The old rule about keeping three copies on two kinds of media with one held off site was written for fire and theft. Ransomware changed which clause carries the weight. An attacker with access to the machine generally has access to whatever that machine can write to, which means an external drive left permanently connected and a cloud folder that syncs both directions are exposed to the same event as the original. The copy that saves you is the one your computer cannot modify: immutable cloud storage with a locked retention period, or a drive that spends most of its life unplugged in a drawer.

Versioning is the companion detail, and it is where barely adequate setups quietly fail. Sync services keep your files current, which is the opposite of what you need when the current version is encrypted, overwritten, or deleted in a way you did not notice for six weeks. Ask how far back the history goes, whether deleted items are retained past the point of deletion, and whether the retention clock resets when the file changes. Thirty days of history sounds generous until you meet a corruption that started in February and surfaced in May.

Reading the reviews for restore complaints, not setup complaints

Ratings for backup products skew toward the first week of ownership, because that is when people are motivated to write. Installation was smooth, the interface is clean, support answered in four minutes. None of that measures the product at the only moment it matters. The reviews worth your attention are the ones written by someone who actually needed the thing: they mention file counts, hours, a support ticket number, a restore that stalled at ninety-four percent. Sort for those, and the star average becomes close to irrelevant next to what those particular accounts describe.

Distinguish a pattern from a grudge by looking for mechanism. One furious review about a billing dispute is a grudge, and it tells you about a customer service interaction, not a product. Six separate reviews across eighteen months describing the same behavior, restores failing on files above a certain size, or archives that will not open without the original software version, constitute a pattern, and a pattern is a design characteristic. Vendors respond to patterns in public; read the responses too. A reply that names a build number and a fix date is worth more than a dozen apologetic ones.

The things nobody remembers to include

Coverage gaps are the most common finding in a first rehearsal, and they cluster in predictable places: phones with photos that never made it anywhere else, cloud-hosted email and documents that many people assume the provider is protecting on their behalf, browser bookmarks and saved sessions, two-factor authenticator seeds, and the recovery codes for the password manager that holds everything else. The last two are small files with outsized consequences, because they gate access to the accounts you need in order to begin recovering at all. Write down where they live, on paper, somewhere physical.

Then account for the machine itself, not just its contents. A file-level backup returns your documents to a computer that still needs an operating system, drivers, license keys, and a day of reinstallation. An image-level backup returns the machine. Which one you need depends on how many hours of downtime you can tolerate, and knowing that answer in advance is what lets you pick deliberately rather than discover the difference mid-crisis. Most people who have done a few restores end up running both, for different things.

Put the next rehearsal on the calendar before you close this page, with a named person attached and a machine that is not the one being backed up. The first one will take longer than you expect and will find something. That is the point of doing it while nothing is wrong.