El incendio de OVHcloud demostró que la localidad de datos no es separación ante desastres

Resumen

• Las alarmas de incendio se activaron en el sitio de OVHcloud en Estrasburgo a las 00:35 del 10 de marzo de 2021. El incendio comenzó en las salas de energía de la planta baja de SBG2, destruyó ese edificio, dañó cuatro de las doce salas de SBG1 y obligó a cortar la electricidad en todo el campus. SBG3 y SBG4 no fueron consumidos por el incendio inicial, pero los servicios allí no estaban disponibles debido a que se requirió aislamiento eléctrico, inspección de seguridad, limpieza y reinicio escalonado. No hubo heridos ni fallecidos.
• La investigación francesa de seguridad industrial no determinó la causa precisa de las fallas eléctricas casi simultáneas observadas en un UPS y sus baterías de plomo asociadas. Estableció factores de propagación y respuesta: ningún sistema de extinción automático en ninguno de los cinco edificios de Estrasburgo, rápida propagación del humo debido al diseño abierto de refrigeración de SBG2, capacidad limitada de agua contra incendios y un difícil corte eléctrico en todo el sitio. La detección en funcionamiento, el personal nocturno, la separación resistente al fuego que protege a SBG3 y la llegada de un barco bombero franco-alemán de alta capacidad limitaron consecuencias peores.
• La pérdida de disponibilidad y la pérdida permanente de datos fueron resultados diferentes. OVHcloud informó alrededor de 65.000 clientes y 120.000 servicios interrumpidos, mientras que Netcraft observó aproximadamente 3,6 millones de sitios web en 464.000 dominios fuera de línea. OVHcloud dijo que muchos clientes que perdieron datos no habían seleccionado una copia de seguridad opcional. Eso no cierra la cuestión de la responsabilidad: el propio documento de registro de OVHcloud decía que las copias de seguridad ofrecidas podían almacenarse en el mismo centro de datos o en uno diferente, y una sentencia de apelación posterior se refería a un cliente cuya copia de seguridad automatizada pagada fue destruida en el mismo edificio que la producción.
• El evento expuso un error categórico en la contratación de servicios en la nube. La soberanía de datos, la jurisdicción legal, la latencia, la disponibilidad, la copia de seguridad y la recuperación ante desastres están relacionadas pero no son intercambiables. Mantener los datos en Francia o en la Unión Europea puede satisfacer una política de localidad mientras aún permite que las copias de producción y recuperación compartan un mismo riesgo físico. Por el contrario, una copia geográficamente distante puede permanecer dentro del mismo territorio legal y bajo los mismos controles europeos.
• OVHcloud reveló cambios sustanciales posteriores al incendio, que incluyen supresión automática más amplia, compartimentación más fuerte, salas de energía separadas, cortes eléctricos remotos, auditorías de sitios, trabajo con los servicios de bomberos y nuevas opciones de múltiples zonas y copia de seguridad distante. Sin embargo, el cierre responsable requiere evidencia específica del servicio y del sitio: cobertura de control completada, inspección independiente, ejercicios realistas de incendio y aislamiento de energía, ubicaciones de copia de seguridad declaradas, pruebas de restauración exitosas y prueba de que la recuperación del cliente no depende de la región dañada ni del mismo plano de control.

Un incendio físico se convirtió en un evento de responsabilidad en la nube

La frase "datos en la nube" fomenta una abstracción. Es útil cuando los ingenieros quieren una interfaz estándar para la capacidad informática, pero peligrosa cuando los tomadores de decisiones comienzan a tratar la ubicación, la energía y el fuego como detalles de otros. Cada servidor virtual descansa en una sala. Cada réplica de almacenamiento ocupa equipos conectados a sistemas eléctricos y de refrigeración. Cada flujo de trabajo de recuperación depende de personas, redes, credenciales, catálogos y un lugar desde el cual se pueda obtener capacidad de reemplazo.

Estrasburgo hizo visible esa cadena física. En la madrugada del 10 de marzo de 2021, un incendio destruyó SBG2, uno de los edificios del campus de OVHcloud en Port du Rhin. SBG1 fue parcialmente destruido. Los otros dos centros de datos en el sitio fueron cerrados aunque la actualización inicial de la empresa los describió como no dañados.

Por lo tanto, la pérdida viajó a través de al menos tres mecanismos distintos: el equipo fue destruido físicamente; el equipo en edificios adyacentes fue expuesto a calor, humo, agua o incertidumbre; y el equipo saludable se volvió no disponible cuando el sitio tuvo que ser aislado eléctricamente y puesto a salvo.

Esos mecanismos importan porque corresponden a diferentes controles. La supresión automática y la compartimentación pueden contener un incendio. Las zonas de energía independientes pueden reducir el área que los bomberos necesitan desconectar. Una aplicación multisede puede continuar mientras un sitio no está disponible. Una copia de seguridad remota y verificada puede apoyar la reconstrucción después de que los datos sean destruidos. Una página de estado puede guiar a los clientes a través de esas opciones. Llamar a todo esto "redundancia" oculta quién controla cada capa y qué evento puede sobrevivir.

La reconstrucción pública más autorizada es el informe de investigación de mayo de 2022 del Bureau d'enquêtes et d'analyses sur les risques industriels francés, o BEA-RI,disponible aquí. Su mandato fue la prevención, no la asignación de responsabilidad civil o penal. Ese límite es importante. El informe puede establecer observaciones, posibles causas, factores contribuyentes y recomendaciones de seguridad. No puede convertirse en un hallazgo judicial de que cada debilidad identificada fue negligente o que una debilidad causó legalmente la pérdida de un cliente en particular.

El análisis de responsabilidad hace una pregunta relacionada pero más amplia: ¿qué actores tenían autoridad sobre las condiciones que permitieron que un evento de equipo nocturno se convirtiera en una interrupción de múltiples edificios, una restauración prolongada y una pérdida irreversible del cliente? OVH controlaba el diseño y la operación del sitio, los productos ofrecidos, la precisión de sus descripciones y la respuesta. Los clientes controlaban la clasificación de la carga de trabajo, la arquitectura, muchas selecciones de servicio y copias independientes. Los reguladores y organismos profesionales controlaban partes del marco mínimo.

Ninguno de esos roles borra a los demás.

Lo que la evidencia establece, y lo que no

El informe BEA-RI sitúa la primera alarma a las 00:35. Un guardia llegó a una sala de energía de SBG2 a las 00:37 y encontró humo negro espeso. El edificio fue evacuado a las 00:39, se llamó al servicio de bomberos y rescate de Bas-Rhin a las 00:42, y los primeros equipos llegaron a las 00:59. La página pública de incidentes de OVH utilizó las 00:47 como la hora en que estalló el incendio. La diferencia debe preservarse: la investigación de seguridad tuvo acceso a alarmas y registros operativos, mientras que la página de la empresa proporcionó un marcador público del incidente.

La energía de emergencia a SBG2 se cortó a la 01:13 y a SBG1, SBG3 y SBG4 a la 01:28. Los bomberos habían visto arcos eléctricos y retuvieron el despliegue de agua hasta que el riesgo pudo controlarse. A la 01:42, el fuego se había extendido por el primer piso. Alrededor de las 02:00, los bomberos informaron de la implicación generalizada de SBG2. El barco bombero de alta capacidad EUROPA llegó alrededor de las 03:00, utilizando la vía fluvial adyacente. El incendio se extinguió a las 10:02 y la intervención se consideró completa a las 18:13.

La investigación localizó el origen del incendio en salas que albergaban baterías y equipos de suministro ininterrumpido de energía. Los registros de video y monitoreo mostraron una falla eléctrica casi simultánea en la unidad UPS ASI2 y sus baterías asociadas, que estaban en salas separadas. Se había realizado mantenimiento en el UPS esa mañana y se midieron niveles de humedad inusuales más tarde ese día. Los investigadores enumeraron varias hipótesis, incluyendo humedad, mal funcionamiento relacionado con el mantenimiento u operación fuera de las condiciones esperadas.

Dijeron explícitamente que la evidencia era insuficiente para seleccionar una causa iniciadora precisa.

Esa restricción a menudo se ha perdido en relatos que dicen que un sistema de enfriamiento con fugas o un UPS recién reparado "causó" el incendio. El registro oficial de accidentes ARIA francéses una corroboración útilpara el entorno de la sala de equipos y la respuesta, pero no convierte un mecanismo plausible en una causa raíz probada. Un relato creíble debe decir que los eventos eléctricos tempranos y el área de origen son conocidos; la razón de esos eventos no se resolvió en el informe BEA-RI publicado.

La distinción no impide el análisis de control. Una organización debe estar preparada para fallas de equipos sin saber qué componente fallará a continuación. La protección contra incendios está diseñada en torno a esa incertidumbre. La pregunta responsable no es solo si OVH debería haber predicho una secuencia eléctrica particular. Es si la detección, el control automático, la compartimentación, el agua, el aislamiento eléctrico, el diseño del edificio y los procedimientos de emergencia les dieron a las personas y a los servicios adyacentes suficiente protección independiente después de que algo se encendió.

El edificio detectó peligro pero no pudo contenerlo

El sitio de Estrasburgo hizo bien un trabajo de seguridad de vida. La detección óptica y por aspiración de humo funcionó. El personal nocturno permitió una verificación rápida y una llamada temprana a los bomberos. Todos escaparon y no hubo heridos. El informe BEA-RI acredita esos controles. La responsabilidad debe retener las barreras exitosas tan cuidadosamente como las fallidas, porque el diseño futuro depende de saber qué ganó tiempo realmente.

La detección no fue igualada por la supresión automática. La investigación encontró que ninguno de los cinco edificios del sitio tenía un sistema automático de protección contra incendios. Las salas de baterías y UPS de SBG2 estaban monitoreadas, pero no había un sistema diseñado para extinguir, controlar o retrasar el incendio en su etapa más temprana. Tal sistema podría haber actuado antes del corte eléctrico completo y sin exponer a los bomberos a equipos vivos. No garantizaría la extinción, particularmente en una sala eléctrica, pero podría haber cambiado la curva de crecimiento del incendio.

El edificio luego ayudó a que el humo y el calor se movieran. SBG2 utilizaba un diseño de enfriamiento abierto tipo torre que era altamente permeable al aire exterior. Quince minutos después del evento inicial, los detectores de aspiración se habían activado en todos los niveles. BEA-RI advirtió que la sincronización de los detectores mostraba humo, no necesariamente llamas, pero concluyó que la construcción permitió que el humo se propagara rápidamente. En aproximadamente noventa minutos, SBG2 estaba generalmente involucrado.

El contraste con el adyacente SBG3 fue instructivo: paredes resistentes al fuego de dos horas y una puerta cortafuegos, junto con agua contra incendios, lo dejaron menos dañado que el más pequeño y menos protegido SBG1.

El agua y la energía interactuaron con este diseño. El suministro público de agua contra incendios disponible para la primera respuesta fue inadecuado para el evento en desarrollo, según la investigación, y OVH no tenía su propia reserva de agua de extinción ni una forma de bombear directamente desde el canal cercano. La llegada del EUROPA fue decisiva. La independencia eléctrica, normalmente una fortaleza del centro de datos, también dificultó el aislamiento de emergencia: el sitio combinaba alimentación de la red, generadores y grandes sistemas de baterías.

El servicio de bomberos no pudo aplicar chorros de agua de manera segura hasta que esas fuentes fueron neutralizadas.

Esta es la paradoja de la resiliencia de la infraestructura. La energía de respaldo preserva la computación durante una falla de servicios públicos ordinaria, pero se convierte en otra fuente de energía durante un incendio. El flujo de aire abierto puede reducir el costo de enfriamiento y mejorar la eficiencia operativa, pero puede debilitar la contención de humo y calor. Los equipos densos y los servicios públicos compartidos pueden mejorar la economía de escala, pero concentran las consecuencias. Cada optimización crea un riesgo que debe ser controlado por una barrera diferente.

La respuesta formal de OVH a las recomendaciones del BEA-RI argumentó que la ausencia de supresión automática no violaba un requisito reglamentario y que las pautas de la industria citadas por la investigación eran posteriores al diseño de SBG2. Eso es relevante para el análisis legal y de cumplimiento. No es el final de la responsabilidad operativa. El cumplimiento mínimo pregunta si una regla exigía un control. La resiliencia pregunta si el control era necesario para un escenario creíble de altas consecuencias.

La decisión de OVH después del incendio de generalizar la extinción automática en sitios no equipados es en sí misma evidencia de que el tratamiento del riesgo cambió.

Cuatro edificios no significaron cuatro resultados independientes

Desde el panel de control de un cliente, SBG1, SBG2, SBG3 y SBG4 podrían parecer varias ubicaciones de infraestructura. Durante el incidente formaron un solo sitio de emergencia. SBG2 se quemó. SBG1 y SBG3 se vieron afectados por el incendio en diferentes grados. SBG4 no resultó dañado por el incendio inicial. Sin embargo, se cortó la electricidad en los cuatro, se controló el acceso, se evaluaron los sistemas compartidos y la infraestructura sobreviviente requirió limpieza, inspección, recableado y reinicio escalonado.

El registro de actualizaciones de OVHcloud sobre Estrasburgo hace que el carácter físico de la recuperación sea inusualmente visible. Los equipos retiraron, limpiaron, inspeccionaron, reinstalaron y reiniciaron equipos habitación por habitación, pasillo por pasillo, rack por rack y servidor por servidor. Los servidores contaminados con hollín fueron trasladados a una fábrica en Croix para trabajos especializados. Las máquinas recuperables de SBG1 se transfirieron a otros centros de datos. Especialistas en recuperación de datos intentaron recuperar discos de salas dañadas.

La primera recuperación no fue lineal. SBG3 se volvió operativo el 18 de marzo. En la noche del 19 de marzo, se detectó humo en una sala de baterías no conectada de SBG1. OVH cerró SBG1 y SBG4 nuevamente como precaución y revisó el cronograma de reinicio. La restauración del servicio se reanudó el 22 de marzo. A finales de marzo, los servidores bare-metal de SBG4 eran accesibles y los servicios de SBG3 volvían en porcentajes, mientras que el equipo de SBG1 aún se estaba limpiando, reparando y reubicando.

El documento de registro de OVH posteriormente dijo que la mayoría de los servicios de los clientes regresaron en tres o cuatro semanas y el servicio se restauró por completo a los aproximadamente 65.000 clientes afectados, utilizando alrededor de 120.000 servicios, a principios de mayo. "Servicio restaurado" no puede leerse como "todos los datos restaurados". Se puede aprovisionar un servidor de reemplazo mientras los discos y registros anteriores del cliente permanecen destruidos.

La información sobre la recuperación debe separar la disponibilidad de la infraestructura, el inicio de la aplicación, la restauración de datos, la actualidad de los datos y la aceptación del negocio.

El cierre de todo el sitio también muestra por qué la palabra "centro de datos" puede ser demasiado granular para la planificación de desastres. Un dominio de falla es cualquier cosa que un peligro pueda afectar conjuntamente. Para la respuesta al incendio en Estrasburgo, el dominio relevante incluía los edificios vecinos, los procedimientos de aislamiento de energía, el acceso de emergencia, la capacidad de agua, el humo, las operaciones compartidas y la autoridad de seguridad que controla la reentrada.

Múltiples nombres de edificios no crearon una recuperación independiente si la misma decisión de emergencia podía dejarlos a todos no disponibles.

Contar el impacto requiere más de un número

La medición externa de la interrupción realizada por Netcraft encontró alrededor de 3,6 millones de sitios web en 464.000 dominios distintos fuera de línea y más del 18 por ciento de las direcciones IP atribuidas a OVH en su encuesta reciente no respondían durante la ventana de medición. Esa es una vista a escala de Internet de la pérdida de accesibilidad. Captura subdominios alojados y acuerdos de alojamiento descendentes, razón por la cual supera con creces el recuento de clientes de OVH.

Los 65.000 clientes afectados y 120.000 servicios de OVH describen relaciones comerciales y de productos. Ninguno de los números dice cuántos usuarios finales no pudieron acceder a un servicio, cuántas empresas perdieron un canal de ingresos o cuántos conjuntos de datos fueron irrecuperables. Informes contemporáneos de Reuters identificaron portales gubernamentales, bancos, tiendas, sitios de noticias y otros servicios en línea entre las interrupciones. Esos ejemplos muestran diversidad de consecuencias, no un censo completo.

El efecto también varió con el tiempo. Un sitio web sin estado con código en un repositorio externo podría reconstruirse en otra región en horas. Un servicio administrado con datos de recuperación en manos del proveedor podría volver cuando OVH restaurara su plataforma. Un cliente de bare-metal que espera inspección o reubicación física podría permanecer no disponible durante semanas. Un cliente cuyos únicos datos de producción y copias de seguridad fueron destruidos enfrentó una pérdida permanente, independientemente de la rapidez con que llegara un nuevo servidor vacío.

Un informe de incidente responsable debe utilizar, por lo tanto, varios denominadores: clientes, servicios, servidores físicos, dominios, direcciones externamente inalcanzables, bandas de duración, restauraciones exitosas por parte del proveedor, reconstrucciones iniciadas por el cliente y casos de pérdida permanente de datos. Debe identificar cuántos clientes no tenían copia de seguridad, una copia en el mismo edificio, una copia en el mismo sitio, una región diferente de OVH o una copia bajo control independiente. La evidencia pública no proporciona esa matriz completa.

La ausencia importa porque la remediación debe seguir el mecanismo de pérdida. Si los clientes no seleccionaron una copia de seguridad remota claramente ofrecida, son relevantes una mejor educación sobre el producto y configuraciones predeterminadas más seguras. Si un producto llamado copia de seguridad colocaba todas las copias dentro de un solo edificio sin una divulgación clara del dominio de falla, el diseño del producto y la contratación son centrales.

Si existían copias remotas pero los clientes no podían recuperarlas porque la identidad, las claves, los catálogos o las rutas de red estaban vinculados a Estrasburgo, el problema es la independencia del sistema de recuperación. Agregar estos casos en "algunos clientes no tenían copia de seguridad" impide una responsabilidad precisa.

Una copia de seguridad es una afirmación sobre una restauración futura

El documento de registro de 2021 de OVHcloud decía que los servicios de copia de seguridad eran servicios opcionales pagados para la mayoría de los clientes y que algunos experimentaron pérdida permanente de datos. También decía que los clientes podían elegir opciones ofrecidas en las que los datos respaldados se almacenaban en el mismo centro de datos o en uno diferente. Ciertos servicios administrados por el proveedor, incluido el correo, solo se interrumpieron levemente y no perdieron datos porque OVH los respaldaba.

Esas divulgaciones desmienten dos historias simples. Es inexacto decir que OVH respaldó todos los servicios y no logró preservar todas las copias. También es insuficiente decir que todos los clientes que perdieron datos no compraron copia de seguridad. Los modelos de servicio diferían. Algunos clientes conservaron la responsabilidad de la única copia duradera, algunos seleccionaron opciones del proveedor con diferentes ubicaciones, y algunos consumieron servicios para los cuales OVH controlaba la recuperación.

Una copia de seguridad no se define meramente por un trabajo de copia exitoso. Es una promesa controlada de que, después de fallas especificadas, una organización puede recuperar una versión suficientemente reciente e intacta de su información y usarla para restaurar un servicio prioritario dentro de un tiempo aceptado. Esa promesa contiene al menos seis propiedades:

1. Alcance:los datos, el estado del sistema, las configuraciones, los almacenes de identidad, las claves, el software y las dependencias externas incluidos o excluidos intencionalmente.
2. Punto:la edad máxima aceptable de los datos restaurados, generalmente expresada como un objetivo de punto de recuperación, y el historial de retención necesario para la corrupción o el descubrimiento tardío.
3. Aislamiento:las fallas físicas, lógicas, administrativas y del proveedor que no pueden destruir o alterar cada copia juntas.
4. Acceso:las credenciales, claves de cifrado, catálogos, herramientas, rutas de red y personas autorizadas necesarias para recuperar la copia durante una crisis.
5. Tiempo:la duración probada para obtener capacidad, transferir datos, reconstruir dependencias, reconciliar transacciones y devolver una función comercial a un estado aceptable.
6. Evidencia:monitoreo de que la copia de seguridad se completó, controles de integridad, restauraciones muestreadas, ejercicios completos de servicio y registros retenidos que muestren el resultado.

Estrasburgo fue principalmente una prueba de aislamiento físico y tiempo de recuperación, pero expuso las seis. Una imagen de disco sin registros DNS, secretos, código de implementación o consistencia de base de datos puede no reiniciar una aplicación. Una copia remota cifrada con claves disponibles solo a través de la región fallida puede ser duradera e inutilizable. Un archivo de varios terabytes que tarda días en recuperarse puede no cumplir con un objetivo comercial de doce horas.

Una copia de seguridad almacenada en el mismo dominio de energía e incendio puede estar perfectamente actualizada hasta el evento que se suponía que debía cubrir.

La autoridad francesa de protección de datos CNIL ahora establece la lección física claramente en su guía de seguridad de copias de seguridad: mantener al menos una copia en un sitio geográficamente distinto, aislar al menos una copia fuera de línea, proteger las copias de seguridad al mismo nivel de seguridad que la producción y probar la integridad y la restauración. La guía de seguridad en la nube de CNIL dice a los clientes que verifiquen que un proveedor de nube tenga ubicaciones de copia de seguridad geográficamente remotas de sus centros de datos.

Estos materiales de 2024 son orientación posterior, no prueba del deber contractual preciso para cada servicio de OVH en 2021. Son un punto de referencia claro para la práctica actual.

El caso Bati Courtage hizo que el lenguaje del producto tuviera consecuencias

La disputa de un cliente le da especificidad legal al límite de la copia de seguridad. France Bati Courtage utilizó un servidor privado virtual de OVH y una opción de copia de seguridad automatizada paga. Según el expediente, OVH le informó en abril de 2021 que la copia de seguridad también había sido total e irreversiblemente destruida porque las copias estaban en el mismo edificio que el servidor principal. El cliente buscó millones de euros por pérdida de datos y supuesto daño comercial posterior.

El resultado cambió en apelación. En su sentencia del 24 de abril de 2025, la Corte de Apelación de Douai retuvo un incumplimiento contractual porque OVH no pudo dejar al cliente acceso a la copia de seguridad completada y conservarla para su recuperación. No respaldó la reclamación separada del cliente de que OVH fue culpable por no ubicar los servicios en lugares geográficamente aislados.

También retuvo el hallazgo anterior de que OVH no había cometido falta grave o violaciones graves de seguridad contra incendios en esa disputa, rechazó la defensa de fuerza mayor de OVH, confirmó las limitaciones de responsabilidad relevantes y redujo la indemnización a 1.800,48 euros.

Esa decisión es más estrecha e instructiva que la sentencia de primera instancia ampliamente informada. No establece que cada contrato de copia de seguridad de OVH prometiera un centro de datos remoto. No establece una regla general de que cualquier copia de seguridad en el mismo sitio sea legalmente defectuosa. Sí muestra que la responsabilidad no puede resolverse diciendo "el cliente era dueño de la política de copia de seguridad" cuando el cliente pagó al proveedor para realizar una copia de seguridad y el proveedor tenía obligaciones contractuales con respecto a la copia resultante.

El caso también demuestra por qué las etiquetas contractuales necesitan topología detrás. Términos como "físicamente aislado", "infraestructura", "local", "región" y "remoto" pueden tener diferentes significados. Una matriz de discos separada está aislada de una falla del servidor. Una sala separada puede estar aislada de un incendio en un rack. Un edificio separado puede sobrevivir a algunos eventos de sala pero no necesariamente a un corte de energía en el campus o un cierre perimetral. Una región separada es más fuerte, siempre que las regiones no compartan control, cuenta, clave o dependencias de red que bloqueen la recuperación.

Los clientes no deberían tener que inferir esos límites de un adjetivo de marketing. Una descripción de servicio debe nombrar el dominio de falla de la copia, si la ubicación se selecciona por defecto o por opción, si la ubicación puede cambiar, los peligros que el diseño pretende sobrevivir, el objetivo de recuperación y los deberes restantes del cliente. Los proveedores deben conservar la versión histórica de esas representaciones porque la interfaz y la documentación disponibles cuando se compró un servicio pueden convertirse posteriormente en evidencia central.

La limitación contractual y la responsabilidad operativa también divergen. La indemnización de apelación fue pequeña porque el tribunal aplicó las limitaciones acordadas después de evaluar las reclamaciones y cláusulas ante él. Un límite de responsabilidad no hace que la pérdida permanente de datos sea operativamente aceptable, ni una gran pérdida alegada demuestra que el proveedor deba legalmente esa cantidad. Los contratos asignan la exposición financiera. No restauran la información ni demuestran que un control fue diseñado adecuadamente.

La responsabilidad compartida debe ser lo suficientemente específica para operar

"Responsabilidad compartida" se usa a menudo como una forma educada de decir que ambas partes tenían trabajo que hacer. A menos que se nombre el trabajo, la frase distribuye la culpa después de la falla en lugar de asignar controles antes de ella. Estrasburgo apoya una división más exacta.

OVH era dueña de la probabilidad de que un evento eléctrico local se convirtiera en una pérdida de edificio. Eligió el diseño físico, la detección y supresión de incendios, la compartimentación, el aislamiento de servicios públicos, los procedimientos de emergencia, el marco de mantenimiento, los recursos hídricos y la relación con los bomberos públicos. Los clientes no podían instalar rociadores en SBG2 ni crear un corte de energía de emergencia. Esos son controles del proveedor incluso cuando los contratos de los clientes limitan los daños.

OVH también era dueña de la verdad sobre sus productos. Solo el proveedor podía saber dónde aterrizó una copia de seguridad automatizada, qué servicios respaldaba por defecto, qué regiones compartían sistemas y cómo se comportaba el plano de control durante la pérdida de Estrasburgo. Debía describir esas propiedades con suficiente precisión para que un cliente tomara una decisión de riesgo. Cuando OVH asumió el servicio de copia de seguridad, era dueña del rendimiento del servicio prometido y de la evidencia sobre la copia resultante.

Los clientes eran dueños del modelo de consecuencias. Un proveedor no podía saber, sin un acuerdo administrado específico, si un pequeño servidor virtual albergaba un sitio de prueba desechable o la única copia de años de registros comerciales. El cliente debía clasificar los datos, establecer objetivos de recuperación, seleccionar una arquitectura proporcional al impacto, preservar copias fuera del dominio de falla principal y probar la reconstrucción. Comprar infraestructura no transfería el deber del cliente de decidir cuánto tiempo podía tolerar el negocio su pérdida.

El límite se mueve con el modelo de servicio. En bare-metal no administrado o infraestructura como servicio, el cliente normalmente es dueño de la copia de seguridad y la conmutación por error consistentes con la aplicación. En una base de datos administrada, un producto de correo alojado o un servicio de copia de seguridad explícito, el proveedor es dueño de más de la copia, retención, consistencia y ruta de restauración.

Un revendedor de mercado o proveedor de servicios administrados introduce otra capa: puede seleccionar OVH, configurar la copia de seguridad, representar la resiliencia a sus propios clientes y retener el único acceso administrativo. Los clientes finales necesitan conocer esa cadena.

La agencia francesa de ciberseguridad ANSSI, en sus fundamentos actuales de copia de seguridad, convierte estos deberes en controles prácticos. Exigen objetivos de punto y tiempo de recuperación, el patrón 3-2-1, al menos una copia fuera de línea o fuera del sitio apropiadamente protegida, pruebas de restauración regulares, un orden de restauración y protección de los medios de instalación y configuraciones de aplicación. Para la copia de seguridad externalizada, ANSSI destaca la ubicación en la UE, el comportamiento de replicación del proveedor, el cifrado controlado por el cliente y el tiempo de recuperación.

Este es un recordatorio útil de que la resiliencia física, el aislamiento cibernético, la soberanía y la recuperabilidad deben diseñarse juntos.

La localidad responde a varias preguntas diferentes

La identidad europea de OVHcloud importaba en 2021 y sigue importando. Para gobiernos y organizaciones reguladas que buscan una alternativa a los hiperescaladores no europeos, un proveedor francés que opera centros de datos europeos puede ofrecer ventajas jurisdiccionales, económicas y operativas significativas. El incendio de Estrasburgo no hizo que la soberanía de datos fuera irrelevante. Mostró que la soberanía no es un sustituto de la ingeniería de disponibilidad.

"¿Dónde están los datos?" puede significar al menos cinco cosas:

• Ubicación legal:qué país tiene normas de protección de datos, divulgación, insolvencia y sectoriales que rigen el almacenamiento, procesamiento y acceso.
• Control corporativo:qué empresas matrices, administradores, subprocesadores y demandas legales extranjeras pueden influir en el servicio.
• Ubicación física:qué edificio, llanura aluvial, red, suministro de agua, campus y peligro regional contiene cada copia.
• Ubicación lógica:qué región, zona, cuenta, inquilino, sistema de claves y plano de control debe operar para recuperar o conmutar por error los datos.
• Distancia operativa:cuánta latencia, ancho de banda, personal y tiempo de recuperación separa la producción de sus usuarios y de la copia de recuperación.

Una política que dice "todos los datos deben permanecer en Francia" responde parte de la primera pregunta y limita la tercera. No requiere que la producción y la copia de seguridad ocupen el mismo edificio. Francia contiene múltiples áreas metropolitanas y regiones de nube. Una política que requiere almacenamiento en la UE permite una diversidad geográfica aún mayor mientras preserva un perímetro legal de la UE. Si eso es suficiente depende de la ley, el modelo de amenaza, la sensibilidad de los datos y el objetivo de recuperación de la organización.

La explicación de la Comisión Europea sobre transferencias internacionales también evita una simplificación opuesta: el RGPD no impone una regla absoluta de que los datos personales nunca puedan salir del Espacio Económico Europeo. Proporciona adecuación, salvaguardas y derogaciones limitadas para las transferencias. Algunas organizaciones adoptan requisitos de localidad más estrictos debido a la ley sectorial, la política pública, las promesas contractuales o la exposición a jurisdicciones extranjeras.

La guía de calificación SecNumCloud de ANSSI ilustra el modelo de soberanía más rico. Aborda la ubicación en la UE no solo para los datos del cliente sino también para la administración, supervisión, copias de seguridad, directorios y datos técnicos, considerando el control corporativo y la exposición a leyes no pertenecientes a la UE. Ese marco trata sobre el control del servicio y los datos, no solo la latitud y longitud de un disco.

La conclusión práctica es constructiva: la soberanía y la separación ante desastres pueden reforzarse mutuamente. Un organismo público francés puede mantener la producción sensible en un entorno europeo calificado, mantener una copia de recuperación de la UE geográficamente distinta, usar cifrado y claves controlados por el cliente y conservar procedimientos de exportación probados a otro entorno aprobado. La arquitectura puede costar más y requerir una revisión legal cuidadosa. La compensación debe ser explícita en lugar de oculta dentro de la palabra "local".

La concentración es una propiedad de la aplicación y también del mercado

La interrupción afectó a portales gubernamentales, comercio, medios, juegos y servicios públicos porque muchas organizaciones seleccionaron un proveedor o lo heredaron a través de un proveedor. Esto es concentración de la nube a nivel de mercado. También hubo concentración dentro de aplicaciones individuales: producción, copias de seguridad, DNS, correo electrónico, gestión y herramientas de implementación podían compartir OVH o Estrasburgo incluso cuando aparecían como productos separados.

Las dos formas requieren un tratamiento diferente. Los reguladores pueden monitorear la dependencia sistémica de un pequeño grupo de proveedores de nube. Los equipos de adquisiciones pueden evitar la concentración de proveedores no examinada entre departamentos. Los propietarios de aplicaciones deben mapear las dependencias que determinan si su propio servicio puede recuperarse. Una empresa puede usar tres proveedores de nube en su cartera mientras que un sistema crítico aún no tiene una copia independiente.

Otra puede permanecer con un proveedor pero usar regiones genuinamente separadas, copias de seguridad exportables, DNS independiente y materiales de recuperación fuera de línea.

La regulación financiera expresa cada vez más esta responsabilidad retenida del cliente. Las directrices de 2019 de la Autoridad Bancaria Europea sobre subcontratación requieren que las instituciones cubiertas gobiernen los riesgos de subcontratación y sigan siendo capaces de supervisión en lugar de convertirse en cascarones vacíos. La posterior Ley de Resiliencia Operativa Digital de la UE, o DORA, requiere que las entidades financieras cubiertas mantengan y prueben periódicamente los acuerdos de copia de seguridad, restauración y recuperación.

Sus requisitos del Artículo 12 incluyen segregación física y lógica cuando las entidades restauran datos de copia de seguridad utilizando sus propios sistemas. Estas reglas tienen alcances definidos y no deben proyectarse retroactivamente sobre cada cliente de OVH en 2021. Muestran la dirección de la práctica responsable: la subcontratación no subcontrata la responsabilidad del órgano de gobierno por la continuidad.

El marco de implementación detallado de DORA va más allá. El reglamento delegado de 2024 sobre gestión del riesgo de TIC incluye escenarios que involucran pérdida parcial o total de locales y centros de datos, falla del servicio de terceros, conmutación por error a capacidad redundante y cortes de energía generalizados. Estrasburgo es exactamente el tipo de evento físico y de proveedor combinado que un ejercicio serio debería modelar.

El diseño multi-proveedor puede reducir algunas dependencias pero no es automáticamente superior. Agrega complejidad de identidad, redes, consistencia de datos, habilidades, observabilidad y coordinación de incidentes. El objetivo correcto es la recuperación portátil y comprobable para funciones importantes, no un eslogan arquitectónico. A veces eso significa servicio activo en zonas independientes. A veces significa capacidad en espera en otra región. A veces una copia de seguridad protegida más infraestructura como código y un ejercicio de reconstrucción satisface la necesidad comercial a un costo mucho menor.

La restauración debe probarse desde el lado del cliente

La restauración del proveedor y la recuperación del cliente no son el mismo reloj. OVH podía declarar un centro de datos operativo cuando la energía, la red y una gran parte de los servidores estaban disponibles. Un cliente aún tenía que validar sistemas de archivos, bases de datos, colas, certificados, DNS, integraciones y transacciones comerciales. Si el servidor original fue destruido, el cliente tenía que aprovisionar una alternativa, recuperar datos, reconstruir la aplicación y conciliar todo lo que ocurrió después de la última copia utilizable.

Un ejercicio de recuperación maduro comienza con una pérdida supuesta, no una exportación conveniente. El equipo debe fingir que la región principal es inaccesible, los administradores normales no pueden iniciar sesión a través de su ruta de identidad y el soporte del proveedor está saturado. Debe obtener la copia de seguridad utilizando credenciales y claves almacenadas fuera del entorno fallido, construir capacidad limpia en el destino aprobado, restaurar dependencias en el orden documentado, validar la integridad de los datos, redirigir a los usuarios y medir el resultado comercial.

La evidencia debe responder preguntas prácticas. ¿Cuál era la marca de tiempo de la base de datos restaurada? ¿Qué escrituras se perdieron? ¿Se incluyeron todas las versiones del almacén de objetos? ¿Podrían recuperarse las claves sin debilitar el control de acceso? ¿Cambió el DNS dentro del tiempo esperado? ¿Los proveedores externos de pagos, correo electrónico e identidad aceptaron las nuevas direcciones? ¿Cuánto tiempo hasta la primera transacción segura, y cuánto tiempo hasta la capacidad total? ¿Quién aprobó el regreso, y qué conciliación quedó?

El monitoreo de copia de seguridad por sí solo no puede responder esas preguntas. Un trabajo verde prueba que el software escribió algo en un destino. Una prueba de integridad prueba que los datos seleccionados pueden leerse. Una restauración técnica prueba que los sistemas pueden reconstruirse. Un ejercicio de servicio prueba que la organización puede entregar su función prioritaria bajo la falla supuesta. Cada uno es útil; ninguno debe representarse como el siguiente.

Esto es especialmente importante para las organizaciones pequeñas. Puede que no necesiten infraestructura activa-activa o una segunda nube dedicada. Sí necesitan un camino proporcional de salida. Una pequeña empresa puede exportar su base de datos y documentos críticos a un destino cifrado bajo una cuenta separada, retener su dominio y credenciales de implementación de forma independiente, documentar una reconstrucción limpia y probar una restauración de muestra. El control debe coincidir con el costo de perder los registros, no con el precio mensual del servidor.

La remediación de OVHcloud abordó la cadena física

La respuesta de OVH al BEA-RI describió un programa sustancial "Hyper Resilience". La empresa dijo que fortalecería la detección, generalizaría la extinción automática donde estuviera ausente, rediseñaría zonas y compartimentación, aumentaría la resistencia al fuego ordinaria de sesenta a 120 minutos y colocaría las salas de energía y baterías fuera de los edificios del centro de datos para sitios nuevos y donde fuera factible en los existentes. Planeó cortes eléctricos remotos por zona para que los respondedores pudieran aislar el peligro sin deshabilitar innecesariamente áreas no afectadas.

La respuesta también dijo que los servicios de bomberos locales visitaron todos los sitios de OVH dentro de los cuatro meses posteriores al incidente, se revisaron los documentos de emergencia y los procedimientos de corte de energía, y se creó un nuevo departamento de riesgos industriales. En Estrasburgo, OVH instaló un tanque de agua privado de 120 metros cúbicos en colaboración con SIS67. Dijo que todos los sitios recibieron un análisis de riesgo de incendio y que la efectividad se mediría a través de un estudio de vulnerabilidad una vez completado el trabajo.

SBG5, inaugurado en julio de 2022, se presentó como un ejemplo de los nuevos estándares.

Estas acciones se corresponden bien con la cadena causal y de propagación de la investigación. La supresión aborda el crecimiento temprano. Los compartimentos contra incendios más fuertes abordan la propagación vertical y entre edificios. Las salas de energía externas separan los peligros de ignición de las salas de servidores. Los cortes por zona abordan el retraso y el radio de explosión del aislamiento eléctrico. El almacenamiento de agua aborda la capacidad de la primera respuesta. Las visitas y ejercicios de los servicios de bomberos abordan la falta de familiaridad, los planes y las decisiones de mando.

El documento de registro universal de 2025 de OVHcloud dice que el grupo continuó el mapeo de riesgos del sitio durante 2025 y describe Hyper Resilience como el fortalecimiento de la seguridad del centro de datos por encima de las recomendaciones reglamentarias y de las aseguradoras. También registra una provisión continua para las consecuencias del incendio de Estrasburgo, incluyendo acciones de responsabilidad. Eso es evidencia de un programa duradero y un tratamiento financiero, no un certificado de finalización independiente sitio por sitio.

El cierre responsable publicaría o proporcionaría a clientes calificados y auditores una matriz de control: qué sitios tienen supresión automática en cada sala de energía y TI relevante; cuáles tienen compartimentos de 120 minutos; qué salas de baterías son externas; qué zonas tienen aislamiento operado remotamente; qué requisitos de flujo de agua se han probado; qué ejercicios de servicios de bomberos ocurrieron; qué hallazgos permanecen abiertos; y qué parte independiente verificó la operación. Un compromiso de política es el comienzo de la remediación. La cobertura y el ejercicio adversarial muestran si funciona.

La empresa también merece crédito por preservar un registro de actualización público detallado durante una recuperación difícil, movilizar capacidad especializada de limpieza y recuperación, reemplazar infraestructura, comunicar el progreso específico del producto y publicar una respuesta formal a las recomendaciones de seguridad. La transparencia no es completa solo porque las actualizaciones son frecuentes, pero esos registros permiten a los clientes e investigadores reconstruir decisiones que de otro modo desaparecerían.

El diseño del producto ha avanzado, pero la configuración aún decide la resiliencia

La documentación actual de OVHcloud es más explícita sobre los dominios de falla que el lenguaje anterior al incendio visible en la disputa de Bati Courtage. Su guía de modos de implementación distingue regiones de una zona de disponibilidad, regiones de tres zonas y zonas locales. Afirma que una región de 1 AZ sigue siendo vulnerable a fallas que afectan a todo un centro de datos, mientras que la arquitectura de 3 AZ utiliza zonas independientes para casos de producción y recuperación ante desastres más exigentes.

La visión general de regiones y zonas de disponibilidad de la empresa dice igualmente que los clientes que buscan una mayor resiliencia deben seleccionar una región multizona compatible y construir para múltiples zonas. Los verbos importan: el proveedor suministra zonas; el cliente debe distribuir los recursos y el estado de la aplicación entre ellas. Simplemente lanzar en una región de 3 AZ no asegura que una máquina virtual, una base de datos o un volumen colocado manualmente abarque zonas.

La documentación actual de copia de seguridad de instancias ahora distingue entre copias de seguridad locales y distantes. Una copia de seguridad local permanece en la misma región. Una copia de seguridad distante crea una copia en otra región seleccionada y se factura por separado. Ese es un lenguaje de dominio de falla mucho más claro. También preserva una elección explícita del cliente, lo que significa que la adquisición y la configuración siguen siendo parte del control.

La documentación actual no debe usarse para reconstruir lo que se ofreció a cada cliente en marzo de 2021. Es relevante para la pregunta actual de responsabilidad: ¿ha aprendido el mercado a exponer localidad y resiliencia por separado? OVHcloud ahora lo hace en estas guías de producto. El siguiente paso de aseguramiento es hacer que la distinción sea consistente en las páginas de producto, contratos, valores predeterminados del panel de control, API, facturas y respuestas de soporte, incluidos los productos donde las copias de seguridad administradas por el proveedor siguen reglas diferentes.

El diseño más seguro también puede usar valores predeterminados graduados. Un servicio de desarrollo de bajo costo puede tener como valor predeterminado la copia de seguridad local si la interfaz lo etiqueta como protección contra fallas de instancia, no desastre regional. Una base de datos de producción o un producto etiquetado como copia de seguridad podría requerir que el cliente afirme el dominio de falla, muestre una advertencia cuando todas las copias compartan un sitio y ofrezca un destino remoto en la misma región legal. El objetivo es la aceptación informada del riesgo, no forzar cada carga de trabajo a la arquitectura más costosa.

El consejo necesita evidencia en dos planos de control

El incendio de Estrasburgo cruzó un plano de control de instalaciones y un plano de control de recuperación del cliente. El consejo y el liderazgo de riesgo de OVH necesitan garantía sobre ambos. La ingeniería contra incendios no puede tratarse como una nota al pie inmobiliaria, y los productos de copia de seguridad no pueden tratarse solo como ingresos de almacenamiento.

Para la capa de instalaciones, el liderazgo debe conocer la pérdida máxima probable en cada sitio, no solo la redundancia del equipo. Los informes deben mostrar la cobertura de supresión, la integridad de la compartimentación, la separación de las salas de energía, el rendimiento de la detección, el agua de emergencia, el tiempo de aislamiento de energía, la familiaridad de los bomberos, las excepciones de mantenimiento y el trabajo correctivo atrasado. Los ejercicios deben asumir que los controles ordinarios fallan y que los bomberos necesitan autoridad inmediata y precisa para aislar la energía.

Para la capa de servicio, el liderazgo debe saber cómo se representan y prueban los dominios de falla del producto. Los informes deben mostrar cuántos servicios comercializados con lenguaje de copia de seguridad o alta disponibilidad almacenan todas las copias en un solo sitio o región; cuántos clientes han seleccionado protección distante; éxito de restauración por producto y escala; dependencias de claves e identidad; distribución del tiempo de recuperación; desviación de la documentación; y quejas que indiquen que los clientes malinterpretaron la ubicación.

El consejo también debe recibir excepciones, no solo promedios. Una tasa de éxito de trabajos de copia de seguridad del 99,99% puede coexistir con miles de copias en un solo dominio físico. Un porcentaje global de supresión puede ocultar un edificio antiguo de alta densidad. Un tiempo medio de restauración puede ocultar los conjuntos de datos más grandes y con mayores consecuencias. La exposición de cola pertenece a la gobernanza porque Estrasburgo fue un evento de cola con impacto concentrado.

El desafío independiente debe rastrear una promesa al cliente hasta el final. Seleccione un servicio vendido como respaldado. Registre lo que dicen la interfaz y el contrato. Localice cada copia y sus metadatos de control. Elimine el sitio principal del ejercicio. Deniegue las rutas normales de identidad y soporte. Restaure en un destino que satisfaga las reglas de localidad del cliente. Compare los resultados medidos con el objetivo de recuperación prometido. Cualquier interrupción es una brecha procesable, ya sea propiedad del producto, la infraestructura, el soporte o el cliente.

Lo que los clientes deben exigir antes de llamar resiliente a un servicio

Las organizaciones no necesitan acceso privado a cada plano del centro de datos. Sí necesitan respuestas lo suficientemente detalladas para decidir si un servicio se ajusta a la consecuencia de una falla. Las siguientes preguntas convierten las lecciones de Estrasburgo en evidencia de adquisición:

Las respuestas deben estar vinculadas al producto exacto. Un informe de resiliencia corporativa de un proveedor puede no describir el VPS económico, la instantánea local o la base de datos administrada que se está comprando. Las certificaciones pueden establecer controles útiles pero pueden tener exclusiones de alcance. Un acuerdo de nivel de servicio de disponibilidad proporciona un remedio después de que se supere un umbral; por sí mismo no describe la durabilidad de los datos ni garantiza la recuperación.

Los clientes también deben verificar la concentración por debajo de los nombres de los revendedores. Un proveedor de copias de seguridad administradas puede almacenar su repositorio en la misma región de OVH que la producción. Una marca de alojamiento secundaria puede usar OVH por debajo. DNS, correo electrónico, código fuente, secretos y comunicaciones de incidentes pueden compartir el proveedor. La diversidad se mide por las rutas sobrevivientes, no por el recuento de facturas.

Finalmente, un cliente debe decidir cuánta pérdida es aceptable. La pérdida de datos cero y el tiempo de inactividad cercano a cero en desastres regionales requieren replicación continua, diseño de aplicaciones, capacidad y pruebas operativas que pueden ser costosas. Una copia fuera de línea semanal puede ser adecuada para un archivo estático y desastrosa para transacciones. La responsabilidad no exige el mismo control en todas partes. Exige una relación consciente entre consecuencia, recuperación prometida, arquitectura y evidencia.

La señal perdurable

El incendio de Estrasburgo no fue solo una ignición desafortunada seguida de un recordatorio de hacer copias de seguridad. Fue una demostración de cómo las abstracciones fallan bajo estrés físico. Edificios separados formaron un solo sitio de emergencia. Servidores saludables se volvieron no disponibles junto con los dañados. Una copia de seguridad completada podía desaparecer con la producción. Una ubicación europea que servía a la soberanía y la latencia podía convertirse en una concentración de riesgo de incendio. Un servidor de reemplazo podía restaurar la infraestructura sin restaurar el negocio del cliente.

El registro público también contiene una mejora significativa. La detección y el personal nocturno protegieron vidas. Los bomberos y el barco bombero EUROPA limitaron la propagación. OVH llevó a cabo una recuperación difícil y transparente, aceptó las recomendaciones del BEA-RI en términos operativos y lanzó un amplio programa de resiliencia física. Su documentación actual de productos distingue más claramente entre copia de seguridad local y distante y entre implementación de una sola zona y multizona. Estos no son cambios cosméticos.

El estándar de responsabilidad restante es la evidencia a lo largo del tiempo. OVH debería poder demostrar que los controles físicos identificados después del incendio están instalados, mantenidos y ejercitados en los sitios relevantes; que el lenguaje del producto se asigna a dominios de falla reales; y que la recuperación administrada funciona cuando una región y sus rutas de control normales están ausentes. Los clientes deberían poder demostrar que los datos críticos tienen una copia utilizable fuera del peligro principal, dentro de los límites legales aprobados, y que su personal puede restaurarla dentro del objetivo comercial.

Ningún proveedor de nube puede prometer que un edificio nunca se quemará. Ningún cliente puede eliminar todas las dependencias. La promesa creíble es más estrecha: un evento físico previsible no consumirá silenciosamente la producción, la recuperación y los medios para entender lo que se perdió; las opciones de localidad serán explícitas tanto sobre la jurisdicción como sobre el peligro; y la palabra "copia de seguridad" estará respaldada por la única evidencia que finalmente importa: una restauración exitosa bajo las condiciones para las que se compró la copia.