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

Resumen

• Las alarmas de incendio se activaron en el centro de OVHcloud en Estrasburgo a las 00:35 del 10 de marzo de 2021. El fuego comenzó en las salas de energía en 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, sin embargo los servicios allí quedaron indisponibles porque se requirió aislamiento eléctrico, inspección de seguridad, limpieza y reinicio por etapas. No hubo muertos ni heridos.
• La investigación francesa de seguridad industrial no determinó la causa precisa de los fallos eléctricos casi simultáneos observados en un SAI y sus baterías de plomo asociadas. Sí estableció factores de propagación y respuesta: ningún sistema de extinción automática en ninguno de los cinco edificios de Estrasburgo, movimiento rápido del humo debido al diseño abierto orientado a la refrigeración de SBG2, capacidad limitada de agua contra incendios y un difícil corte eléctrico en todo el sitio. La detección funcional, el personal nocturno, la separación resistente al fuego que protegió SBG3 y la llegada de un barco de bomberos 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ó de aproximadamente 65.000 clientes y 120.000 servicios interrumpidos, mientras que Netcraft observó que alrededor de 3,6 millones de sitios web en 464.000 dominios quedaron 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 de pago fue destruida en el mismo edificio que la producción.
• El suceso expuso un error de categoría en la contratación de servicios en la nube. La soberanía de los datos, la jurisdicción legal, la latencia, la disponibilidad, las copias 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 al tiempo que 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 tras el incendio, incluyendo una extinción automática más extendida, compartimentación más estricta, salas de energía separadas, cortes eléctricos remotos, auditorías de centros, trabajo con los servicios de bomberos y nuevas opciones multizona y de copia de seguridad distante. Sin embargo, un cierre responsable requiere evidencia específica de servicio y de centro: cobertura de controles completada, inspección independiente, ejercicios realistas de incendio y aislamiento eléctrico, 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 para la nube

La expresión «datos en la nube» fomenta una abstracción. Es útil cuando los ingenieros quieren una interfaz estándar para la capacidad de computación, pero peligrosa cuando los responsables comienzan a tratar la ubicación, la electricidad 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 obtener capacidad de reemplazo.

Estrasburgo hizo visible esa cadena física. En las primeras horas del 10 de marzo de 2021, el fuego destruyó SBG2, uno de los edificios del campus de OVHcloud en el Port du Rhin. SBG1 fue parcialmente destruido. Los otros dos centros de datos del sitio fueron apagados aunque la primera actualización de la empresa los describía como no dañados.

Por lo tanto, la pérdida se propagó a través de al menos tres mecanismos distintos: equipos que fueron físicamente destruidos; equipos en edificios adyacentes expuestos al calor, humo, agua o incertidumbre; y equipos sanos que quedaron indisponibles cuando el sitio tuvo que ser aislado eléctricamente y asegurado.

Esos mecanismos importan porque corresponden a diferentes controles. La extinción automática y la compartimentación pueden contener un incendio. Las zonas de alimentación independientes pueden reducir el área que los bomberos necesitan desconectar. Una aplicación multisitio puede continuar mientras un sitio no está disponible. Una copia de seguridad remota y verificada puede respaldar la reconstrucción después de la destrucción de los datos. 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 elinforme de investigación de mayo de 2022del Bureau d'enquetes et d'analyses sur les risques industriels (BEA-RI) francés. Su mandato era la prevención, no la asignación de responsabilidad civil o penal. Este límite es importante. El informe puede establecer observaciones, posibles causas, factores contribuyentes y recomendaciones de seguridad. No puede convertirse en una conclusión 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 plantea una pregunta relacionada pero más amplia: ¿qué actores tenían autoridad sobre las condiciones que permitieron que un incidente de equipos nocturno se convirtiera en una interrupción de múltiples edificios, una restauración prolongada y una pérdida irreversible para los clientes? OVH controlaba el diseño y la operación del sitio, los productos ofrecidos, la exactitud de sus descripciones y la respuesta. Los clientes controlaban la clasificación de cargas de trabajo, la arquitectura, muchas selecciones de servicios y las copias independientes.

Los reguladores y organismos profesionales controlaban partes del marco mínimo. Ninguno de esos roles anula a los otros.

Lo que la evidencia establece, y lo que no

El informe del 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 denso. El edificio fue evacuado a las 00:39, se llamó al servicio de bomberos del 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 se declaró el incendio. La diferencia debe preservarse en lugar de forzarse a una sola marca temporal: la investigación de seguridad tuvo acceso a alarmas y registros operativos, mientras que la página de la empresa proporcionó un marcador de incidente público.

La alimentación 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 masivo de agua hasta que se pudo controlar el riesgo. A la 01:42 el fuego se había extendido por la primera planta. Alrededor de las 02:00, los bomberos informaron de la afectación generalizada de SBG2. El barco de bomberos de alta capacidad EUROPA llegó hacia las 03:00, extrayendo agua de la vía fluvial adyacente. El incendio se extinguió a las 10:02 y la intervención se dio por concluida a las 18:13.

La investigación situó el origen del fuego en salas que albergaban baterías y equipos de alimentación ininterrumpida. Los registros de vídeo y monitorización mostraron un fallo eléctrico casi simultáneo en la unidad SAI ASI2 y sus baterías asociadas, que estaban en salas separadas. Se había realizado mantenimiento en el SAI 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 o funcionamiento fuera de las condiciones esperadas.

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

Esa contención se ha perdido a menudo en relatos que dicen que un sistema de refrigeración con fugas o un SAI recientemente reparado «causó» el incendio. Elregistro oficial del accidente en ARIAes una corroboración útil del entorno de la sala de máquinas y la respuesta, pero no convierte un mecanismo plausible en una causa raíz probada. Un relato creíble debe decir que se conocen los primeros eventos eléctricos y el área de origen; la razón por la que ocurrieron esos eventos quedó sin resolver en el informe publicado del BEA-RI.

La distinción no impide el análisis de control. Una organización debe estar preparada para fallos de equipos sin saber qué componente fallará a continuación. La protección contra incendios se diseña en torno a esa incertidumbre. La pregunta responsable no es solo si OVH debería haber previsto una secuencia eléctrica particular, sino 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 dieron a las personas y a los servicios adyacentes suficiente protección independiente después de que algo se incendiara.

El edificio detectó el peligro pero no pudo contenerlo

El centro de Estrasburgo cumplió bien una tarea de seguridad vital. La detección óptica y por aspiración de humo funcionó. La presencia de personal nocturno permitió una verificación rápida y una llamada temprana a los bomberos. Todos escaparon y no hubo heridos. El informe del BEA-RI valora esos controles. La rendición de cuentas debe conservar las barreras que funcionaron tan cuidadosamente como las que fallaron, porque el diseño futuro depende de saber qué es lo que realmente dio tiempo.

La detección no fue acompañada de una extinción automática. La investigación constató que ninguno de los cinco edificios del centro disponía de un sistema automático de protección contra incendios. Las salas de baterías y SAI de SBG2 estaban monitorizadas, pero no existía ningún sistema diseñado para extinguir, controlar o retrasar el fuego en su etapa más temprana. Un sistema así podría haber actuado antes del apagado eléctrico completo y sin exponer a los bomberos a equipos en tensión. No habría garantizado la extinción, especialmente en una sala eléctrica, pero podría haber cambiado la curva de crecimiento del fuego.

Luego el edificio ayudó al humo y al calor a moverse. SBG2 utilizaba un diseño de refrigeración abierto, en torre, muy permeable al aire exterior. A los quince minutos del evento inicial, los detectores por aspiración se habían activado en todos los niveles. El BEA-RI advirtió que la temporizació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 afectado.

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

El agua y la electricidad interactuaron con este diseño. El suministro público de agua contra incendios disponible para la primera respuesta era inadecuado para el evento en desarrollo, según la investigación, y OVH no tenía ni 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 un punto fuerte de los centros de datos, también dificultó el aislamiento de emergencia: el sitio combinaba alimentación de la red, generadores y grandes sistemas de baterías.

Los bomberos no pudieron aplicar grandes caudales de agua de forma segura hasta que esas fuentes fueron neutralizadas.

Esta es la paradoja de la resiliencia de infraestructuras. La alimentación de respaldo mantiene la computación durante un fallo de la red eléctrica ordinario, pero se convierte en otra fuente de energía que gestionar durante un incendio. El flujo de aire abierto puede reducir el coste de refrigeración y mejorar la eficiencia operativa, pero puede debilitar la contención de humo y calor. Los equipos densos y los servicios compartidos del centro pueden mejorar las economías de escala, pero concentran las consecuencias. Cada optimización crea un riesgo que debe ser controlado por una barrera diferente.

Larespuesta formal de OVH a las recomendaciones del BEA-RIargumentó que la ausencia de extinción automática no incumplía ningún requisito reglamentario y que la guía industrial citada por la investigación era posterior 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 norma obligaba a un control. La resiliencia pregunta si el control era necesario para un escenario creíble de alta consecuencia. La decisión de OVH después del incendio de generalizar la extinción automática en los centros no equipados es en sí misma evidencia de que el tratamiento del riesgo cambió.

Cuatro edificios no significaban cuatro resultados independientes

Desde un panel de control de cliente, SBG1, SBG2, SBG3 y SBG4 podían parecer varias ubicaciones de infraestructura. Durante el incidente formaron un único centro de emergencia. SBG2 ardió. SBG1 y SBG3 se vieron afectados por el fuego en distintos grados. SBG4 no fue dañado por el incendio inicial. Sin embargo, se cortó la electricidad a los cuatro, se controlaron los accesos, hubo que evaluar los sistemas compartidos y la infraestructura superviviente requirió limpieza, inspección, recableado y reinicio por etapas.

Elregistro de actualizaciones de Estrasburgo de OVHcloudde aquel momento hace inusualmente visible el carácter físico de la recuperación. Los equipos retiraron, limpiaron, inspeccionaron, reinstalaron y reiniciaron los equipos sala por sala, pasillo por pasillo, bastidor por bastidor y servidor por servidor. Los servidores contaminados de hollín se trasladaron 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 entró en funcionamiento el 18 de marzo. En la tarde del 19 de marzo, se detectó humo en una sala de baterías no conectada de SBG1. OVH apagó SBG1 y SBG4 de nuevo por precaución y revisó el calendario de reinicio. La restauración del servicio se reanudó el 22 de marzo. A finales de marzo, los servidores bare-metal de SBG4 estaban accesibles y los servicios de SBG3 volvían en porcentajes, mientras que los equipos de SBG1 seguían limpiándose, reparándose y reubicándose.

El documento de registro de OVH dijo más tarde que la mayoría de los servicios de los clientes se restablecieron en un plazo de tres a cuatro semanas y que el servicio se restableció por completo para los aproximadamente 65.000 clientes afectados, que utilizaban unos 120.000 servicios, a principios de mayo. «Servicio restablecido» 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.

Los informes de recuperación deben 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 por parte del negocio.

El apagado de todo el centro también muestra por qué la palabra «centro de datos» puede ser demasiado granular para la planificación de desastres. Un dominio de fallo es todo lo que un peligro puede afectar conjuntamente. Para la respuesta al incendio en Estrasburgo, el dominio relevante incluía los edificios vecinos, los procedimientos de aislamiento eléctrico, el acceso de emergencia, la capacidad de agua, el humo, las operaciones compartidas y la autoridad de seguridad que controlaba la reentrada.

Tener varios nombres de edificios no creaba una recuperación independiente si la misma decisión de emergencia podía hacer que todos ellos quedaran indisponibles.

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

Lamedición externa de la interrupción por Netcraftencontró 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 direcciones IP atribuidas a OVH en su encuesta reciente que no respondieron durante la ventana medida. Esa es una vista a escala de Internet de la pérdida de alcanzabilidad. Captura subdominios alojados y acuerdos de alojamiento posteriores, por lo que supera con creces la cantidad de clientes de OVH.

Los 65.000 clientes afectados y 120.000 servicios de OVH describen relaciones comerciales y de producto. Ninguna de estas cifras dice cuántos usuarios finales no pudieron acceder a un servicio, cuántas empresas perdieron un canal de ingresos ni cuántos conjuntos de datos se perdieron irremediablemente. Elreportaje de Reutersde la época identificó portales gubernamentales, bancos, tiendas, sitios de noticias y otros servicios en línea entre las afectaciones. Esos ejemplos muestran diversidad de consecuencias, no un censo completo.

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

Por lo tanto, un informe de incidente responsable debería utilizar varios denominadores: clientes, servicios, servidores físicos, dominios, direcciones externas no alcanzables, bandas de duración, restauraciones exitosas por el proveedor, reconstrucciones iniciadas por el cliente y casos de pérdida permanente de datos. Debería identificar cuántos clientes no tenían copia de seguridad, una copia en el mismo edificio, una copia en el mismo centro, una copia en 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, una mejor educación sobre el producto y unos valores predeterminados más seguros son relevantes. Si un producto llamado copia de seguridad colocaba todas las copias en un mismo edificio sin una divulgación clara del dominio de fallo, 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, la independencia del sistema de recuperación es el problema. Agrupar 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

Eldocumento de registro de 2021 de OVHclouddecía que los servicios de copia de seguridad de datos eran servicios opcionales de pago 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 un centro de datos diferente. Ciertos servicios gestionados por el proveedor, incluido el correo, solo se interrumpieron levemente y no perdieron datos porque OVH los respaldaba.

Estas declaraciones desmienten dos historias simples. Es inexacto decir que OVH respaldaba todos los servicios y no logró preservar todas las copias. También es inadecuado decir que cada cliente que perdió datos no había comprado una copia de seguridad. Los modelos de servicio diferían. Algunos clientes conservaban la responsabilidad de la única copia duradera, otros seleccionaban opciones del proveedor con diferentes ubicaciones y otros consumían servicios para los que OVH controlaba la recuperación.

Una copia de seguridad no se define simplemente por un trabajo de copia exitoso. Es una promesa controlada de que, después de fallos especificados, 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 incluidas o excluidas intencionadamente.
2. Punto:la antigüedad máxima aceptable de los datos restaurados, generalmente expresada como objetivo de punto de recuperación, y el historial de retención necesario para la corrupción o el descubrimiento tardío.
3. Aislamiento:los fallos físicos, lógicos, administrativos y de proveedor que no pueden destruir o alterar todas las copias conjuntamente.
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, conciliar transacciones y devolver una función de negocio a un estado aceptable.
6. Evidencia:monitoreo de que la copia de seguridad se completó, verificaciones de integridad, restauraciones de muestra, ejercicios completos de servicio y registros conservados que muestran 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 despliegue 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 pero inutilizable. Un archivo de varios terabytes que tarda días en recuperarse puede incumplir un objetivo de negocio 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 expone ahora la lección física claramente en suguí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 con el mismo nivel de seguridad que la producción y probar la integridad y la restauración. Laguía de seguridad en la nube de la CNILindica 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 de la obligación contractual precisa 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 confiere especificidad legal al límite de la copia de seguridad. France Bati Courtage utilizaba un servidor privado virtual de OVH y una opción de copia de seguridad automatizada de pago. Según el expediente, OVH le informó en abril de 2021 de que la copia de seguridad también había sido destruida total e irreversiblemente porque las copias estaban en el mismo edificio que el servidor principal. El cliente reclamó millones de euros por la pérdida de datos y el presunto perjuicio empresarial derivado.

El resultado cambió en apelación. En susentencia del 24 de abril de 2025, el Tribunal de Apelación de Douai apreció un incumplimiento contractual porque OVH no pudo dejar al cliente el acceso a la copia de seguridad completada y conservarla para su recuperación. No estimó la pretensión separada del cliente de que OVH era responsable por no ubicar los servicios en lugares geográficamente aislados. También mantuvo la conclusión anterior de que OVH no había cometido falta grave ni infracciones graves de seguridad contra incendios en esa disputa, rechazó la defensa de fuerza mayor de OVH, mantuvo las limitaciones de responsabilidad aplicables y redujo la indemnización a 1.800,48 euros.

Ese fallo es más limitado y más instructivo que la indemnización de primera instancia ampliamente difundida. No establece que todo 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 centro sea legalmente defectuosa. Sí muestra que la responsabilidad no puede resolverse diciendo «el cliente era dueño de la política de copias de seguridad» cuando el cliente pagó al proveedor para que realizara una copia de seguridad y el proveedor tenía obligaciones contractuales respecto a la copia resultante.

El caso también demuestra por qué las etiquetas contractuales necesitan una topología detrás. Términos como «aislado físicamente», «infraestructura», «local», «región» y «remoto» pueden tener diferentes significados. Una matriz de discos separada está aislada de un fallo de servidor. Una sala separada puede estar aislada de un incendio en un bastidor. Un edificio separado puede sobrevivir a algunos eventos en una sala, pero no necesariamente a un corte de energía del campus o al cierre del perímetro.

Una región separada es más fuerte, siempre que las regiones no compartan dependencias de control, cuenta, clave o red que bloqueen la recuperación.

Los clientes no deberían tener que inferir esos límites a partir de un adjetivo de marketing. La descripción de un servicio debe nombrar el dominio de fallo 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 soportar, 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 contrató un servicio pueden convertirse más tarde 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 tras evaluar las pretensiones y cláusulas que tenía ante sí. Un límite de responsabilidad no hace que la pérdida permanente de datos sea operativamente aceptable, como tampoco una presunta pérdida elevada demuestra que el proveedor deba legalmente esa cantidad. Los contratos asignan exposición financiera. No restauran información ni prueban que un control estuviera diseñado adecuadamente.

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

La «responsabilidad compartida» se utiliza 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 culpas después del fallo en lugar de asignar controles antes de él. Estrasburgo respalda una división más exacta.

OVH era responsable de la probabilidad de que un evento eléctrico local se convirtiera en la pérdida de un edificio. Eligió el diseño físico, la detección y extinción de incendios, la compartimentación, el aislamiento de servicios, 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 emergencia. Esos son controles del proveedor incluso cuando los contratos de los clientes limitan los daños.

OVH también era responsable de la veracidad sobre sus productos. Solo el proveedor podía saber dónde aterrizaba 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. Tenía que describir esas propiedades con suficiente precisión para que un cliente pudiera tomar una decisión de riesgo. Cuando OVH asumía el servicio de copia de seguridad, era responsable de la ejecución del servicio prometido y de la evidencia sobre la copia resultante.

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

El límite se desplaza con el modelo de servicio. En el bare-metal no gestionado o en infraestructura como servicio, el cliente normalmente es responsable de la copia de seguridad consistente con la aplicación y de la conmutación por error. En una base de datos gestionada, un producto de correo alojado o un servicio de copia de seguridad explícito, el proveedor asume más parte de la copia, la retención, la consistencia y la ruta de restauración.

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

Losfundamentos actuales de copias de seguridad de la agencia francesa de ciberseguridad ANSSIconvierten estos deberes en controles prácticos. Piden objetivos de punto y tiempo de recuperación, el patrón 3-2-1, al menos una copia fuera de línea o adecuadamente protegida y externa, pruebas periódicas de restauración, un orden de restauración y protección de los medios de instalación y las configuraciones de las aplicaciones. Para las copias de seguridad externalizadas, 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 conjuntamente.

La localidad responde a varias preguntas diferentes

La identidad europea de OVHcloud importaba en 2021 y sigue importando. Para los gobiernos y las 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 irrelevante la soberanía de los datos. Demostró 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é normas de protección de datos, divulgación, insolvencia y sectoriales del país rigen el almacenamiento, el procesamiento y el acceso.
• Control corporativo:qué empresas matrices, administradores, subencargados y demandas legales extranjeras pueden influir en el servicio.
• Ubicación física:qué edificio, llanura de inundación, red eléctrica, 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 deben funcionar para recuperar o conmutar los datos.
• Distancia operativa:cuánta latencia, ancho de banda, personal y tiempo de recuperación separan la producción de sus usuarios y de la copia de recuperación.

Una política que diga «todos los datos deben permanecer en Francia» responde a parte de la primera pregunta y limita la tercera. No exige 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 exija almacenamiento en la UE permite una diversidad geográfica aún mayor manteniendo un perímetro legal europeo. Si eso es suficiente depende de la legislación de la organización, el modelo de amenazas, la sensibilidad de los datos y el objetivo de recuperación.

Laexplicación de la Comisión Europea sobre transferencias internacionalestambién impide una simplificación opuesta: el RGPD no impone una norma absoluta de que los datos personales nunca puedan salir del Espacio Económico Europeo. Ofrece adecuación, garantías y excepciones limitadas para las transferencias. No obstante, algunas organizaciones adoptan requisitos de localidad más estrictos debido a la legislación sectorial, políticas públicas, promesas contractuales o exposición a jurisdicción extranjera.

Laguía de cualificación SecNumCloud de la ANSSIilustra 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, la supervisión, las copias de seguridad, los directorios y los datos técnicos, considerando al mismo tiempo el control corporativo y la exposición a leyes no comunitarias. Ese marco trata del control sobre el servicio y los datos, no meramente de 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 cualificado, mantener una copia de recuperación geográficamente distinta dentro de la UE, utilizar cifrado y claves controladas 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. El compromiso debe ser explícito en lugar de ocultarse dentro de la palabra «local».

La concentración es una propiedad de la aplicación tanto como del mercado

La interrupción afectó a portales gubernamentales, comercio, medios de comunicación, juegos y servicios de cara al público porque muchas organizaciones seleccionaron un mismo proveedor o lo heredaron a través de un proveedor. Esta es la concentración de la nube a nivel de mercado. También hubo concentración dentro de las aplicaciones individuales: la producción, las copias de seguridad, DNS, el correo electrónico, la gestión y las herramientas de despliegue 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 compras pueden evitar una concentración no examinada de proveedores entre departamentos. Los propietarios de aplicaciones deben mapear las dependencias que determinan si su propio servicio puede recuperarse. Una empresa puede utilizar tres proveedores de nube en toda su cartera mientras un sistema crítico sigue sin tener una copia independiente.

Otra puede permanecer con un solo proveedor pero utilizar regiones realmente 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. Lasdirectrices de externalización de 2019 de la Autoridad Bancaria Europea (EBA)exigen que las entidades cubiertas gobiernen los riesgos de externalización y sigan siendo capaces de supervisión en lugar de convertirse en cáscaras vacías. La posterior Ley de Resiliencia Operativa Digital de la UE (DORA) exige a las entidades financieras cubiertas que mantengan y prueben periódicamente las disposiciones de copia de seguridad, restauración y recuperación. Susrequisitos del artículo 12incluyen la segregación física y lógica cuando las entidades restauran datos de copia de seguridad utilizando sus propios sistemas. Estas normas tienen ámbitos definidos y no deben proyectarse retroactivamente sobre cada cliente de OVH de 2021. Muestran la dirección de la práctica responsable: la externalización no externaliza la responsabilidad del órgano de gobierno por la continuidad.

El marco de implementación detallado de DORA va más allá. Elreglamento delegado de 2024 sobre la gestión del riesgo de las TICincluye escenarios que implican la pérdida parcial o total de locales y centros de datos, fallos de servicios de terceros, conmutaciones 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 multiproveedor puede reducir algunas dependencias pero no es automáticamente superior. Añade complejidad de identidad, redes, consistencia de datos, habilidades, observabilidad y coordinación de incidentes. El objetivo correcto es una recuperación portable y comprobable para las funciones importantes, no un eslogan arquitectónico. A veces eso significa un servicio activo en zonas independientes. A veces significa capacidad templada en otra región. A veces una copia de seguridad protegida más infraestructura como código y una reconstrucción ejercitada satisface la necesidad del negocio a un coste mucho menor.

La restauración debe probarse desde el lado del cliente

La restauración por parte del proveedor y la recuperación por parte del cliente no son el mismo reloj. OVH podía declarar operativo un centro de datos cuando la alimentación, la red y una gran proporción de 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 los datos, reconstruir la aplicación y conciliar todo lo ocurrido después de la última copia utilizable.

Un ejercicio de recuperación maduro comienza con una pérdida asumida, no con una exportación conveniente. El equipo debe simular que la región primaria es inaccesible, que los administradores normales no pueden iniciar sesión a través de su ruta de identidad y que 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 las dependencias en el orden documentado, validar la integridad de los datos, redirigir a los usuarios y medir el resultado para el negocio.

La evidencia debe responder a 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? ¿Se pudieron recuperar las claves sin debilitar el control de acceso? ¿Cambió el DNS en el tiempo esperado? ¿Aceptaron los proveedores externos de pagos, correo electrónico e identidad las nuevas direcciones? ¿Cuánto tiempo hasta la primera transacción segura y cuánto hasta la plena capacidad? ¿Quién aprobó el regreso y qué conciliación quedó pendiente?

El monitoreo de copias de seguridad por sí solo no puede responder a esas preguntas. Un trabajo en verde demuestra que el software escribió algo en un destino. Una prueba de integridad demuestra que los datos seleccionados se pueden leer. Una restauración técnica demuestra que los sistemas se pueden reconstruir. Un ejercicio de servicio demuestra que la organización puede prestar su función prioritaria bajo el fallo asumido. Cada uno es útil; ninguno debe presentarse como el siguiente.

Esto es especialmente importante para las organizaciones pequeñas. Puede que no necesiten una infraestructura activa-activa o una segunda nube dedicada. Necesitan un camino de salida proporcionado. Una pequeña empresa puede exportar su base de datos y sus documentos críticos a un destino cifrado bajo una cuenta separada, conservar su dominio y sus credenciales de despliegue de forma independiente, documentar una reconstrucción limpia y probar una restauración de muestra. El control debe coincidir con el coste 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 importante programa «Hyper Resilience». La compañía dijo que reforzaría la detección, generalizaría la extinción automática donde faltara, rediseñaría las zonas y la 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 en los nuevos centros y, cuando fuera posible, en los existentes. Planeó cortes eléctricos remotos por zona para que los servicios de emergencia pudieran aislar el peligro sin deshabilitar innecesariamente las áreas no afectadas.

La respuesta también dijo que los servicios de bomberos locales visitaron todos los centros de OVH en los cuatro meses siguientes al incidente, se revisaron los documentos de emergencia y los procedimientos de corte eléctrico, y se creó un nuevo departamento de riesgos industriales. En Estrasburgo, OVH instaló un depósito de agua privado de 120 metros cúbicos en colaboración con el SIS67. Dijo que todos los centros recibieron un análisis de riesgo de incendio y que la eficacia se mediría a través de un estudio de vulnerabilidad cuando terminaran los trabajos.

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

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

Eldocumento de registro universal de 2025 de OVHclouddice que el grupo continuó la cartografía de riesgos de los centros durante 2025 y describe Hyper Resilience como el refuerzo de la seguridad de los centros de datos por encima de las recomendaciones regulatorias y de las aseguradoras. También registra una provisión continuada para las consecuencias del incendio de Estrasburgo, incluidas las acciones de responsabilidad. Es una evidencia de un programa duradero y de un tratamiento financiero, no un certificado independiente de finalización centro por centro.

Un cierre responsable publicaría o proporcionaría a los clientes cualificados y a los auditores una matriz de control: qué centros tienen extinción automática en todas las salas de energía y TI relevantes; 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 bomberos se han realizado; qué hallazgos siguen abiertos; y qué parte independiente verificó el funcionamiento. Un compromiso político es el comienzo de la remediación. La cobertura y el ejercicio adversarial muestran si funciona.

La compañía también merece crédito por preservar un registro de actualizaciones público detallado durante una recuperación difícil, movilizar capacidad especializada de limpieza y recuperación, reemplazar infraestructura, comunicar el progreso específico de los productos y publicar una respuesta formal a las recomendaciones de seguridad. La transparencia no es completa simplemente porque las actualizaciones sean frecuentes, pero esos registros permiten a 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 fallo que el lenguaje anterior al incendio visible en la disputa Bati Courtage. Suguía de modos de desplieguedistingue 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 fallos que afecten 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.

Ladescripción general de regiones y zonas de disponibilidad de la compañíatambién dice que los clientes que buscan una mayor resiliencia deben seleccionar una región multizona compatible y diseñar para múltiples zonas. Los verbos importan: el proveedor suministra las zonas; el cliente debe distribuir los recursos y el estado de la aplicación entre ellas. El simple hecho de lanzar en una región 3-AZ no asegura que una máquina virtual, una base de datos o un volumen colocado manualmente abarquen zonas.

Ladocumentación actual de copias de seguridad de instanciasahora 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 fallo mucho más claro. También conserva una elección explícita del cliente, lo que significa que la contratación y la configuración siguen siendo parte del control.

La documentación actual no debe utilizarse para reconstruir lo que se ofrecía a cada cliente en marzo de 2021. Es pertinente para la pregunta de responsabilidad actual: ¿ha aprendido el mercado a exponer la localidad y la 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 coherente en todas las páginas de producto, contratos, valores predeterminados del panel de control, API, facturas y respuestas de soporte, incluidos los productos en los que las copias de seguridad gestionadas por el proveedor siguen reglas diferentes.

Un diseño más seguro también puede utilizar valores predeterminados graduados. Un servicio de desarrollo de bajo coste puede, razonablemente, tener por defecto una copia de seguridad local si la interfaz la etiqueta como protección contra fallos de instancia, no contra desastres regionales. Una base de datos de producción o un producto de copia de seguridad podría exigir al cliente que confirme el dominio de fallo, mostrar una advertencia cuando todas las copias compartan un mismo centro y ofrecer un destino remoto en la misma región legal.

El objetivo es una aceptación informada del riesgo, no forzar cada carga de trabajo a la arquitectura más cara.

El consejo necesita evidencia en dos planos de control

El incendio de Estrasburgo atravesó un plano de control de las instalaciones y un plano de control de recuperación del cliente. El consejo y la dirección de riesgos de OVH necesitan garantías sobre ambos. La ingeniería contra incendios no puede tratarse como una nota a pie de página inmobiliaria, y los productos de copia de seguridad no pueden tratarse solo como ingresos por almacenamiento.

Para la capa de instalaciones, la dirección debe conocer la pérdida máxima probable en cada centro, no solo la redundancia de equipos. Los informes deben mostrar la cobertura de extinción, la integridad de los compartimentos, la separación de las salas de energía, el rendimiento de la detección, el agua de emergencia, el tiempo de aislamiento eléctrico, la familiaridad de los servicios de bomberos, las excepciones de mantenimiento y los trabajos correctivos atrasados. Los ejercicios deben asumir que los controles ordinarios fallan y que los bomberos necesitan una autorización inmediata y precisa para aislar la energía.

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

El consejo también debe recibir las excepciones, no solo los promedios. Una tasa de éxito del 99,99 por ciento en los trabajos de copia de seguridad puede coexistir con miles de copias en un solo dominio físico. Un porcentaje global de extinció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 de mayores consecuencias. La exposición extrema pertenece a la gobernanza porque Estrasburgo fue un evento extremo con impacto concentrado.

Un desafío independiente debe rastrear una promesa al cliente hasta el final. Seleccionar un servicio vendido como respaldado. Registrar lo que dicen la interfaz y el contrato. Localizar cada copia y sus metadatos de control. Eliminar el sitio primario del ejercicio. Denegar las rutas normales de identidad y soporte. Restaurar en un destino que satisfaga las reglas de localidad del cliente. Comparar los resultados medidos con el objetivo de recuperación prometido. Cualquier ruptura es una brecha procesable, ya sea propiedad del producto, la infraestructura, el soporte o el cliente.

Lo que los clientes deberían exigir antes de llamar resiliente a un servicio

Las organizaciones no necesitan acceso privado a cada plano de un centro de datos. Necesitan respuestas lo suficientemente detalladas para decidir si un servicio se ajusta a las consecuencias de un fallo. Las siguientes preguntas convierten las lecciones de Estrasburgo en evidencia para la contratación:

Las respuestas deben estar vinculadas al producto exacto. Un informe de resiliencia corporativa del proveedor puede no describir el VPS económico, la instantánea local o la base de datos gestionada 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 recurso después de que se supere un umbral; no describe por sí mismo la durabilidad de los datos ni garantiza la recuperación.

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

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

La señal duradera

El incendio de Estrasburgo no fue solo un desafortunado incendio seguido de un recordatorio para hacer copias de seguridad. Fue una demostración de cómo las abstracciones fallan bajo estrés físico. Edificios separados formaron un único centro de emergencia. Servidores sanos quedaron indisponibles 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 mejoras significativas. La detección y el personal nocturno protegieron la vida. Los bomberos y el barco 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 de producto actual distingue más claramente la copia de seguridad local de la distante y el despliegue en zona única del 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 tras el incendio están instalados, mantenidos y ejercitados en los centros pertinentes; que el lenguaje del producto se corresponde con dominios de fallo reales; y que la recuperación gestionada 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 de negocio.

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 limitada: 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 en cuanto a jurisdicción como a peligro; y la palabra «copia de seguridad» estará respaldada por la única evidencia que en última instancia importa: una restauración exitosa en las condiciones para las que se compró la copia.