Recuperación ante desastres

Incendio en OVHcloud: cuando la copia y el servidor arden juntos

En marzo de 2021 un incendio destruyó un centro de datos en Estrasburgo. Las empresas con un plan para arrancar en otro lugar siguieron adelante. Otras descubrieron que su copia ardía en el mismo edificio que su servidor.

10 mar 2021fecha del incendio
SBG2edificio destruido por completo
≈ 255.000 €indemnizaciones en dos sentencias
Mismo edificiodonde estaban algunas copias

Qué pasó

En la madrugada del 10 de marzo de 2021 se declaró un incendio en SBG2, uno de los edificios del campus de centros de datos que OVHcloud, uno de los mayores proveedores de alojamiento de Europa, tiene en Estrasburgo. La empresa aisló todo el campus. SBG2 quedó destruido y SBG1 sufrió daños parciales.

Esa misma mañana, OVHcloud pidió a los clientes con servidores en Estrasburgo que activaran su plan de recuperación ante desastres. Ahí se vio la diferencia. Quien tenía copia en otro lugar y un procedimiento para arrancar en otro sitio pudo seguir trabajando. Muchos clientes no tenían copias y no pudieron recuperar sus aplicaciones.

La pregunta claveSi mañana arde el edificio donde está tu servidor, ¿dónde está tu copia? Si no sabes contestar con una dirección física distinta, tienes el mismo riesgo.

Cronología

  1. 10 de marzo de 2021, madrugadaEl fuego se declara en SBG2. Los bomberos lo controlan en las primeras horas del día.
  2. 10 de marzo de 2021OVHcloud aísla el campus completo (SBG1 a SBG4) y recomienda a sus clientes activar su plan de recuperación.
  3. Días siguientesEl fundador de la compañía anuncia que las copias de seguridad pasarán a incluirse por defecto y sin coste adicional en todos sus centros de datos.
  4. 2023Un tribunal mercantil de Lille condena a OVHcloud a indemnizar a dos clientes que perdieron sus copias. La empresa anunció que recurriría.

Por qué se perdieron datos

Los dos casos que llegaron a los tribunales muestran el mismo error de fondo: la copia y el original compartían edificio.

Bati Courtage

Esta correduría creía que su copia estaba en un edificio distinto al de su servidor virtual. Ambos estaban en SBG2, así que no quedó nada que recuperar. Reclamó más de 6,5 millones de euros. El tribunal valoró que el contrato describía la copia como aislada físicamente de la infraestructura del servidor, y eso no se cumplía. Fijó una indemnización de unos 101.000 euros.

Bluepad

Esta empresa de software tenía, según su versión, la producción en SBG1 y las copias en SBG2. Además, al reiniciar el servidor de copias tras el incendio, unos scripts de limpieza borraron los datos que quedaban. Reclamó unos 330.000 euros. El tribunal le reconoció cerca de 154.000.

En ambos casos, la indemnización fue una fracción de lo reclamado. Y ninguna sentencia devuelve los datos.

Qué habría cambiado con un buen plan

La regla 3-2-1-1-0 existe precisamente para este escenario:

  • 3 copias de los datos: si una se pierde, quedan dos.
  • 2 soportes distintos: un fallo del mismo tipo no se lleva todo.
  • 1 copia fuera, en otra ubicación física. Mejor aún, en otro proveedor o región.
  • 1 copia inmutable o desconectada, que nadie pueda borrar, ni siquiera un script por error.
  • 0 errores en las restauraciones de prueba.

Con una copia en otra región y un procedimiento de arranque documentado, el incendio habría sido un mal día, no la pérdida de la empresa.

Lecciones para tu empresa

  1. Pregunta dónde está físicamente cada copia y pídelo por escrito. "En la nube" no es una ubicación.
  2. Al menos una copia en otro proveedor o en otra región. Un mismo proveedor puede compartir riesgos que no ves.
  3. No te fíes solo del contrato. Que diga "aislada" no garantiza que lo esté. Compruébalo.
  4. Ten un plan de recuperación listo para activar. Cuando el proveedor te dice "activa tu plan", ya debería existir.
  5. Una indemnización no recupera tus datos. Diseña para no tener que reclamar.