Yesterday morning, a fire broke out at OVHcloud’s SBG2 datacenter in Strasbourg, France. It didn’t just damage the facility — it destroyed it entirely, along with a significant portion of the adjacent SBG1 building. SBG3 and SBG4 were taken offline as a precaution. In one night, a substantial chunk of Europe’s largest cloud provider went up in smoke. Literally.
The images circulating on social media are remarkable. The entire five-story SBG2 building engulfed in flames, the metal structure glowing orange against the night sky. No injuries reported, thankfully, but the data losses are already proving catastrophic for many customers.
OVHcloud founder Octave Klaba has been posting updates on Twitter with admirable transparency, but the reality is grim: SBG2 is a total loss. For customers whose data lived exclusively in that facility, with no off-site backups, it’s gone. Permanently.
The Blast Radius#
OVHcloud hosts approximately 1.5 million websites across its infrastructure. The Strasbourg campus was one of their major European hubs. In the hours since the fire, we’ve seen:
- Government agencies in France with services offline
- The Centre Pompidou’s website down
- Multiple game servers (Rust players are particularly vocal) wiped entirely
- Cryptocurrency platforms, e-commerce sites, and SaaS applications offline
- data.gouv.fr, the French government’s open data platform, inaccessible
Octave Klaba has stated that SBG1 and SBG4 should be partially restored within one to two weeks, and SBG3 within two weeks. SBG2 will not be restored — it no longer exists. For customers with data replicated across availability zones, recovery is possible. For those without… the conversations happening right now must be brutal.
The Shared Responsibility Misunderstanding#
This event exposes what I consider the cloud industry’s original sin: the persistent, widespread misunderstanding of the shared responsibility model.
When you buy a bare metal server or a VPS from OVHcloud (or any provider), you’re buying compute and network. You are not buying disaster recovery. You are not buying backups. You are not buying geographic redundancy. These are available as additional services, and OVHcloud offers them, but they’re not default.
The problem is that “cloud” has become synonymous with “resilient” in many people’s minds. Marketing language about “enterprise-grade infrastructure” and “99.99% uptime SLAs” creates an expectation that the provider handles everything. But an SLA is a financial agreement about service credits — it’s not a guarantee that your data survives a building fire.
I’ve had this conversation with clients more times than I can count. “But it’s in the cloud!” Yes, and “the cloud” is a computer in someone else’s building. Buildings can flood, lose power, or — as we’ve just been reminded — catch fire.
Backup Lessons (Again)#
The 3-2-1 backup rule has been around for decades, and it exists precisely for moments like this:
- 3 copies of your data
- 2 different storage media
- 1 off-site copy
If your production database lives on an OVHcloud VPS in Strasbourg, and your only backup is a snapshot stored… on OVHcloud’s infrastructure in Strasbourg, you don’t have a backup. You have two copies in the same blast radius.
For anyone reassessing their backup strategy after this wake-up call:
- Automate off-site backups. Use
restic,borgbackup, or similar tools to push encrypted backups to a geographically separate location. S3-compatible storage in a different region is cheap and effective. - Test your restores. A backup you’ve never restored is Schrödinger’s backup — it both works and doesn’t work until you try. Schedule monthly restore tests.
- Document your recovery procedure. When everything is on fire (perhaps literally), you don’t want to be figuring out the restore process from scratch.
- Consider your RPO and RTO. Recovery Point Objective (how much data can you afford to lose) and Recovery Time Objective (how long can you be down) should drive your backup frequency and infrastructure choices.
Multi-Region Is Not Optional#
For production workloads that matter, single-datacenter deployment is a calculated risk. Sometimes that calculation makes sense — not every application justifies the complexity and cost of multi-region architecture. A personal blog, a staging environment, an internal tool used by five people — fine, single region.
But if your business depends on it, you need geographic redundancy. And not “two availability zones in the same campus” redundancy — actual geographic separation. OVHcloud’s SBG1 through SBG4 are all on the same campus in Strasbourg. Adjacent buildings. When one caught fire, they all went down.
This is where the major hyperscalers (AWS, Azure, GCP) have a structural advantage. Their region model, with availability zones that are physically separate facilities with independent power and cooling, provides genuine isolation. OVHcloud and other European providers have been building out similar capabilities, but the Strasbourg campus design clearly didn’t provide the isolation customers assumed.
My Take#
I feel for the OVHcloud team and their customers. Octave Klaba’s transparency has been exemplary — real-time updates, honest assessments, no corporate spin. That’s how you handle a crisis.
But I also feel frustrated, because this conversation happens after every major outage. We collectively express shock, write blog posts about backup strategies, and then slowly drift back to complacency until the next incident. I watched the same cycle after the 2017 OVH Strasbourg flood, after S3’s 2017 outage, after every significant infrastructure failure.
The lesson isn’t complicated: your data is your responsibility. Cloud providers sell infrastructure, not peace of mind. If you’re reading this and you’re not sure whether your backups would survive your primary datacenter being physically destroyed, that’s your action item for today. Not tomorrow. Today.