Backups: what we learned the day a host went down without warning

The day we nearly lost eight months of a client’s content was an ordinary Tuesday. The shared hosting where they ran their WordPress — a cheap provider they’d signed up with themselves before working with us — had a disk failure, and there was no way to recover anything on the provider’s end. They didn’t keep backups older than 24 hours. By the time they called us, it was already too late.

We didn’t lose the full eight months, to be fair: we had a copy from three weeks earlier because we’d touched the template shortly before, and I always save a manual copy before putting my hands into production. But those three weeks of posts, orders and customer comments were gone. It was the last time I left backup management in someone else’s hosting without checking it myself first.

Since then we apply the same rule to every new project, whether it’s our own hosting or the client’s: automated daily backups, stored off the server the site actually lives on (usually a separate S3 bucket, sometimes Backblaze if the budget is tight), with at least 14 days of retention. Setting it up costs almost nothing — a cron job with mysqldump and rsync, or a decent plugin if it’s WordPress — and yet half the clients we inherit had none of this configured.

What surprises me most isn’t the lack of backups itself. It’s the lack of curiosity. Nobody asks “what if it goes down?” until it does. And when it happens, the real cost isn’t just the lost content: it’s the hours spent rebuilding by hand, the client’s trust that their site is something serious and not a hobbyist with a domain name, and the decisions made in a hurry with no real budget behind them.

With this particular client we ended up migrating everything to a VPS we manage ourselves, with automated backups and a full weekly server snapshot. It cost more per month than the three-euro hosting he had before, and yes, we discussed that. But once I explained he was paying to never live through that Tuesday again, he got it fast.

There’s something a little perverse in how cheap hosting gets sold: it looks like price is the only variable that matters, when what you’re actually buying is a recovery promise that almost never gets tested until you need it. Now, on any new project, we run an actual restore before calling the site done. It’s not enough for the backup to exist — it has to work when you really need it. We got that wrong once and it took us four hours to realize the automated backup had been silently failing for two months because nobody was checking the logs.

How many of the sites you manage have a backup you’ve never actually tried to restore?