Esta semana Amazon confirmó algo que lleva meses gestándose: no puede restaurar los datos de algunos clientes que estaban guardados en sus data centers de Emiratos Árabes Unidos y Bahréin, que quedaron fuera de combate tras los ataques con drones iraníes a comienzos de la guerra. No es un outage de dos horas ni un S3 que se cae y vuelve. Es data que probablemente se fue para siempre, y la empresa más grande del mundo en cloud no tiene forma de traerla de vuelta.
El detalle incómodo: estaba solo en un lugar
La parte que más me llama la atención no es la guerra, sino la geometría del problema. Los datos perdidos estaban alojados exclusivamente en esas instalaciones del Golfo Pérsico. O sea: alguien decidió que su información crítica viviera en una sola región geográfica, en un solo proveedor, probablemente confiando en el marketing de «replicación automática». La replicación automática replica dentro de la región que le digas. Si le dices una, tienes una copia y un punto de falla del tamaño de un país entero.
Y ojo, no es soberbia: cuando tienes data centers golpeados por drones militares, ya estás en territorio donde ninguna arquitectura normal estaba diseñada para sobrevivir. Pero justamente por eso sirve como test de estrés mental. Si tu plan de contingencia no contempla «la región completa desaparece», tu plan es una esperanza, no un plan.
La regla 3-2-1 no es un meme de Twitter
Cualquiera que haya administrado servidores en serio conoce la regla 3-2-1: tres copias de los datos, en dos medios distintos, una fuera del lugar. Suena a sermón de abuelo, pero cada cierto tiempo la realidad cobra las deudas. Yo mismo tengo mi propio ritual: mis servidores se respaldan diariamente a un Google Drive externo, con script y cron, y de vez en cuando hago la prueba poco sexy de restaurar algo. Porque un backup que nunca se restauró no es un backup, es una suposición con buena pinta.
El punto clave de este caso es la diferencia entre redundancia y resiliencia. AWS tenía redundancia: discos, nodos, zonas de disponibilidad. Lo que no tenía era copia del todo fuera del alcance del desastre. Cuando el desastre es físico y geopolítico, el RAID no sirve de nada.
«La nube es el computador de otro» sigue siendo verdad
Años de marketing lograron que mucha gente crea que subir algo a AWS es lo mismo que ponerlo a buen recaudo. No lo es. La nube te resuelve Operational Excellence: discos que fallan, servidores que se mueren, parches. Pero no te resuelve la responsabilidad de tus datos. Si el único lugar donde existía tu información era un bucket en Bahréin, el problema no fue el dron: fue la decisión de arquitectura tomada meses antes.
Mi conclusión después de ver este caso es simple y la aplico a todo lo que administro: exporta siempre. Deja tus datos en formatos que puedas leer fuera del proveedor, guarda copias en un lugar que esté a un continente de distancia, y hazte la pregunta que nadie quiere hacerse: si mañana este proveedor me dice «lo sentimos, no hay restauración posible», ¿qué pierdo exactamente? Si la respuesta es «todo», ya sabes qué hacer este fin de semana.
Los que perdimos datos alguna vez —un disco que murió, un rm mal ejecutado, da igual— salimos de ahí con una religión nueva. Este caso es la versión de la religión a escala industrial: hasta el proveedor más grande del planeta te va a decir que no, a veces no hay forma de volver atrás.
Fuente de inspiración: AWS Says It Can’t Restore Some Data From Mideast Facilities Struck by Iran
