Skip to content
Back to blog

Backups That Actually Restore

Published on June 12, 2026 · principale.dev

The Day You Actually Need the Backup

Picture the Monday when all of this stops being theoretical. Someone’s laptop gets stolen with the only complete set of contracts on it. A disk dies after five years of service, with no warning. Or worse: nobody in the company can open their files this morning, because ransomware encrypted everything overnight and there’s a ransom note on the screen.

The first thought is a relief: “It’s fine, we have backups.”

Then comes the second moment, the one where the backup turns out to be useless. The archive won’t open. The most recent copy is eight months old, because something silently disconnected and nobody noticed. The encryption password was known to exactly one person, who left the company last year. Or the classic: the backup lived on the same disk that just died.

Nothing here is bad luck: this is the most ordinary failure there is, and it is avoidable.

Backups Fail Silently

Backups have one treacherous property: they break without a sound. A website that’s down screams about it immediately. A backup that’s broken looks exactly like one that works, right up until the day you need it.

The most common silent failures:

  • Corrupted archives. The file exists, the size looks plausible, and the moment you try to restore it, it won’t open.
  • Incomplete files. The job runs every night but has been skipping the folder with the things that matter most, because someone moved it six months ago.
  • A password nobody remembers. An encrypted backup without its password is worth exactly as much as no backup at all.
  • A copy on the same disk. If the backup lives on the machine it’s supposed to protect, a fire, a theft, or a disk failure takes the original and the copy in one go.

AWS’s Well-Architected Framework has a whole best practice for this, REL09-BP04, “Perform periodic recovery of the data to verify backup integrity and processes”, and its anti-pattern list reads like a description of the Monday above:

  • “Restoring a backup, but not querying or retrieving any data to check that the restoration is usable.”
  • “Assuming that a backup exists.”
  • “Assuming that the backup of a system is fully operational and that data can be recovered from it.”
  • “Assuming that the time to restore or recover data from a backup falls within the RTO for the workload.”
  • “Assuming that the data contained on the backup falls within the RPO for the workload.”
  • “Restoring when necessary, without using a runbook or outside of an established automated procedure.”

Two terms recur through that list: RTO (recovery time objective — how long a restore is allowed to take) and RPO (recovery point objective — how much data loss, measured in time, is acceptable). Datto describes automated backup verification as a feature built into its backup products, and NinjaOne publishes a guide to testing backups and proving restores. The reasoning is the same everywhere: a backup is a means, the goal is getting your data back, and the only way to know you can is to try.

The Fifteen-Minute Check

You don’t need to be an IT person, and you don’t need any service, to check the basics. Fifteen minutes and four steps:

  1. Restore one file. Pick any document from the backup and open it on a different device than the one it came from. If it opens and looks right, the first test has passed.
  2. Check the date of the last backup. Is the newest copy from yesterday, or from February? If you don’t know where to check, that’s already your answer.
  3. Check where the backup physically lives. A different disk, a different machine, ideally a different location than the original. A copy on the same computer protects you from deleting a file, not from failure, theft, or ransomware.
  4. Write down where the backup password is. If your backup is encrypted, good. Just make sure the password is stored somewhere safe, and that more than one person can find it when it counts.

If all four pass, the basics are in order. Repeat the routine every so often; the first of the month works well.

If one of them fails, you found out on a calm day instead of on that Monday from the first paragraph. That is the better outcome.

A Real Restore Drill

The fifteen-minute check catches whether a backup opens. It doesn’t tell you whether a full restore finishes in time, or whether the data it recovers is actually current enough to matter. For that, AWS’s REL09-BP04 lays out a longer procedure — the version below is a condensed take on it, dropping the AWS-specific tooling (CloudTrail, Resilience Hub, AWS Backup) that a self-hosted setup doesn’t have:

  1. Decide your RTO and RPO first. RTO is how long you can tolerate being down before a restore finishes. RPO is how much recent data you can afford to lose, measured in time (e.g., “at most 24 hours of new invoices”). Without these numbers, “it restored” and “it restored in time” are indistinguishable.
  2. Restore to a new location, not back over the original. AWS’s guidance is explicit that a real test means “periodically restore backups to a new location and run tests to verify the integrity of the data” — restoring onto the live system risks masking a bad backup with data that was never lost.
  3. Validate the data, not just its presence. AWS’s own validation criteria are a useful checklist: “data type, format, checksum, size, or a combination of these with custom validation logic.” Check that the restored files are complete and not corrupted, and that the most recent record in them falls within your RPO. A restored folder that opens but is missing last week’s invoices has failed the drill even though nothing “errored”.
  4. Time the whole thing. Note when the restore started and when validation finished. Compare that against your RTO. A backup that takes six hours to restore is a real number to know before the day you need it, not during.
  5. Write down what you found, and repeat the drill on a schedule. A test you ran once, two years ago, tells you what your backups were good for two years ago.

Self-Service backups run on a schedule to storage you control from day one, at no cost, but nobody watches the jobs or runs this drill for you yet — that part is on you today, and a verified, automated restore drill with a proof report is on the roadmap, not live yet.

That is the difference between “the backup ran” and “the backup works”. The first is a promise; the second has to be shown by a restore.

principale.dev installs open-source tools like these on a server you own. Every install is free. See how it works.