The backup that did not exist

A small company lost eleven years of records in an afternoon. They had backups. The backups had been running nightly without a single error message for four years.

What they had never done was restore one.

The script had been copying an empty directory since a server migration in 2022. The path it pointed at no longer existed, and the tool it used treated a missing source as nothing to copy rather than as a failure. Every night it reported success, because from its point of view it had successfully copied all zero files it had found.

This is the most common shape of backup failure, and it is not really a technical problem. It is a problem of what gets checked. A green light confirms that a process ran. It does not confirm that the process did anything useful, and the gap between those two statements is where the data was lost.

The practice that prevents it is dull and reliable: restore something, on a schedule, to a different machine, and open the file. Not verify the archive, not check the log — actually open a document and read it. Organisations that do this find broken backups within weeks. Organisations that watch the log find them on the day they need the data.

It generalises beyond computers. A fire alarm nobody has tested, a spare tyre nobody has checked, an emergency plan nobody has rehearsed: each reports success by remaining silent, and silence is the same sound whether the thing works or not.