A backup never restored is not a backup

Almost every company has backups. Few know whether they work.

The difference only shows up on the worst possible day: the server will not come up, someone opens the backup dashboard, sees the job marked green for months, and discovers at restore time that the file is truncated, that the database came out inconsistent because it was copied while running, or that nobody has the passphrase for the encryption key.

A green dashboard does not prove the data comes back. It proves a process finished without error — which is considerably less than it sounds.

A real restore test answers questions the job does not:

• Does the file open at all? A corrupted backup finishes green just the same.
• Does the system come up with that data, or are there pieces nobody knew had to be in the copy?
• How long does it take? A backup that restores in eighteen hours is no use to a system that cannot be down for two.
• Who can actually do it? If only one person knows, the plan fails while they are on holiday.
• Are the required credentials and keys reachable from outside the environment that went down?

That last point kills more recovery plans than technical failure does. It is common for the backup encryption key to live on the same server the backup protects, or for the passphrase to sit in a manager that only authenticates over the internal network that has just gone offline.

There is no universal frequency for the test. There is a question that sets it: how much can the company afford to lose? A system recording sales all day needs verifying more often than a catalogue that changes once a month. The answer comes from impact, not from the calendar.

It is also worth separating two numbers that get confused. One is how long the system can be down; the other is how much data the company accepts losing. They call for different solutions: the first is solved with restore speed and an environment ready to receive; the second with copy frequency. Buying more storage does not improve the first.

A minimum routine that already changes the picture:

• Restore into a separate environment, never over what is in production.
• Bring the application up pointing at the restored data and actually use it.
• Time the whole process, from request to usable system.
• Note what was missing, fix the job, and repeat.
• Record who did it, when, and what went wrong — including when it went right.

A test nobody documents ends up redone from scratch by the next person, under pressure, on the day mistakes are least affordable.

A backup is a promise the company makes to itself. Testing is the only way to know whether it can keep it.