We zitten in een publieke testfase — kijk gerust rond, maar bestellen kan nog niet. Bestellen kan vanaf 1 oktober 2026.
Blog / We Tested Our Backups by Pretending the Datacenter Burned Down

We Tested Our Backups by Pretending the Datacenter Burned Down

A backup you've never restored is a hope, not a backup. Here's how our backup chain works, why copies now live in a second region, and what happened when we pulled one back with a stopwatch running.

Article

Overview

A practical look at how legitimate email infrastructure can be abused, why it slips past normal expectations, and what SMEs can do to reduce backscatter and inbox noise.

In March 2021, a fire destroyed one of OVH's Strasbourg datacenters. Thousands of customers discovered, the hard way, the difference between "we have backups" and "we have backups somewhere else". Some businesses lost everything — their servers and their backups had been in the same building.

Every hosting provider read that story and thought: could that be us? Here's our honest answer, including the part where we found a hole in our own setup last week.

What gets backed up, and when

Every site on our platform with backups enabled gets a nightly snapshot: all the files plus a full database dump, bundled into one archive. Customers can also hit "back up now" before doing anything risky, and we snapshot automatically before every restore — so you can undo an undo. Restoring is self-service and takes about a minute; we've timed a full production-site restore at 43 seconds.

That covers the everyday disasters: a bad plugin update, a deleted folder, a migration gone sideways. It does not cover the OVH scenario. If the server holding both your site and its backups is gone, the nightly snapshot goes with it.

The gap we found in our own house

Last week, while preparing our disaster-recovery runbook, we audited what actually left the primary server each night. The off-site job was there, running faithfully. But its list of what to copy had been written months earlier and never revisited. Customer site backups weren't on it. Neither was the platform's own database.

Nobody had done anything wrong, exactly. The job worked; the world had changed around it. That's the uncomfortable thing about backup systems: they fail silently, by omission, while every status light stays green.

We fixed it the same day. Every customer backup archive and a full dump of the platform databases now replicate every night to storage in Nuremberg — a different city from the Falkenstein datacenter that runs the sites. Same country, different region, different building, different failure domain. If Falkenstein goes dark, the archives are sitting 300 kilometers away.

Then we tested it, because untested backups are folklore

A backup you have never restored is a hope, not a backup. So we ran a drill against the off-site copies, not the local ones — the point was to simulate the primary server being gone.

Pulled the newest site archive from the Nuremberg storage over SSH: two seconds. Extracted it and checked inside: a 191 MB code tree, a valid database dump, the server configuration alongside. Decompressed the platform database dump and checked that both databases were actually in it. They were. Total time from "pretend everything is on fire" to verified, restorable data on independent hardware: well under a minute for the data layer.

A full rebuild — new server, containers reprovisioned, DNS repointed — would take longer, and we've written the runbook for it rather than pretending it's instant. The nameservers themselves run on separate machines in two locations, so DNS keeps answering even while a web host is being rebuilt. We'll drill the full rebuild next and publish what it took.

What we tell customers, and what we deliberately don't

Our SLA now states the second-region replication plainly. You'll notice what it doesn't say: "failover". Replicated backups mean your data survives a regional disaster; they do not mean your site stays up through one without intervention. Automatic multi-region failover is a different, much more expensive machine, and claiming it because "backups exist somewhere else" is how hosting marketing earns its reputation.

Two takeaways if you run anything important, on any host:

Ask where the backups physically are. Not whether they exist — where. If the answer is "same server" or "same building", you have a copy, not a backup.

Ask when a restore was last actually performed. Not tested in theory. Performed, timed, verified. If the answer is a blank look, assume the worst, because silence is what backup failure sounds like.