Copias de seguridad en la nube: lo que AWS no puede restaurar

Imagina abrir el panel de tu sistema un lunes y leer este aviso de tu proveedor: parte de tus datos no se puede restaurar. No "va a tardar". No "estamos trabajando en ello". Simplemente no vuelve. Eso fue más o menos lo que AWS comunicó a sus clientes después de que instalaciones en Oriente Medio fueran alcanzadas por ataques iraníes, según el Wall Street Journal. Es el tipo de noticia que hace que todos los que dependen de la nube se detengan un segundo y piensen: ¿y si me pasara a mí? La respuesta depende por completo de cómo esté montado hoy tu backup en la nube.

Voy a ser directo: la mayoría de las empresas que atiendo no tiene backup. Tiene la sensación de backup. Son cosas distintas.

"Pero está en la nube, ¿no es seguro?"

Esa es la confusión más cara que existe hoy en tecnología.

La nube resuelve muy bien un problema específico: te quita la responsabilidad de comprar servidores, cambiar discos quemados y pagar la factura del aire acondicionado de la sala técnica. No te quita la responsabilidad sobre tus datos. Todo gran proveedor lo tiene escrito en el contrato, en lo que llaman modelo de responsabilidad compartida. Ellos cuidan la infraestructura. Tú cuidas lo que pones dentro de ella.

Traducido al idioma de un dueño de empresa: si un centro de datos se vuelve polvo, el proveedor devuelve el servicio. Tus archivos, solo si antes ordenaste copiarlos a otro lugar.

Y hay un detalle técnico que engaña a mucha gente. Cuando contratas un servicio en la nube, eliges una "región", tipo São Paulo o Norte de Virginia. Dentro de una región existen zonas de disponibilidad, que son edificios diferentes. La mayoría de los sistemas está configurada para sobrevivir a la caída de un edificio. Casi ninguno está configurado para sobrevivir a la pérdida de una región entera. Y es exactamente ese escenario, el regional, el que aparece en guerras, desastres naturales, incendios grandes o bloqueos judiciales.

Esto no es una hipótesis, ya pasó varias veces

La guerra parece lejana. Entonces vamos con ejemplos más domésticos.

En marzo de 2021, OVH, la mayor proveedora de nube de Europa, tuvo un centro de datos en Estrasburgo destruido por un incendio. El edificio entero. Miles de clientes perdieron datos de forma definitiva. Muchos descubrieron ese día que el "backup" que pagaban estaba en el mismo campus que se incendió. Hubo empresas que cerraron.

En 2014, Code Spaces, que alojaba código para otras empresas, sufrió un ataque. El intruso entró en el panel de administración de AWS y borró los datos junto con los backups, porque backup y producción estaban en la misma cuenta, con las mismas credenciales. La empresa anunció el cierre de sus operaciones en menos de 24 horas.

En 2023, un proveedor surcoreano perdió datos de clientes cuando un ransomware cifró producción y backups conectados. El patrón se repite: el backup existía, pero estaba al alcance del mismo problema.

Un backup que muere junto con el original nunca fue un backup. Era solo una segunda copia del riesgo.

Lo que realmente necesitas tener fuera de la nube de tu proveedor

Existe una regla antigua de TI, la 3-2-1, y envejeció muy bien. Tres copias de los datos, en dos tipos de medio o plataformas distintas, y una de ellas fuera del sitio principal.

Para un negocio pequeño o mediano que funciona con SaaS, yo la adapto así:

• Una copia fuera del proveedor principal. Si tu sistema corre en AWS, la copia de seguridad no puede estar solo en AWS. Puede ir a Google Cloud, a un almacenamiento barato tipo Backblaze, o incluso a un NAS en la oficina.
• Una copia que el sistema de producción no pueda borrar. Credencial aparte, cuenta aparte, de preferencia con bloqueo de eliminación por un período (inmutabilidad). Eso es lo que te salva del ransomware y del empleado enojado.
• Una copia en un formato que puedas leer sin el proveedor. CSV, JSON, PDF, SQL. Si el backup de tu CRM solo se abre dentro del propio CRM, y el CRM desapareció, tienes un archivo bonito e inútil.

Ese tercer punto es el más olvidado y el más importante en SaaS. No estás solo en la nube de infraestructura. Estás en tu ERP, en tu CRM, en RD Station, en Notion, en ClickUp, en WhatsApp Business. Cada uno de ellos guarda pedazos de tu negocio. Cada uno puede bloquearte por sospecha de fraude con la tarjeta, cancelar un plan, o simplemente romperse.

La prueba que casi nadie hace

Aquí va la pregunta que hago en toda primera reunión y que casi siempre traba la conversación: ¿cuándo fue la última vez que restauraste un backup?

No que lo "generaste". No que "revisaste si el archivo existe". Que lo restauraste de verdad, lo abriste, miraste los datos y confirmaste que estaba todo ahí.

Un backup sin probar es una creencia religiosa. Ya me encontré con una rutina de exportación que llevaba ocho meses generando un archivo de 0 KB, porque la clave de la API había caducado y nadie leía el correo de error. También me encontré con un dump de base de datos perfecto, completo, íntegro, pero al que le faltaba la carpeta de adjuntos: todos los contratos firmados en PDF, todas las fotos de productos, nada de eso estaba en el backup. La base tenía la ruta de los archivos. Los archivos, no.

Haz esto una vez por trimestre. Toma el backup más reciente, restáuralo en un entorno separado, e intenta responder tres preguntas simples:

1. ¿Están los datos de los últimos siete días?
2. ¿Se abren los adjuntos y las imágenes?
3. ¿Cuánto tiempo llevó esto, desde cero hasta funcionando?

Esa tercera respuesta es tu tiempo real de recuperación. Si son ocho horas y tu negocio no aguanta dos, no tienes un problema de backup, tienes un problema de arquitectura, y es mejor descubrirlo en una prueba que en una crisis.

Cuánto tiempo y cuántos datos aguantas perder

Dos preguntas resuelven el 90% de la planificación, y ninguna de las dos es técnica.

¿Cuánto tiempo aguanta el negocio parado? ¿Una hora? ¿Un día? ¿Una semana? Una tienda online parada un día pierde ventas y se recupera. Una clínica sin historias clínicas durante un día cancela toda la agenda y daña su reputación.

¿Cuántos datos aguanta perder el negocio? Si el backup corre cada madrugada y el problema ocurre a las 17h, pierdes el día entero de trabajo. Cada pedido, cada llamada registrada, cada atención. Para algunos negocios eso es aceptable. Para otros es inaceptable, y ahí el backup tiene que ser continuo.

Responde esas dos con un número y el resto es ejecución. Sin ellas, cualquier solución que alguien te venda es una corazonada con factura.

Y sí, hay un costo. Pero mucho menor de lo que la gente imagina. Guardar 500 GB en almacenamiento frío en una segunda nube cuesta entre 2 y 5 dólares al mes. La automatización que copia eso cada día, lo prueba y te avisa cuando falla, es trabajo de configuración, no una suscripción eterna. Compáralo con el valor de una semana parada y la cuenta se cierra sola.

Qué hacer esta semana

No necesitas un proyecto de seis meses. Necesitas una tarde.

Lista todos los sistemas donde tu negocio guarda algo que importa. Sistema de gestión, finanzas, CRM, correos, archivos, sitio web. Para cada uno, escribe tres cosas: dónde están los datos, si existe exportación automática, y quién tiene acceso a esa exportación. Solo armar esa tabla ya suele revelar dos o tres agujeros que nadie sabía que existían.

Después de eso, elige el sistema más crítico y configura una exportación diaria hacia un lugar distinto del proveedor original. Solo uno. Empieza por lo que más dolería perder.

La noticia de AWS es dramática porque involucra misiles, pero el aprendizaje es banal y sirve para quien nunca va a acercarse a una zona de conflicto. Toda dependencia que no puedes sustituir es una apuesta a que nada va a salir mal. Y sale mal, tarde o temprano, casi siempre un viernes por la tarde.

Si quieres una segunda opinión sobre dónde están los agujeros de tu setup, cuéntame cómo funciona hoy. En general se resuelve con automatización simple, y sin cambiar nada de lo que ya usas.

AWS avisó a sus clientes que parte de los datos simplemente no vuelve. No "va a tardar". No vuelve.

La mayoría de las empresas que atiendo no tiene backup. Tiene la sensación de backup.

La nube cuida la infraestructura. Tus datos siguen siendo responsabilidad tuya, está en el contrato.

Y la pregunta que casi siempre traba la reunión: ¿cuándo fue la última vez que restauraste un backup de verdad? No que lo generaste. Que lo restauraste, lo abriste y lo revisaste.

Ya me encontré con una rutina que llevaba ocho meses generando un archivo de 0 KB, porque la clave de la API había caducado y nadie leía el correo de error.

Un backup que muere junto con el original nunca fue un backup. Era solo una segunda copia del riesgo.

Si quieres, cuéntame cómo está tu setup hoy. En general se resuelve con automatización simple, sin cambiar nada de lo que ya usas.

#backup #cloudcomputing #gestionderiesgos #tecnologia #pymes