A backup you have never restored
Everyone has backups. Far fewer have restores, and you find out which kind you have on the worst day of the year.
Backups fail quietly and in ways that look exactly like success: the job reports green, the file exists, the size looks plausible. The failure only becomes visible at the moment you need it, which is the moment you can least afford to discover it.
The only test of a backup is a restore
A completed backup job proves that something was written. It does not prove the archive opens, that it contains what you think, or that the version you need is inside it.
The common failures are dull and specific: the job has been backing up an empty directory since a path changed, the archive is encrypted with a key nobody has any more, or it has been running fine and quietly skipping the one database that matters. All three report success every night.
Back up what you cannot regenerate
Not everything deserves the cost. Code that lives in a repository, files you can download again, anything a build produces — those are already safe or cheaply rebuilt.
What matters is what exists in exactly one place and was made by people: the database, uploaded files, configuration nobody wrote down, and the settings someone spent two days tuning. If it took a human to create it and there is one copy, it is on the list. If a machine can make it again in ten minutes, it usually is not.
A copy in the same place is not a backup
A snapshot on the same server, in the same account, under the same login, survives a disk failure and nothing else. It does not survive the account being locked, a mistaken deletion that propagates, or someone with access having a bad day.
Put at least one copy somewhere the live system cannot reach and cannot delete. That property — that the running system has no power over the copy — is what makes it a backup rather than a duplicate.
Run a drill on a normal Tuesday
The number that matters is not how often you back up; it is how long a restore takes and whether you can do it under pressure. Nobody knows that number until they have done it once.
Pick an ordinary afternoon, restore something real into a safe place, and time it. You will find at least one broken assumption — a missing credential, a step that needs someone on holiday, an archive that takes four hours to transfer. Fix those while nothing is on fire, write down the steps in the order that worked, and you have converted a hope into a procedure.
Questions people actually ask
How do I know my backups work?
Only by restoring one. A completed job proves something was written, not that the archive opens or contains what you think. Backing up an empty directory since a path changed reports success every night.
What should I back up?
What exists in exactly one place and was made by people: the database, uploaded files, undocumented configuration, hand-tuned settings. Anything a machine can regenerate in ten minutes usually does not need it.
Is a snapshot on the same server enough?
No. It survives a disk failure and nothing else — not a locked account, a propagating deletion, or someone with access having a bad day. At least one copy must be somewhere the live system cannot reach or delete.
