A backup you have never restored is not a backup

Configured is not the same as working

Almost every business we look at has backups switched on somewhere. Very few can answer the follow-up question: when did you last restore one, and did the result work?

That gap matters because the failure modes are silent. A backup job that has been failing for six weeks looks identical to one that has been succeeding, unless somebody is watching the outcome rather than the setting. A dump that completes but excludes half your data produces a file of plausible size that is useless when you need it.

The only test that means anything is a restore. Everything else is an assumption.

Your files are probably not in the database dump

This is the most common gap we find, and it catches competent teams. The database backup runs faithfully every night. Meanwhile signed delivery photographs, uploaded invoices, scanned documents and attachments live on a disk or in object storage, and no backup covers them.

It gets worse on platforms where the application filesystem is not persistent. Each deployment quietly discards uploaded files. The database rows referencing them survive, so the system looks intact — until someone opens a record and the attachment is a broken link. By the time anyone notices, the files are months gone.

Ask a specific question of whoever runs your systems: which storage locations are covered by a backup, and which are not? Vagueness in the answer is the finding.

Decide how much you can lose, and how long you can be down

Two numbers drive every sensible backup design. How much data can the business afford to lose — an hour, a day, a week? And how long can it be down while you recover?

For a logistics operation, the second is usually the tighter one. Losing four hours of entries is painful but recoverable by re-keying from paper. Being unable to issue a consignment note for a day means trucks are not moving.

Answer both in plain language with whoever owns the business, before designing anything. A nightly backup with a restore path nobody has walked implies a recovery time of unknown, which is not an answer you want to give during an incident.

Keep a copy somewhere your provider does not control

Backups sitting on the same platform as the system protect against the common failures — a bad deployment, a dropped table, a corrupted file. They do not protect against losing access to the account itself, whether through a billing failure, a suspension or a compromise.

One copy with a different provider closes that. It costs very little for a database that is a couple of gigabytes, and it is the difference between a bad week and the end of the business.

Automate the drill, because manual checks stop happening

A restore test that depends on someone remembering will be done twice and then forgotten. Schedule it instead: take the most recent backup, restore it into a scratch database, check that the schemas are all present and that a few known row counts look right, then email the result and delete the scratch copy.

Ours runs monthly and finishes in well under a minute. The value is not the minute — it is that a silent failure becomes an email within thirty days instead of a discovery during an outage.

Have it report success as well as failure. A job that only speaks up when something is wrong is indistinguishable from a job that has stopped running.

Write the recovery down before you need it

During an incident, nobody is at their best. The person who knows the system may be asleep, on a flight, or no longer at the company. A runbook someone else can follow — exact commands, in order, including how to fetch the backup and where the credentials are — turns a crisis into a procedure.

Test it by having someone who did not write it follow it. The steps that were obvious to the author are exactly the ones that will be missing.

Five questions worth asking this week

• When was a backup last restored, and what proved the restore worked?
• Which file storage is covered by a backup, and which is not?
• Is there a copy with a provider other than the one hosting the system?
• Does anyone get told when a backup job fails — and when it succeeds?
• Could someone other than the person who built it perform a recovery?

None of this is expensive

Off-site storage for a small operational database costs a rounding error. The scheduled restore drill is an afternoon to set up. The runbook is a document.

What it takes is deciding it matters before something forces the issue. Every business that has lost data had backups configured too.