Everyone has backups. Almost nobody tests them. And an untested backup is not a backup — it's a hope, wearing a backup's uniform.
I learned this the way most people in IT learn it: badly, at the worst possible moment. A backup that had been "running successfully" for months, green checkmarks the whole way, turned out to be quietly useless when we finally needed it. The job had been completing. The data it was writing was incomplete. Nobody had ever tried to restore from it, so nobody knew. The first real test of that backup was also the first real disaster, and it failed both at once.
That's the trap. Backups fail silently. The job reports success, the storage fills up, everyone feels safe — and the actual recoverability of the thing is completely unverified. You don't have a backup. You have a file you've never opened, and a belief about what's inside it.
The only backup that counts is one you've actually restored. Restored to a real system, verified as complete, timed so you know how long recovery takes. Until you've done that, you don't know if the data is good, if the process works, or if "we can recover in an hour" is true or a comforting story. And you never want to find out for the first time while production is down.
So test the restore. Schedule it like any other critical task. Pull a backup, bring it back somewhere safe, confirm it's whole, and note how long it took. Do it often enough that recovery is routine instead of terrifying.
A backup you've never restored is a question, not an answer. Test it, and turn the hope into something you can actually count on.
– Serguey Shinder
