“Do you have backups?” is the wrong question. The right one is: which disaster are they for?
Three copies, three failures
- On your own server. Protects against a bad update. It is on the same disk as the site, so the rollback is immediate — which is exactly what you want at the moment an update has just gone wrong.
- On ours. Protects against losing the hosting account: an expired invoice, a suspended server, a provider that goes quiet. The copy on your server is useless if you cannot reach your server.
- Off-site. Protects against losing us. Slowest to restore from, and the one that matters if the other two are gone.
A single backup, wherever it lives, only covers one of these three. That is the argument for all three, not for the biggest one.
Before every install, not every night
A nightly backup means that if an update breaks something at 02:40, your restore point is from before yesterday’s orders. So the dump is taken before each install instead. A security update that cannot be undone is not a safe update.
Rotation, and what it leaves alone
Old copies are rotated per type — database dumps and file archives do not share a quota, so a week of database dumps cannot quietly push out your only file archive. The safety copy taken before a restore is not counted at all; it expires on age instead. And anything rotation does not recognise, it does not touch. A cleanup routine that deletes files it does not understand is a second disaster waiting behind the first.
Restoring takes a backup too
A restore overwrites the live site. So before it runs, the current state is dumped as well. If the restore turns out to have been the wrong call — the fault was elsewhere, the data since is worth keeping — that is recoverable too.
Where the copies live is a legal question
A database dump of a working site contains its customers’ personal data: names, addresses, order history. For an EU client that makes the storage region a GDPR matter, not a preference. Off-site copies belong in EU storage, and that is worth checking in whatever backup arrangement you already have.
A backup you have never restored from is a hypothesis, not a backup.
