A backup is not a restore plan

The green tick is not the thing you need

A backup job that exits successfully is useful, but it is not the same as knowing you can recover. The green tick tells you that one scheduled operation appeared to finish. It does not prove the right data was selected, that the repository is still readable, that you remember the password, that the restore target has enough space, or that the service can start cleanly after the files come back. For a home server, that distinction matters because the moment you need a backup is usually the moment you have the least patience for discovery.

This is the practical mental model: a backup is a stored copy; a restore plan is a rehearsed path from failure to working service. They overlap, but they are not the same artifact. A reliable setup needs both.

Start by naming what has to come back first

Before touching tooling, write down the smallest useful recovery order. Not every file on a server deserves the same urgency. A family photo archive, a password manager export, a Home Assistant configuration directory, a DNS blocklist setup, a media library and a throwaway container cache all have different recovery value. If everything is labelled critical, the first restore will become a scavenger hunt.

Use a plain table with four columns:

That last column keeps the plan honest. If a service can lose a day of changes, a daily backup may be enough. If it cannot lose more than ten minutes, a weekly archive is theatre. NIST's contingency-planning guide frames recovery work as deciding requirements and priorities, which is a useful home-server translation too: recover the things that keep the household or project working before you polish the things that are merely convenient.

• What must be recoverable, named in human language.
• Where it is backed up from, without publishing private paths or hostnames.
• What proves it restored, such as a service starting, a file opening, or a checksum matching.
• How much loss is acceptable, stated as time, not vibes.

Test a restore, not just a backup

The simplest useful drill is not dramatic. Pick one real backup, restore it to a temporary location that is not the live service, and check the result against your table. Can you find the snapshot? Can you authenticate to the repository without hunting through chat history? Does the restored directory contain the expected current files? If it is a configuration backup, can the application parse it? If it is a database dump, can it load into a disposable database and answer one known query?

NIST's 2026 OT Backup Quick Start Guide is written for operational technology rather than a home lab, but its core backup discipline generalises cleanly: effective backup management involves creating backups regularly, testing them, and reviewing them during recovery exercises. The home-server version is smaller, but the evidence is the same kind of evidence. A restore drill should leave behind a dated note that says what was restored, where it was restored to, what passed, what failed, and what you changed afterwards.

Use integrity checks for what they actually prove

Restore drills are the human workflow test. Repository checks are the storage-health test. They answer different questions, so do both.

The restic documentation gives a good example of the distinction. Its `check` command can test whether a repository is healthy and consistent, including structural consistency across snapshots, trees and pack files. It also documents an important limit: by default, the command does not verify that every actual pack file on disk is unmodified, because doing that requires reading a copy of every pack file. For that stronger check, restic provides `--read-data`, and for a less expensive routine it provides subset options such as checking one part of the repository at a time.

That is the pattern to copy even if you do not use restic. A lightweight automated check after every backup is good. A periodic deeper read of stored data is better. Neither replaces an actual restore into a temporary target, because passing a repository check still does not prove your service start-up procedure, credentials, documentation or recovery order.

Keep the drill boring and reversible

A good restore drill has guardrails. Do not restore over the live service. Do not test by deleting the only working copy. Do not expose private paths, credentials or network details in notes. Use a scratch directory, a disposable database, or an offline spare machine. Make the test small enough that you will repeat it.

For most home servers, a monthly or quarterly drill for the most important services is more useful than an elaborate annual exercise nobody wants to run. Rotate the target: one month restore a config directory, another month a database dump, another month a sample from long-term storage. If the backup tool supports partial data checks, spread those across the same rhythm rather than trying to read the entire repository every time.

The output should be terse:

The problems are not embarrassment; they are the point. A missing environment variable, an undocumented password location, a stale exclude rule or a service that cannot parse its restored config is much cheaper to find during a quiet Saturday test than during a failed disk replacement.

• Date of the drill.
• Backup set and snapshot used.
• Restore target.
• Evidence checked.
• Time taken.
• Problems found.
• Next change to make.

Know where this advice stops

This article is a practical recovery habit, not a disaster-recovery standard. It does not tell you what retention law applies to a business, how to handle regulated data, or how to design immutable off-site storage. It also does not claim that one backup tool, one cloud provider or one home-server layout is universally right. Those choices depend on the value of the data, the threat model, the budget, and the person who will have to do the restore.

What does generalise is the evidence standard. A backup is not proven because a schedule ran. It is proven, for the thing you care about, when you can restore it somewhere safe, inspect the result, and update the plan from what you learned. That is a quieter habit than buying another drive or adding another dashboard tile, but it is the habit that turns stored copies into actual recovery.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. OT Backup Quick Start Guide — National Institute of Standards and Technology. States that effective backup management includes creating backups regularly, testing them, and reviewing them during recovery exercises.
2. Working with repositories — restic. Explains restore, repository integrity checks, data-reading checks, and the limits of default structural checks.
3. Contingency Planning Guide for Federal Information Systems — NIST CSRC. Frames recovery planning as practical guidance for contingency planning requirements and priorities.