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

Resumen

• Las alarmas de incendio se activaron en el centro de Estrasburgo de OVHcloud 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 consumidas por el incendio inicial, pero los servicios quedaron indisponibles porque fue necesario aislar la electricidad, inspeccionar la seguridad, limpiar y reiniciar por fases. No hubo víctimas mortales 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 UPS y sus baterías de plomo asociadas. Sí estableció factores de propagación y respuesta: ningún sistema automático de extinción en ninguno de los cinco edificios de Estrasburgo, rápido movimiento del humo a través del diseño abierto orientado a la refrigeración de SBG2, capacidad limitada de agua contra incendios y un difícil corte eléctrico general del 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 gran capacidad limitaron consecuencias peores.
• La pérdida de disponibilidad y la pérdida permanente de datos fueron resultados diferentes. OVHcloud informó de unos 65 000 clientes y 120 000 servicios afectados, mientras que Netcraft observó que aproximadamente 3,6 millones de sitios web en 464 000 dominios quedaron fuera de línea. OVHcloud afirmó que muchos clientes que perdieron datos no habían contratado una copia de seguridad opcional. Esto no cierra la cuestión de la responsabilidad: el propio documento de registro de OVHcloud indicaba que las copias de seguridad ofrecidas podían almacenarse en el mismo centro de datos o en otro 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 puso de manifiesto un error de concepto en la contratación de servicios en la nube. Soberanía de los datos, jurisdicción legal, latencia, disponibilidad, copia de seguridad y recuperación ante desastres están relacionados pero no son intercambiables. Mantener los datos en Francia o en la Unión Europea puede satisfacer una política de localización, pero aun así permitir que las copias de producción y recuperación compartan un mismo riesgo físico. A la inversa, 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, como una extinción automática más amplia, una mejor compartimentación, salas de energía independientes, cortes eléctricos remotos, auditorías in situ, colaboración con los bomberos y nuevas opciones multi-zona y de copia de seguridad distante. No obstante, para cerrar el ciclo de responsabilidad se requiere evidencia específica sobre los servicios y los centros: cobertura completa de los controles, inspección independiente, simulacros realistas de incendio y aislamiento eléctrico, ubicaciones declaradas de las copias de seguridad, pruebas de restauración exitosas y demostración 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 expresión "datos en la nube" fomenta una abstracción. Resulta útil cuando los ingenieros desean una interfaz estándar para la capacidad de cómputo, pero peligrosa cuando los responsables de decisiones comienzan a tratar la ubicación, la energía y el fuego como detalles ajenos. Cada servidor virtual reside en una sala. Cada réplica de almacenamiento ocupa equipos conectados a sistemas eléctricos y de refrigeración. Cada flujo 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 la madrugada del 10 de marzo de 2021, el fuego destruyó SBG2, uno de los edificios del campus de OVHcloud en el Port du Rhin. SBG1 quedó parcialmente destruido. Los otros dos centros de datos del sitio fueron apagados, aunque la primera actualización de la empresa los describió como no dañados. Por lo tanto, la pérdida se propagó a través de al menos tres mecanismos distintos: equipos destruidos físicamente; equipos en edificios adyacentes expuestos al calor, humo, agua o incertidumbre; y equipos sanos que quedaron indisponibles cuando fue necesario aislar eléctricamente el sitio y asegurarlo.

Estos mecanismos importan porque corresponden a diferentes controles. La extinció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 multisitio puede continuar mientras un sitio no está disponible. Una copia de seguridad remota y verificada puede respaldar la reconstrucción después de que los datos se destruyan. 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 soportar.

La reconstrucción pública más autorizada es elinforme de investigación de mayo de 2022de la Oficina Francesa de Investigación y Análisis de Riesgos Industriales (BEA-RI). Su mandato era la prevención, no la asignación de responsabilidad civil o penal. Esa distinción es importante. El informe puede establecer observaciones, posibles causas, factores contribuyentes y recomendaciones de seguridad. No puede convertirse en un fallo judicial que determine 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 nocturno en un equipo se convirtiera en una interrupción de varios 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 la carga de trabajo, la arquitectura, muchas opciones de servicio y las copias independientes. Los reguladores y los organismos profesionales controlaban partes del marco mínimo. Ninguno de esos roles anula 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ó un humo negro denso. El edificio fue evacuado a las 00:39, se llamó al servicio de bomberos 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 el momento en que se declaró el incendio. Esta diferencia debe preservarse en lugar de forzar 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 público del incidente.

La energía de emergencia de SBG2 se cortó a la 01:13 y la de SBG1, SBG3 y SBG4 a la 01:28. Los equipos de 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. Hacia las 02:00, los bomberos informaron de la afectación generalizada de SBG2. El barco de bomberos de gran 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 alimentación ininterrumpida (SAI). 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. Esa mañana se había realizado mantenimiento en el SAI y más tarde se registraron niveles de humedad inusuales. Los investigadores enumeraron varias hipótesis, incluida la humedad, un mal funcionamiento relacionado con el mantenimiento o el funcionamiento fuera de las condiciones previstas. 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 afirman que un sistema de refrigeración con fugas o un SAI recién reparado "causaron" el incendio. Elregistro de accidentes ARIA francéses 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 debería decir que se conocen los primeros eventos eléctricos y la zona de origen; la razón por la que ocurrieron esos eventos no se resolvió en el informe BEA-RI publicado.

Esta distinción no impide el análisis de controles. Una organización debe estar preparada para un fallo del equipo sin saber qué componente fallará a continuación. La protección contra incendios se diseña en torno a esa incertidumbre. La cuestión responsable no es solo si OVH debería haber previsto una secuencia eléctrica en 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 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 función 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 BEA-RI reconoce esos controles. La rendición de cuentas debe conservar las barreras exitosas tan cuidadosamente como las fallidas, porque el diseño futuro depende de saber qué fue lo que realmente ganó tiempo.

La detección no fue acompañada de una extinción automática. La investigación reveló que ninguno de los cinco edificios del sitio contaba con un sistema automático de protección contra incendios. Las salas de baterías y SAI de SBG2 estaban monitorizadas, pero no había ningún sistema diseñado para extinguir, controlar o retrasar el fuego en su etapa más temprana. Un sistema de este tipo podría haber actuado antes del corte eléctrico total y sin exponer a los bomberos a equipos con 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 incendio.

El edificio ayudó entonces al humo y al calor a moverse. SBG2 utilizaba un diseño de refrigeración abierto, similar a una torre, muy permeable al aire exterior. En los quince minutos posteriores al evento inicial, los detectores por aspiración se activaron en todos los niveles. BEA-RI advirtió que la activación de los detectores indicaba humo, no necesariamente llamas, pero concluyó que la construcción permitió que el humo se extendiera rápidamente. En aproximadamente noventa minutos, SBG2 estaba generalmente afectado. El contraste con el adyacente SBG3 fue instructivo: paredes resistentes al fuego de 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 una fortaleza de los centros de datos, también dificultó el aislamiento de emergencia: el sitio combinaba alimentaciones de red, generadores y grandes sistemas de baterías. El servicio de bomberos no pudo aplicar grandes chorros de agua de forma segura hasta que esas fuentes fueron neutralizadas.

Esta es la paradoja de la resiliencia de infraestructura. La energía de respaldo preserva la informática durante un fallo normal del suministro eléctrico, pero se convierte en otra fuente de energía que gestionar durante un incendio. El flujo de aire abierto puede reducir el costo de refrigeración y mejorar la eficiencia operativa, pero puede debilitar la contención del humo y el calor. Los equipos densos y los servicios compartidos del sitio 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 de BEA-RIargumentó que la ausencia de extinción automática no incumplía ningún requisito reglamentario y que la guía de la industria 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 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 los sitios que carecían de ella es en sí misma evidencia de que el tratamiento del riesgo cambió.

Cuatro edificios no significaban cuatro resultados independientes

Desde el panel de control de un cliente, SBG1, SBG2, SBG3 y SBG4 podían parecer varias ubicaciones de infraestructura. Durante el incidente formaron un solo sitio de emergencia. SBG2 ardió. 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 a los cuatro, se controló el acceso, hubo que evaluar los sistemas compartidos y la infraestructura superviviente requirió limpieza, inspección, recableado y reinicio por fases.

Elregistro de actualizaciones contemporáneo de Estrasburgo de OVHcloudhace inusualmente visible el carácter físico de la recuperación. Los equipos retiraron, limpiaron, inspeccionaron, reinstalaron y reiniciaron equipos sala por sala, pasillo por pasillo, bastidor por bastidor y servidor por servidor. Los servidores contaminados con 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 empezó a funcionar el 18 de marzo. En la tarde del 19 de marzo, se detectó humo en una sala de baterías de SBG1 no conectada. OVH apagó SBG1 y SBG4 de nuevo por precaución y revisó el calendario de reinicio. El restablecimiento del servicio se reanudó el 22 de marzo. A finales de marzo, los servidores dedicados de SBG4 eran 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 indicó posteriormente 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 restauró completamente para los aproximadamente 65 000 clientes afectados, que utilizaban unos 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. 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 sitio también muestra por qué la palabra "centro de datos" puede ser demasiado específica para la planificación de desastres. Un dominio de fallo es cualquier cosa a lo 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 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 dejarlos todos indisponibles.

Cuantificar el impacto requiere más de una cifra

Lamedición externa de la interrupción realizada por Netcraftencontró alrededor de 3,6 millones de sitios web en 464 000 dominios distintos fuera de línea y más del 18 % de las direcciones IP atribuidas a OVH en su encuesta reciente sin responder durante el período medido. Esa es una visión a escala de Internet de la pérdida de accesibilidad. Captura subdominios alojados y acuerdos de alojamiento posteriores, razón por la cual supera con creces el número de clientes de OVH.

Los 65 000 clientes afectados y los 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 o cuántos conjuntos de datos fueron irrecuperables. Losreportajes contemporáneos de Reutersidentificaron portales gubernamentales, bancos, tiendas, sitios de noticias y otros servicios en línea entre los afectados. Esos ejemplos muestran la 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 horas. Un servicio gestionado con datos de recuperación en poder del proveedor podría volver cuando OVH restaurara su plataforma. Un cliente de servidor dedicado a la espera de inspección o reubicación física podría permanecer indisponible durante semanas. Un cliente cuyos únicos datos de producción y copias de seguridad fueron 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 inaccesibles, franjas de duración, restauraciones exitosas del proveedor, reconstrucciones iniciadas por el cliente y casos de pérdida de datos permanente. Debería identificar cuántos clientes no tenían copia de seguridad, una copia en el mismo edificio, una copia en el mismo sitio, una copia en una región diferente de OVH o una copia bajo control independiente. La evidencia pública no proporciona esa matriz completa.

Esta ausencia importa porque la corrección debe seguir al mecanismo de pérdida. Si los clientes no contrataron 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 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 vinculadas 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 rendición de cuentas precisa.

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

Eldocumento de registro de 2021 de OVHcloudindicaba que los servicios de copia de seguridad de datos eran servicios de pago opcionales para la mayoría de los clientes y que algunos experimentaron una pérdida de datos permanente. 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 gestionados por el proveedor, incluido el correo, solo se interrumpieron levemente y no perdieron datos porque OVH realizó copias de seguridad de los mismos.

Estas revelaciones desmienten dos historias simples. Es inexacto decir que OVH realizó copias de seguridad de todos los servicios y no logró conservar todas las copias. También es insuficiente decir que todos los clientes que perdieron datos no compraron copias 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 cuales 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 utilizarla para restaurar un servicio prioritario en un tiempo aceptado. Esa promesa contiene al menos seis propiedades:

1. Ámbito: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 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:los fallos físicos, lógicos, administrativos y del proveedor que no pueden destruir o alterar todas las copias 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 comprobada para obtener capacidad, transferir datos, reconstruir dependencias, conciliar transacciones y devolver una función empresarial a un estado aceptable.
6. Evidencia:monitoreo de que la copia de seguridad se completó, verificaciones de integridad, restauraciones de muestra, ejercicios de servicio completos 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 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 incumplir un objetivo empresarial de doce horas. Una copia de seguridad almacenada en el mismo dominio de energía e incendio puede ser perfectamente actual hasta el evento que se suponía que debía cubrir.

La autoridad francesa de protección de datos, CNIL, establece 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 sin conexión, 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 orientaciones posteriores, no una 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 da 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 consideró un incumplimiento contractual porque OVH no pudo dejar al cliente acceso a la copia de seguridad completada y conservarla para su recuperación. No estimó la pretensión separada del cliente de que OVH tuvo la culpa 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 ese litigio, rechazó la defensa de fuerza mayor de OVH, confirmó las limitaciones de responsabilidad aplicables y redujo la indemnización a 1.800,48 EUR.

Ese fallo es más limitado e instructivo que la sentencia de primera instancia ampliamente difundida. No establece que todos los contratos de copia de seguridad de OVH prometieran 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 copias de seguridad" cuando el cliente pagó al proveedor para que realizara 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 una 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 un fallo del servidor. Una sala separada puede estar aislada de un incendio en un bastidor. Un edificio separado puede sobrevivir a algunos eventos de 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 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 las obligaciones 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 una prueba central.

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

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

"Responsabilidad compartida" se utiliza a menudo como una forma educada de decir que ambas partes tenían trabajo que hacer. A menos que se especifique el trabajo, la frase distribuye la culpa después del fallo en lugar de asignar los controles antes del mismo. Estrasburgo apoya 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 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 emergencia de energía. Estos son controles del proveedor, incluso cuando los contratos de los clientes limitan los daños.

OVH también era responsable de la veracidad de sus productos. Solo el proveedor podía saber dónde terminaba una copia de seguridad automatizada, de qué servicios hacía copia de seguridad 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 tomara una decisión sobre el riesgo. Cuando OVH se encargaba del 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 contenía un sitio de prueba 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, conservar copias fuera del dominio de fallo principal y probar la reconstrucción. La compra de 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 desplaza con el modelo de servicio. En el metal desnudo no gestionado o la infraestructura como servicio, el cliente suele ser responsable de la copia de seguridad consistente a nivel de 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 responsabilidad sobre la copia, la retención, la consistencia y la ruta de restauración. Un revendedor del mercado 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 copia de seguridad de la ANSSI(Agencia Francesa de Ciberseguridad) convierten 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 adecuadamente protegida, pruebas de restauración periódicas, un orden de restauración y la protección de los medios de instalación y las configuraciones de las aplicaciones. Para la copia de seguridad externalizada, la 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. 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 localización responde a varias preguntas diferentes

La identidad europea de OVHcloud era importante en 2021 y lo sigue siendo. Para los gobiernos y las organizaciones reguladas que buscan una alternativa a los hiperescalares 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 los datos fuera irrelevante. 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 riesgo 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 dice "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 exige el almacenamiento en la UE permite una diversidad geográfica aún mayor, preservando al mismo tiempo un perímetro legal en la UE. Si eso es suficiente depende de la legislación, el modelo de amenazas, la sensibilidad de los datos y el objetivo de recuperación de la organización.

Laexplicación de la Comisión Europea sobre las transferencias internacionalestambié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, garantías y excepciones limitadas para las transferencias. No obstante, algunas organizaciones adoptan requisitos de localización más estrictos debido a la legislación sectorial, las políticas públicas, las promesas contractuales o la exposición a jurisdicciones extranjeras.

Laguía de calificació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, supervisión, copias de seguridad, directorios y datos técnicos, considerando al mismo tiempo el control corporativo y la exposición a legislación no europea. 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 en la UE, utilizar 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 ocultarse 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 de comunicación, juegos y servicios de cara al público porque muchas organizaciones seleccionaron a un solo proveedor o lo heredaron a través de un suministrador. Esto es concentración en la nube a nivel de mercado. También hubo concentración dentro de las aplicaciones individuales: producción, copias de seguridad, DNS, correo electrónico, gestión y herramientas de despliegue podían compartir OVH o Estrasburgo, aunque parecieran 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 contratación pueden evitar la 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 su cartera mientras que un sistema crítico aún no tiene 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 (ABE)exigen que las instituciones cubiertas regulen los riesgos de externalización y sigan siendo capaces de supervisar, en lugar de convertirse en cáscaras vacías. La posterior Ley de Resiliencia Operativa Digital de la UE, o DORA, exige que las entidades financieras cubiertas mantengan y prueben periódicamente los acuerdos 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 de aplicación definidos y no deben proyectarse retroactivamente a todos los clientes de OVH de 2021. Muestran la dirección de la práctica responsable: la externalización no externaliza la responsabilidad del órgano de gobierno en materia de 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, el fallo de servicios de terceros, el cambio a capacidad redundante y cortes de energía generalizados. Estrasburgo es exactamente el tipo de evento combinado, físico y de proveedor, que un simulacro 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 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 una reconstrucción ejercitada satisface la necesidad empresarial a un costo mucho menor.

La restauración debe demostrarse 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 estuvieran disponibles. El 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 que ocurrió después de la última copia utilizable.

Un ejercicio de recuperación maduro comienza con una pérdida supuesta, no con una exportación conveniente. El equipo debe simular que la región principal 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, crear 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 empresarial.

La evidencia debe responder a preguntas prácticas. ¿Cuál fue 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 capacidad total? ¿Quién aprobó el regreso y qué conciliación quedó pendiente?

La supervisión de copias de seguridad por sí sola no puede responder a estas preguntas. Un trabajo en 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 ofrecer su función prioritaria bajo el fallo supuesto. 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. Sí necesitan una vía de salida proporcionada. Una pequeña empresa puede exportar su base de datos y documentos críticos a un destino cifrado bajo una cuenta separada, conservar su dominio y credenciales de despliegue de forma independiente, documentar una reconstrucción limpia y probar una restauración de muestra. El control debe corresponderse con el costo de perder los registros, no con el precio mensual del servidor.

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

La respuesta de OVH a BEA-RI describió un importante programa "Hyper Resilience". La empresa 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 ciento veinte minutos y ubicaría las salas de energía y baterías fuera de los edificios del centro de datos para los nuevos sitios y, cuando fuera factible, en los existentes. Planeó cortes eléctricos remotos por zona para que los servicios de emergencia pudieran aislar el peligro sin desactivar innecesariamente las áreas no afectadas.

La respuesta también decía que los bomberos locales visitaron todos los centros de OVH en 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 depósito de agua privado de 120 metros cúbicos en colaboración con SIS67. Afirmó que todos los centros recibieron un análisis de riesgo de incendio y que la eficacia se mediría mediante un estudio de vulnerabilidad cuando finalizaran los trabajos. 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 extinción aborda el crecimiento inicial. Los compartimentos contra incendios más fuertes 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 los ejercicios de los 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 reglamentarias y de las aseguradoras. También registra una provisión continua para las consecuencias del incendio de Estrasburgo, incluidas las acciones de responsabilidad. Eso es evidencia de un programa duradero y de un tratamiento financiero, no de un certificado de finalización independiente centro por centro.

Un cierre responsable publicaría o proporcionaría a los clientes cualificados y a los auditores una matriz de controles: 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 con los bomberos se han realizado; qué hallazgos siguen pendientes; y qué parte independiente verificó el funcionamiento. Un compromiso político es el comienzo de la corrección. La cobertura y el ejercicio adversarial muestran si funciona.

La empresa también merece crédito por mantener un registro público detallado de actualizaciones 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 sean 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 sigue determinando 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 de Bati Courtage. Suguía de modos de desplieguedistingue entre 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 empresatambién dice que los clientes que buscan una mayor resiliencia deben seleccionar una región multi-zona 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 mero hecho de lanzar en una región de 3-AZ no garantiza que una máquina virtual, una base de datos o un volumen colocado manualmente abarque las zonas.

Ladocumentación actual de copias de seguridad de instanciasdistingue ahora las 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 preserva 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 relevante para la cuestión de responsabilidad actual: ¿ha aprendido el mercado a exponer la localización y la resiliencia por separado? OVHcloud lo hace ahora 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, configuraciones predeterminadas 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 costo puede tener razonablemente una copia de seguridad local predeterminada 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 la marca de copia de seguridad podrían requerir que el cliente confirme el dominio de fallo, mostrar una advertencia cuando todas las copias compartan un mismo sitio y ofrecer un destino remoto en la misma región legal. El objetivo es la aceptación informada del riesgo, no obligar a cada carga de trabajo a utilizar la arquitectura más cara.

La junta directiva necesita evidencia en dos planos de control

El incendio de Estrasburgo atravesó un plano de control de instalaciones y un plano de control de recuperación del cliente. La junta 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 con los bomberos, las excepciones de mantenimiento y los trabajos correctivos atrasados. Los simulacros deben suponer que los controles ordinarios fallan y que los bomberos necesitan una autoridad inmediata y precisa para aislar la energía.

Para la capa de servicio, la dirección debe saber cómo se representan y 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 mismo sitio o región; cuántos clientes han seleccionado protección distante; el éxito de la restauración 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 indiquen que los clientes no entendieron la ubicación.

La junta también debe recibir las excepciones, no solo los promedios. Una tasa de éxito del 99,99 % en los trabajos de copia de seguridad puede coexistir con miles de copias en un mismo dominio físico. Un porcentaje global de extinción puede ocultar un viejo edificio de alta densidad. Un tiempo medio de restauración puede ocultar los conjuntos de datos más grandes y de mayor consecuencia. La exposición a los extremos pertenece a la gobernanza porque Estrasburgo fue un evento extremo con impacto concentrado.

Un desafío independiente debe rastrear la promesa al cliente hasta el final. Seleccionar un servicio que se vende como con copia de seguridad. Registrar lo que dicen la interfaz y el contrato. Localizar cada copia y sus metadatos de control. Eliminar el centro principal del ejercicio. Denegar las rutas normales de identidad y soporte. Restaurar en un destino que satisfaga las reglas de localización del cliente. Comparar 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 deberían exigir antes de considerar un servicio como resiliente

Las organizaciones no necesitan acceso privado a todos los planos de los centros de datos. Sí 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, el snapshot 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 una compensación después de que se incumple 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 por 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 secundaria puede usar OVH por debajo. El DNS, el correo electrónico, el código fuente, los secretos y las comunicaciones de incidentes pueden compartir todas el mismo proveedor. La diversidad se mide por las rutas supervivientes, no por el número de facturas.

Por último, el cliente debe decidir cuánta pérdida es aceptable. Cero pérdida de datos y un tiempo de inactividad casi nulo ante desastres regionales requieren replicación continua, diseño de aplicaciones, capacidad y pruebas operativas que pueden ser costosas. Una copia semanal sin conexión 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 las consecuencias, la recuperación prometida, la arquitectura y la 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 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 vidas. Los bomberos y el barco bomba EUROPA limitaron la propagación. OVH llevó a cabo una recuperación difícil y transparente, aceptó las recomendaciones de BEA-RI en términos operativos y lanzó un amplio programa de resiliencia física. La documentación actual de sus productos distingue más claramente las copias de seguridad locales de las distantes y el despliegue en una sola zona del multi-zona. 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 relevantes; que el lenguaje del producto se corresponde con los 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 restaurarlos dentro del objetivo empresarial.

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 elecciones de localización serán explícitas tanto en cuanto a la jurisdicción como al 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.