Backups you actually restore
Everyone says backups are important. Almost nobody checks whether they work. I didn't for a long time: the backup job ran, the files were there, I looked at the green success message and moved on. Until I actually had to restore something for the first time – and realized I had no idea whether it would work. Not whether the data is there, but whether I get it back.
That is the difference this is about. A backup is not an artifact, it's a promise. And a promise you never keep is not one.
The first real restore
My first forced encounter came through Nextcloud. A wrong occ command had wrecked a database table, and the instance wouldn't come back up. The backup was there – a dump from last night. So: import the dump, done, I thought.
It took three hours.
Not because the dump was broken. But because I had never thought through the order: first the database, then the files, then the config, then the permissions – and in what order do you stop the services so a running PHP process doesn't write into the middle of the restore? I didn't know any of it, because I had never practiced it. That evening I tried it live, on a broken system, with a client waiting. Exactly the wrong environment for an experiment.
What breaks along the way
That evening dismantled a list of assumptions I had taken for granted:
- The dump is readable. A
pg_dumpthat has run for weeks can be corrupt without the job ever reporting an error. You only notice when you import it. - The restore matches the version. Restoring a Nextcloud 27 backup into a 29 instance is not a restore, it's a migration project. Version levels belong in the backup – or better: in the restore script.
- The config is not just the database. With Nextcloud, state and data live in at least three places: the database, the data directory,
config.php. Whoever backs up only one of them has no snapshot. - Permissions are part of the data. A restore with wrong owner or group rights produces an instance that looks fresh but is allowed to do nothing.
www-datais not a formality. - I was the bottleneck. The real problem wasn't the technology, it was that I was doing the process for the first time. Under pressure.
The common thread: the backup job verifies that it wrote something. Not that you can come back.
What I changed since
That evening turned into three habits worth more than any additional backup tool:
1. Practice restores before you need them. I regularly take a test instance and replay the latest snapshot – not production, a copy of it. The process becomes routine, the steps become muscle memory. When it gets serious, it's no longer an experiment but repetition.
2. Treat the backup as a script, not a configuration. The restore is a script I maintain like the rest of the code. It knows the order, the versions, the permissions. I no longer have to know them by heart – I only have to run it and see that it goes through.
3. Automate the restore and verify it. A script that imports the dump at night and then runs a check – does the instance come up, is the snapshot readable? If yes, yesterday's backup was actually usable. That's the only test that counts.
The uncomfortable truth
Backup software sells you the feeling of security. The green message, the checkmark, the "backup successful" mail. But no tool in the world knows whether that backup actually gets you a running system again. Only you know that – and only if you've tried it.
My rule has been simple ever since: if I'm not willing to restore this backup tomorrow, it isn't one. The rest is file management with a clear conscience.
Having backups is not an achievement. Getting them back is.