The OVHcloud fire showed that data locality is not disaster separation

Summary

• Fire alarms activated at OVHcloud's Strasbourg site at 00:35 on 10 March 2021. The fire began in energy rooms on the ground floor of SBG2, destroyed that building, damaged four of SBG1's twelve rooms, and forced power off across the campus. SBG3 and SBG4 were not consumed by the initial fire, yet services there were unavailable because electrical isolation, safety inspection, cleaning, and staged restart were required. No one was killed or injured.
• The French industrial-safety investigation did not determine the precise cause of the near-simultaneous electrical failures observed at a UPS and its associated lead batteries. It did establish propagation and response factors: no automatic extinguishing system in any of the five Strasbourg buildings, rapid movement of smoke through SBG2's open cooling-oriented design, limited fire-water capacity, and a difficult site-wide electrical shutdown. Working detection, overnight staff, fire-resistant separation protecting SBG3, and the arrival of a high-capacity Franco-German fireboat limited worse consequences.
• Availability loss and permanent data loss were different outcomes. OVHcloud reported about 65,000 customers and 120,000 services disrupted, while Netcraft observed roughly 3.6 million websites across 464,000 domains go offline. OVHcloud said many customers who lost data had not selected an optional backup. That does not close the accountability question: OVHcloud's own registration document said offered backups could be stored in the same or a different datacentre, and a later appellate judgment concerned a customer whose paid automated backup was destroyed in the same building as production.
• The event exposed a category error in cloud procurement. Data sovereignty, legal jurisdiction, latency, availability, backup, and disaster recovery are related but not interchangeable. Keeping data in France or the European Union can satisfy a locality policy while still allowing production and recovery copies to share one physical hazard. Conversely, a geographically distant copy can remain inside the same legal territory and under the same European controls.
• OVHcloud disclosed substantial post-fire changes, including wider automatic suppression, stronger compartmentation, separate energy rooms, remote electrical cut-offs, site audits, work with fire services, and new multi-zone and distant-backup options. Accountable closure nevertheless requires service- and site-specific evidence: completed-control coverage, independent inspection, realistic fire and power-isolation exercises, declared backup locations, successful restore tests, and proof that customer recovery does not depend on the damaged region or the same control plane.

A physical fire became a cloud accountability event

The phrase "data in the cloud" encourages an abstraction. It is useful when engineers want a standard interface to computing capacity, but dangerous when decision-makers begin to treat location, power, and fire as somebody else's details. Every virtual server rests in a room. Every storage replica occupies equipment connected to electrical and cooling systems. Every recovery workflow depends on people, networks, credentials, catalogues, and a place from which replacement capacity can be obtained.

Strasbourg made that physical chain visible. In the early hours of 10 March 2021, fire destroyed SBG2, one of the buildings on OVHcloud's campus at the Port du Rhin. SBG1 was partly destroyed. The two other datacentres at the site were shut down even though the initial company update described them as undamaged. The loss therefore travelled through at least three distinct mechanisms: equipment was physically destroyed; equipment in adjacent buildings was exposed to heat, smoke, water, or uncertainty; and healthy equipment became unavailable when the site had to be electrically isolated and made safe.

Those mechanisms matter because they correspond to different controls. Automatic suppression and compartmentation can contain a fire. Independent power zones can reduce the area that firefighters need disconnected. A multi-site application can continue while one site is unavailable. A remote, verified backup can support reconstruction after data is destroyed. A status page can guide customers through those options. Calling all of this "redundancy" conceals who controls each layer and what event it can survive.

The most authoritative public reconstruction is the French Bureau d'enquetes et d'analyses sur les risques industriels, or BEA-RI, May 2022 investigation report. Its mandate was prevention, not allocation of civil or criminal liability. That boundary is important. The report can establish observations, possible causes, contributing factors, and safety recommendations. It cannot be converted into a court finding that every identified weakness was negligent or that one weakness legally caused a particular customer's loss.

Accountability analysis asks a related but broader question: which actors had authority over the conditions that allowed one night-time equipment event to become a multi-building outage, a prolonged restoration, and irreversible customer loss? OVH controlled the site's design and operation, the offered products, the accuracy of their descriptions, and the response. Customers controlled workload classification, architecture, many service selections, and independent copies. Regulators and professional bodies controlled parts of the minimum framework. None of those roles erases the others.

What the evidence establishes, and what it does not

The BEA-RI report places the first alarm at 00:35. A guard reached an SBG2 energy room at 00:37 and found thick black smoke. The building was evacuated at 00:39, the Bas-Rhin fire and rescue service was called at 00:42, and the first crews arrived at 00:59. OVH's public incident page used 00:47 as the time at which the fire broke out. The difference should be preserved rather than forced into one timestamp: the safety investigation had access to alarms and operational records, while the company page provided a public incident marker.

Emergency power to SBG2 was cut at 01:13 and to SBG1, SBG3, and SBG4 at 01:28. Fire crews had seen electrical arcing and held major water deployment until the risk could be controlled. By 01:42 the fire had spread across the first floor. At about 02:00, firefighters reported generalized involvement of SBG2. The high-capacity fireboat EUROPA arrived around 03:00, drawing on the adjacent waterway. The fire was extinguished at 10:02, and the intervention was considered complete at 18:13.

The investigation located the fire's origin in rooms holding batteries and uninterruptible power supply equipment. Video and monitoring records showed a nearly simultaneous electrical fault at UPS unit ASI2 and its associated batteries, which were in separate rooms. There had been maintenance on the UPS that morning and unusual humidity measurements later in the day. The investigators listed several hypotheses, including moisture, maintenance-related malfunction, or operation outside expected conditions. They explicitly said the evidence was limited public evidence to select a precise initiating cause.

That restraint has often been lost in retellings that say a leaking cooling system or a recently serviced UPS "caused" the fire. The official French ARIA accident record is useful corroboration for the plant-room setting and response, but it does not turn a plausible mechanism into a proven root cause. A credible account should say that the early electrical events and origin area are known; the reason those events occurred was unresolved in the published BEA-RI report.

The distinction does not prevent control analysis. An organization must be prepared for equipment failure without knowing which component will fail next. Fire protection is designed around that uncertainty. The accountable question is not only whether OVH should have predicted one particular electrical sequence. It is whether detection, automatic control, compartmentation, water, electrical isolation, building design, and emergency procedures gave people and adjacent services enough independent protection after something ignited.

The building detected danger but could not contain it

The Strasbourg site did one life-safety job well. Optical and aspirating smoke detection worked. Overnight staffing allowed rapid verification and an early call to firefighters. Everyone escaped, and there were no injuries. The BEA-RI report credits those controls. Accountability should retain successful barriers as carefully as failed ones, because future design depends on knowing what actually bought time.

Detection was not matched by automatic suppression. The investigation found that none of the site's five buildings had an automatic fire-protection system. SBG2's battery and UPS rooms were monitored, but there was no system designed to extinguish, control, or delay the fire at its earliest stage. Such a system could have acted before the full electrical shutdown and without exposing firefighters to live equipment. It would not guarantee extinction, particularly in an electrical room, but it could have changed the fire's growth curve.

The building then helped smoke and heat move. SBG2 used an open, tower-like cooling design that was highly permeable to outside air. Within fifteen minutes of the initial event, aspirating detectors had activated on every level. BEA-RI cautioned that detector timing showed smoke, not necessarily flame, but concluded that the construction allowed smoke to spread rapidly. Within roughly ninety minutes, SBG2 was generally involved. The contrast with adjacent SBG3 was instructive: two-hour fire-resistant walls and a fire door, together with firefighting water, left it less damaged than the smaller and less protected SBG1.

Water and power interacted with this design. The public fire-water supply available to the first response was inadequate for the developing event, according to the investigation, and OVH had neither its own extinguishing-water reserve nor a way to pump directly from the nearby canal. EUROPA's arrival was decisive. Electrical independence, normally a datacentre strength, also made emergency isolation difficult: the site combined grid feeds, generators, and large battery systems. The fire service could not safely apply major water streams until those sources were neutralized.

This is the paradox of infrastructure resilience. Backup power preserves computing during an ordinary utility failure, but becomes another energy source to manage during fire. Open airflow can reduce cooling cost and improve operating efficiency, but can weaken smoke and heat containment. Dense equipment and shared site utilities can improve scale economics, but concentrate consequence. Each optimization creates a risk that must be controlled by a different barrier.

OVH's formal response to the BEA-RI recommendations argued that the absence of automatic suppression did not breach a regulatory requirement and that industry guidance cited by the investigation postdated SBG2's design. That is relevant to legal and compliance analysis. It is not the end of operational accountability. Minimum compliance asks whether a rule compelled a control. Resilience asks whether the control was needed for a credible high-consequence scenario. OVH's decision after the fire to generalize automatic extinguishing across unequipped sites is itself evidence that the risk treatment changed.

Four buildings did not mean four independent outcomes

From a customer dashboard, SBG1, SBG2, SBG3, and SBG4 could look like several infrastructure locations. During the incident they formed one emergency site. SBG2 burned. SBG1 and SBG3 were affected by the fire to different degrees. SBG4 was not damaged by the initial blaze. Yet electricity was cut to all four, access was controlled, shared systems had to be assessed, and the surviving infrastructure required cleaning, inspection, recabling, and staged restart.

OVHcloud's contemporaneous Strasbourg update log makes the recovery's physical character unusually visible. Teams removed, cleaned, inspected, reinstalled, and restarted equipment room by room, aisle by aisle, rack by rack, and server by server. Soot-contaminated servers were moved to a factory at Croix for specialist work. Recoverable machines from SBG1 were transferred to other datacentres. Data-recovery specialists attempted to retrieve disks from damaged rooms.

The first recovery was not linear. SBG3 became operational on 18 March. On the evening of 19 March, smoke was detected in an unconnected SBG1 battery room. OVH shut SBG1 and SBG4 again as a precaution and revised the restart schedule. Service restoration resumed on 22 March. By late March, SBG4's bare-metal servers were accessible and SBG3 services were returning in percentages, while equipment from SBG1 was still being cleaned, repaired, and relocated.

OVH's registration document later said most customer services returned within three to four weeks and service was fully restored to the roughly 65,000 affected customers, using about 120,000 services, by the beginning of May. "Service restored" cannot be read as "all data restored." A replacement server can be provisioned while the customer's former disks and records remain destroyed. Recovery reporting must separate infrastructure availability, application startup, data restoration, data currency, and business acceptance.

The site-wide shutdown also shows why the word "datacentre" can be too granular for disaster planning. A failure domain is whatever a hazard can affect together. For fire response at Strasbourg, the relevant domain included the neighboring buildings, power-isolation procedures, emergency access, water capacity, smoke, shared operations, and the safety authority controlling re-entry. Multiple building names did not create independent recovery if the same emergency decision could make all of them unavailable.

Counting the impact requires more than one number

Netcraft's external measurement of the outage found around 3.6 million websites across 464,000 distinct domains offline and more than 18 percent of IP addresses attributed to OVH in its recent survey not responding during the measured window. That is an internet-scale view of lost reachability. It captures hosted subdomains and downstream hosting arrangements, which is why it greatly exceeds OVH's customer count.

OVH's 65,000 affected customers and 120,000 services describe commercial and product relationships. Neither number says how many end users could not reach a service, how many businesses lost a revenue channel, or how many datasets were irrecoverable. Contemporary Reuters reporting identified government portals, banks, shops, news sites, and other online services among the disruption. Those examples show diversity of consequence, not a complete census.

The effect also varied over time. A stateless website with code in an external repository could be rebuilt in another region in hours. A managed service with provider-held recovery data might return when OVH restored its platform. A bare-metal customer waiting for inspection or physical relocation could remain unavailable for weeks. A customer whose only production data and backups were destroyed faced permanent loss, regardless of how quickly a new empty server arrived.

An accountable incident report should therefore use several denominators: customers, services, physical servers, domains, externally unreachable addresses, duration bands, successful provider restores, customer-initiated rebuilds, and permanent data-loss cases. It should identify how many customers had no backup, a same-building copy, a same-site copy, a different OVH region, or a copy under independent control. Public evidence does not provide that complete matrix.

The absence matters because remediation should follow the loss mechanism. If customers did not select a clearly offered remote backup, better product education and safer defaults are relevant. If a product called backup placed all copies inside one building without a clear failure-domain disclosure, product design and contracting are central. If remote copies existed but customers could not retrieve them because identity, keys, catalogues, or network paths were tied to Strasbourg, recovery-system independence is the problem. Aggregating these cases into "some customers had no backup" prevents precise accountability.

A backup is a claim about a future restore

OVHcloud's 2021 registration document said that data-backup services were optional paid services for most clients and that some experienced permanent data loss. It also said clients could choose offered options in which backed-up data was stored either at the same datacentre or at a different datacentre. Certain provider-managed services, including mail, were only mildly interrupted and did not lose data because OVH backed them up.

Those disclosures defeat two simple stories. It is inaccurate to say OVH backed up every service and failed to preserve all the copies. It is also inadequate to say every customer who lost data failed to buy backup. Service models differed. Some customers retained responsibility for the only durable copy, some selected provider options with different locations, and some consumed services for which OVH controlled recovery.

A backup is not defined merely by a successful copy job. It is a controlled promise that, after specified failures, an organization can retrieve a sufficiently recent, intact version of its information and use it to restore a priority service within an accepted time. That promise contains at least six properties:

1. Scope: the data, system state, configurations, identity stores, keys, software, and external dependencies included or intentionally excluded.
2. Point: the maximum acceptable age of restored data, usually expressed as a recovery point objective, and the retention history needed for corruption or delayed discovery.
3. Isolation: the physical, logical, administrative, and provider failures that cannot destroy or alter every copy together.
4. Access: the credentials, encryption keys, catalogues, tools, network paths, and authorized people required to retrieve the copy during a crisis.
5. Time: the tested duration to obtain capacity, transfer data, rebuild dependencies, reconcile transactions, and return a business function to an acceptable state.
6. Evidence: monitoring that the backup completed, integrity checks, sampled restores, full service exercises, and retained records showing the result.

Strasbourg was primarily a test of physical isolation and recovery time, but it exposed all six. A disk image without DNS records, secrets, deployment code, or database consistency may not restart an application. A remote copy encrypted with keys available only through the failed region may be durable and unusable. A multi-terabyte archive that takes days to retrieve may miss a twelve-hour business objective. A backup stored in the same energy and fire domain can be perfectly current until the event it was supposed to cover.

French data-protection authority CNIL now states the physical lesson plainly in its backup security guidance: keep at least one copy at a geographically distinct site, isolate at least one copy offline, protect backups to the same security level as production, and test integrity and restoration. CNIL's cloud security guidance tells customers to verify that a cloud provider has backup locations geographically remote from its datacentres. These 2024 materials are later guidance, not proof of the precise contractual duty for every OVH service in 2021. They are a clear benchmark for present practice.

The Bati Courtage case made product language consequential

One customer's dispute gives the backup boundary legal specificity. France Bati Courtage used an OVH virtual private server and a paid automated backup option. According to the record, OVH informed it in April 2021 that the backup had also been totally and irreversibly destroyed because the copies were in the same building as the primary server. The customer sought millions of euros for data loss and alleged downstream business harm.

The outcome changed on appeal. In its 24 April 2025 judgment, the Douai Court of Appeal retained a contractual breach because OVH could not leave the customer access to the completed backup and conserve it for retrieval. It did not uphold the customer's separate claim that OVH was at fault for failing to locate the services in geographically isolated places. It also retained the earlier finding that OVH had not committed gross fault or serious fire-safety breaches in that dispute, rejected OVH's force-majeure defense, upheld the relevant liability limitations, and reduced the award to EUR1,800.48.

That holding is narrower and more instructive than the widely reported first-instance award. It does not establish that every OVH backup contract promised a remote datacentre. It does not establish a general rule that any same-site backup is legally defective. It does show that responsibility cannot be resolved by saying "the customer owned backup policy" when the customer paid the provider to perform a backup and the provider had contractual obligations concerning the resulting copy.

The case also demonstrates why contract labels need topology behind them. Terms such as "physically isolated," "infrastructure," "local," "region," and "remote" can carry different meanings. A separate disk array is isolated from a server failure. A separate room may be isolated from a rack fire. A separate building can survive some room events but not necessarily a campus power cut or perimeter closure. A separate region is stronger, provided the regions do not share control, account, key, or network dependencies that block recovery.

Customers should not have to infer those boundaries from a marketing adjective. A service description should name the copy's failure domain, whether the location is selected by default or by option, whether location can change, the hazards the design is intended to survive, the recovery objective, and the customer's remaining duties. Providers should retain the historical version of those representations because the interface and documentation available when a service was purchased may later become central evidence.

Contractual limitation and operational accountability also diverge. The appellate award was small because the court applied agreed limitations after assessing the claims and clauses before it. A liability cap does not make permanent data loss operationally acceptable, nor does a large alleged loss prove the provider legally owes that amount. Contracts allocate financial exposure. They do not restore information or prove that a control was appropriately designed.

Shared responsibility must be specific enough to operate

"Shared responsibility" is often used as a polite way to say both parties had work to do. Unless the work is named, the phrase distributes blame after failure instead of assigning controls before it. Strasbourg supports a more exact division.

OVH owned the probability that a local electrical event would grow into a building loss. It chose the physical design, fire detection and suppression, compartmentation, utility isolation, emergency procedures, maintenance framework, water resources, and relationship with public firefighters. Customers could not install sprinklers in SBG2 or create an emergency power cut-off. Those are provider controls even when customer contracts limit damages.

OVH also owned truth about its products. Only the provider could know where an automated backup landed, which services it backed up by default, which regions shared systems, and how the control plane behaved during loss of Strasbourg. It had to describe those properties accurately enough for a customer to make a risk decision. Where OVH undertook the backup service, it owned performance of the promised service and evidence about the resulting copy.

Customers owned the consequence model. A provider could not know, without a specific managed arrangement, whether a small virtual server held a disposable test site or the only copy of years of business records. The customer had to classify data, set recovery objectives, select an architecture proportionate to impact, preserve copies outside the primary failure domain, and test reconstruction. Buying infrastructure did not transfer the customer's duty to decide how long the business could tolerate its loss.

The boundary moves with the service model. In unmanaged bare metal or infrastructure as a service, the customer ordinarily owns application-consistent backup and failover. In a managed database, hosted mail product, or explicit backup service, the provider owns more of the copy, retention, consistency, and restore path. A marketplace reseller or managed-service provider introduces another layer: it may select OVH, configure the backup, represent resilience to its own clients, and retain the only administrative access. End customers need to know that chain.

The French cybersecurity agency ANSSI's current backup fundamentals turn these duties into practical controls. They call for recovery point and time objectives, the 3-2-1 pattern, at least an offline or appropriately protected off-site copy, regular restore testing, an order of restoration, and protection of installation media and application configurations. For outsourced backup, ANSSI highlights EU location, provider replication behavior, customer-controlled encryption, and retrieval time. This is a useful reminder that physical resilience, cyber isolation, sovereignty, and recoverability need to be designed together.

Locality answers several different questions

OVHcloud's European identity mattered in 2021 and still matters. For governments and regulated organizations seeking an alternative to non-European hyperscalers, a French provider operating European datacentres can offer meaningful jurisdictional, economic, and operational advantages. The Strasbourg fire did not make data sovereignty irrelevant. It showed that sovereignty is not a substitute for availability engineering.

"Where is the data?" can mean at least five things:

• Legal location: which country's data-protection, disclosure, insolvency, and sector rules govern storage, processing, and access.
• Corporate control: which parent companies, administrators, subprocessors, and foreign legal demands can influence the service.
• Physical location: which building, floodplain, grid, water supply, campus, and regional hazard contains each copy.
• Logical location: which region, zone, account, tenant, key system, and control plane must operate to retrieve or fail over the data.
• Operational distance: how much latency, bandwidth, staffing, and recovery time separates production from its users and from the recovery copy.

A policy that says "all data must remain in France" answers part of the first question and constrains the third. It does not require production and backup to occupy the same building. France contains multiple metropolitan areas and cloud regions. A policy requiring EU storage allows still more geographic diversity while preserving an EU legal perimeter. Whether that is sufficient depends on the organization's law, threat model, data sensitivity, and recovery objective.

The European Commission's explanation of international transfers also prevents an opposite simplification: GDPR does not impose an absolute rule that personal data can never leave the European Economic Area. It provides adequacy, safeguards, and limited derogations for transfers. Some organizations nevertheless adopt stricter locality requirements because of sector law, public policy, contractual promises, or exposure to foreign jurisdiction.

ANSSI's SecNumCloud qualification guidance illustrates the richer sovereignty model. It addresses EU location not only for customer data but also for administration, supervision, backups, directories, and technical data, while considering corporate control and exposure to non-EU law. That framework is about control over service and data, not merely the latitude and longitude of one disk.

The practical conclusion is constructive: sovereignty and disaster separation can reinforce each other. A French public body can keep sensitive production in one qualified European environment, maintain a geographically distinct EU recovery copy, use customer-controlled encryption and keys, and retain tested export procedures to another approved environment. The architecture may cost more and require careful legal review. The trade-off should be explicit rather than hidden inside the word "local."

Concentration is an application property as well as a market property

The outage affected government portals, commerce, media, games, and public-facing services because many organizations selected one provider or inherited it through a supplier. This is cloud concentration at the market level. There was also concentration inside individual applications: production, backups, DNS, email, management, and deployment tooling could share OVH or Strasbourg even when they appeared as separate products.

The two forms require different treatment. Regulators can monitor systemic reliance on a small group of cloud providers. Procurement teams can avoid unexamined provider concentration across departments. Application owners must map the dependencies that determine whether their own service can recover. A company may use three cloud providers across its portfolio while one critical system still has no independent copy. Another may remain with one provider but use genuinely separate regions, exportable backups, independent DNS, and offline recovery materials.

Financial regulation increasingly expresses this retained customer responsibility. The European Banking Authority's 2019 outsourcing guidelines require covered institutions to govern outsourcing risks and remain capable of oversight rather than becoming empty shells. The later EU Digital Operational Resilience Act, or DORA, requires covered financial entities to maintain and periodically test backup, restoration, and recovery arrangements. Its Article 12 requirements include physical and logical segregation when entities restore backup data using their own systems. These rules have defined scopes and should not be projected retroactively onto every 2021 OVH customer. They show the direction of accountable practice: outsourcing does not outsource the governing body's responsibility for continuity.

DORA's detailed implementation framework goes further. The 2024 delegated regulation on ICT risk management includes scenarios involving partial or total loss of premises and datacentres, third-party service failure, switchovers to redundant capacity, and widespread power outages. Strasbourg is exactly the kind of combined physical and supplier event that a serious exercise should model.

Multi-provider design can reduce some dependencies but is not automatically superior. It adds identity, networking, data-consistency, skill, observability, and incident-coordination complexity. The correct objective is portable, testable recovery for important functions, not an architectural slogan. Sometimes that means active service across independent zones. Sometimes it means warm capacity in another region. Sometimes a protected backup plus infrastructure-as-code and an exercised rebuild meets the business need at much lower cost.

Restoration must be proven from the customer's side

Provider restoration and customer recovery are not the same clock. OVH could declare a datacentre operational when power, network, and a large share of servers were available. A customer still had to validate filesystems, databases, queues, certificates, DNS, integrations, and business transactions. If the original server was destroyed, the customer had to provision an alternative, retrieve data, rebuild the application, and reconcile everything that occurred after the last usable copy.

A mature recovery exercise begins with an assumed loss, not a convenient export. The team should pretend the primary region is inaccessible, normal administrators cannot log in through its identity path, and provider support is saturated. It should obtain the backup using credentials and keys stored outside the failed environment, build clean capacity in the approved destination, restore dependencies in the documented order, validate data integrity, redirect users, and measure the business outcome.

The evidence should answer practical questions. What was the timestamp of the restored database? Which writes were lost? Were all entity-store versions included? Could keys be recovered without weakening access control? Did DNS change within the expected time? Did external payment, email, and identity providers accept the new addresses? How long until the first safe transaction, and how long until full capacity? Who approved the return, and what reconciliation remained?

Backup monitoring alone cannot answer those questions. A green job proves that software wrote something to a target. An integrity test proves that selected data can be read. A technical restore proves that systems can be reconstructed. A service exercise proves that the organization can deliver its priority function under the assumed failure. Each is useful; none should be represented as the next.

This is especially important for small organizations. They may not need active-active infrastructure or a dedicated second cloud. They do need a proportionate path out. A small business can export its database and critical documents to an encrypted destination under a separate account, retain its domain and deployment credentials independently, document a clean rebuild, and test a sample restore. The control should match the cost of losing the records, not the monthly price of the server.

OVHcloud's remediation addressed the physical chain

OVH's response to BEA-RI described a substantial "Hyper Resilience" program. The company said it would strengthen detection, generalize automatic extinguishing where absent, redesign zones and compartmentation, increase ordinary fire resistance from sixty to 120 minutes, and place energy and battery rooms outside datacentre buildings for new sites and where feasible at existing ones. It planned remote electrical cut-offs by zone so responders could isolate danger without unnecessarily disabling unaffected areas.

The response also said local fire services visited every OVH site within four months of the incident, emergency documents and power-cut procedures were revised, and a new industrial-risk department was created. At Strasbourg, OVH installed a private 120-cubic-metre water tank in collaboration with SIS67. It said all sites received a fire-risk analysis and that effectiveness would be measured through a vulnerability study when work was complete. SBG5, opened in July 2022, was presented as an example of the new standards.

These actions map well to the investigation's causal and propagation chain. Suppression addresses early growth. Stronger fire compartments address vertical and building spread. External energy rooms separate ignition hazards from server rooms. Zoned cut-offs address the delay and blast radius of electrical isolation. Water storage addresses first-response capacity. Fire-service visits and exercises address unfamiliarity, plans, and command decisions.

OVHcloud's 2025 universal registration document says the group continued site risk mapping during 2025 and describes Hyper Resilience as strengthening datacentre safety above regulatory and insurer recommendations. It also records a continuing provision for the consequences of the Strasbourg fire, including liability actions. That is evidence of an enduring program and financial treatment, not a site-by-site independent completion certificate.

Accountable closure would publish or provide qualified customers and auditors with a control matrix: which sites have automatic suppression in every relevant energy and IT room; which have 120-minute compartments; which battery rooms are external; which zones have remotely operated isolation; which water-flow requirements have been tested; which fire-service exercises occurred; which findings remain open; and which independent party verified operation. A policy commitment is the beginning of remediation. Coverage and adversarial exercise show whether it works.

The company also deserves credit for preserving a detailed public update log during a difficult recovery, mobilizing specialist cleaning and recovery capacity, replacing infrastructure, communicating product-specific progress, and publishing a formal response to the safety recommendations. Transparency is not complete merely because updates are frequent, but those records allow customers and investigators to reconstruct decisions that would otherwise disappear.

Product design has moved, but configuration still decides resilience

OVHcloud's current documentation is more explicit about failure domains than the pre-fire language visible in the Bati Courtage dispute. Its deployment-mode guide distinguishes one-availability-zone regions, three-zone regions, and local zones. It states that a 1-AZ region remains vulnerable to failures affecting an entire datacentre, while 3-AZ architecture uses independent zones for more demanding production and disaster-recovery cases.

The company's region and availability-zone overview likewise says customers seeking higher resilience should select a supported multi-zone region and build for multiple zones. The verbs matter: the provider supplies zones; the customer must distribute resources and application state across them. Merely launching in a 3-AZ region does not ensure that one virtual machine, one database, or one manually placed volume spans zones.

Current instance-backup documentation now distinguishes local and distant backups. A local backup remains in the same region. A distant backup creates a copy in another selected region and is billed separately. That is much clearer failure-domain language. It also preserves an explicit customer choice, which means procurement and configuration remain part of the control.

Present documentation should not be used to reconstruct what every customer was offered in March 2021. It is relevant to the current accountability question: has the market learned to expose locality and resilience separately? OVHcloud now does so in these product guides. The next assurance step is to make the distinction consistent across product pages, contracts, control-panel defaults, APIs, invoices, and support responses, including products where provider-managed backups follow different rules.

Safer design can also use graduated defaults. A low-cost development service may reasonably default to local backup if the interface labels it as protection from instance failure, not regional disaster. A production database or backup-branded product could require the customer to affirm the failure domain, display a warning when all copies share one site, and offer a remote destination in the same legal region. The objective is informed risk acceptance, not forcing every workload into the most expensive architecture.

The board needs evidence across two control planes

The Strasbourg fire crossed a facility control plane and a customer recovery control plane. OVH's board and risk leadership need assurance over both. Fire engineering cannot be treated as a real-estate footnote, and backup products cannot be treated only as storage revenue.

For the facility layer, leadership should know the maximum probable loss at each site, not just equipment redundancy. Reports should show suppression coverage, compartment integrity, energy-room separation, detection performance, emergency water, power-isolation time, fire-service familiarity, maintenance exceptions, and overdue corrective work. Exercises should assume that ordinary controls fail and that firefighters need immediate, accurate authority to isolate energy.

For the service layer, leadership should know how product failure domains are represented and tested. Reports should show how many services marketed with backup or high-availability language store every copy in one site or region; how many customers have selected distant protection; restore success by product and scale; key and identity dependencies; recovery time distribution; documentation drift; and complaints indicating that customers misunderstood location.

The board should also receive exceptions, not only averages. A 99.99 percent backup-job success rate can coexist with thousands of copies in one physical domain. A global suppression percentage can hide one old high-density building. A mean restore time can hide the largest and most consequential datasets. Tail exposure belongs in governance because Strasbourg was a tail event with concentrated impact.

Independent challenge should trace a customer promise all the way down. Select a service sold as backed up. Record what the interface and contract say. Locate each copy and its control metadata. Remove the primary site from the exercise. Deny normal identity and support paths. Restore in a destination that satisfies the customer's locality rules. Compare measured results with the promised recovery objective. Any break is an actionable gap, whether owned by product, infrastructure, support, or the customer.

What customers should require before calling a service resilient

Organizations do not need private access to every datacentre blueprint. They do need answers detailed enough to decide whether a service fits the consequence of failure. The following questions turn Strasbourg's lessons into procurement evidence:

Question	Evidence that answers it
What is the primary failure domain?	Named region and zone model, number and separation of datacentres, and dependencies on shared power, network, control, and site access.
Where is every backup and replica?	Contractual location matrix covering production, snapshots, backup catalogues, keys, logs, and provider internal replication.
Which events can remove all copies?	Threat model covering fire, flood, site isolation, regional outage, account compromise, malicious deletion, provider control-plane loss, and insolvency or exit.
Who initiates failover or restore?	Operational runbook with roles, credentials, support path, destination capacity, decision rights, and degraded-service criteria.
What are the recovery objectives?	Dataset-specific recovery point and time commitments, including transfer and application validation rather than server provisioning alone.
Has the full path worked?	Dated restore and failover results at representative data volume, with exceptions, reconciliation, and business-owner acceptance.
Does recovery preserve locality?	Approved destination list, legal and subprocessor analysis, customer-controlled encryption where needed, and evidence that emergency placement cannot silently cross the required boundary.
Can the organization leave?	Tested export format, bandwidth and duration estimate, independent DNS and keys, infrastructure definitions, and a current alternative destination.

Answers should be tied to the exact product. A provider's corporate resilience report may not describe the budget VPS, local snapshot, or managed database being purchased. Certifications can establish useful controls but may have scope exclusions. An availability service-level agreement provides a remedy after a threshold is missed; it does not by itself describe data durability or guarantee recovery.

Customers should also verify concentration below reseller names. A managed backup vendor may store its repository in the same OVH region as production. A secondary hosting brand may use OVH underneath. DNS, email, source code, secrets, and incident communications may all share the provider. Diversity is measured by surviving paths, not invoice count.

Finally, a customer must decide how much loss is acceptable. Zero data loss and near-zero downtime across regional disasters require continuous replication, application design, capacity, and operational testing that can be expensive. A weekly offline copy may be adequate for a static archive and disastrous for transactions. Accountability does not demand the same control everywhere. It demands a conscious relationship between consequence, promised recovery, architecture, and evidence.

The enduring signal

The Strasbourg fire was not just an unfortunate ignition followed by a reminder to make backups. It was a demonstration of how abstractions fail under physical stress. Separate buildings formed one emergency site. Healthy servers became unavailable with damaged ones. A completed backup could disappear with production. A European location that served sovereignty and latency could become a concentration of fire risk. A replacement server could restore infrastructure without restoring the customer's business.

The public record also contains meaningful improvement. Detection and overnight staff protected life. Firefighters and the EUROPA fireboat limited spread. OVH carried out a difficult, transparent recovery, accepted the BEA-RI recommendations in operational terms, and launched a broad physical-resilience program. Its current product documentation more clearly distinguishes local from distant backup and single-zone from multi-zone deployment. These are not cosmetic changes.

The remaining accountability standard is evidence over time. OVH should be able to show that the physical controls identified after the fire are installed, maintained, and exercised across relevant sites; that product language maps to real failure domains; and that managed recovery works when a region and its normal control paths are absent. Customers should be able to show that critical data has a usable copy outside the primary hazard, within approved legal boundaries, and that their people can restore it within the business objective.

No cloud provider can promise that a building will never burn. No customer can eliminate every dependency. The credible promise is narrower: one foreseeable physical event will not silently consume production, recovery, and the means to understand what was lost; locality choices will be explicit about both jurisdiction and hazard; and the word "backup" will be supported by the only evidence that ultimately matters, a successful restore under the conditions for which the copy was bought.

Typography

Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.

• Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
• Key elements include font selection, kerning, tracking, and leading.
• Good typography enhances readability and conveys mood or tone in design.