Backup en la nube: lo que el caso de AWS le enseña a tu negocio
Si el sistema de tu empresa desapareciera mañana, ¿sabrías decir en cuánto tiempo vuelves a vender? La mayoría de los dueños de negocio que conozco responde con un "ah, pero está todo en la nube". Y ahí está el peligro. El backup en la nube solo protege de verdad cuando alguien lo pensó a propósito.
Esta semana llegó un recordatorio bien directo de eso. AWS, el mayor proveedor de nube del mundo, admitió que no puede restaurar parte de los datos guardados en instalaciones de Oriente Medio alcanzadas por ataques de Irán. Así es: la empresa que es sinónimo de "nube confiable" dijo, con todas las letras, que tiene datos que ya no van a volver.
Probablemente no tienes un servidor en Dubái. Pero la lección vale para cualquier empresa que funcione sobre sistemas online. O sea, casi todas.
Qué le pasó a AWS, en lenguaje simple
La nube no es una nube. Es un edificio. Un edificio lleno de computadoras, con energía, aire acondicionado, cables y gente trabajando. Cuando ese edificio recibe un misil, un incendio o una inundación, los datos que están ahí quedan en riesgo.
AWS organiza sus edificios en "regiones". Cada región tiene algunos centros de datos separados físicamente, justamente para que un problema en un lugar no tumbe todo. En la mayoría de los casos, esto funciona muy bien.
El punto es que esa protección tiene un límite. Si el cliente guardó los datos en una sola región, y toda esa región se vio afectada, no hay magia. El proveedor puede ser excelente y aun así no tener de dónde sacar la copia.
Y aquí viene la parte que poca gente lee en el contrato.
¿De qué se hace cargo la nube, exactamente?
Todo gran proveedor trabaja con lo que llaman "responsabilidad compartida". Traducido: ellos cuidan la infraestructura y tú cuidas tus datos.
En la práctica, queda más o menos así:
- El proveedor garantiza que el edificio tiene energía, que los servidores funcionan y que nadie entra sin autorización.
- Tú garantizas que existe una copia de tus datos en otro lugar, que las contraseñas están seguras y que alguien sabe restaurar todo si algo sale mal.
Cuando contratas un SaaS, como un CRM, un ERP o una plataforma de e-commerce, la lógica es parecida. La empresa del software cuida el sistema. Pero si un empleado borra 3 mil clientes sin querer, o si el proveedor quiebra, la pregunta "¿dónde están mis datos?" va a ser tuya.
Ya vi a una empresa pequeña descubrir que el sistema de agendamiento que usaba hace 4 años solo guardaba backup de los últimos 7 días. Un error de importación pasó desapercibido durante dos semanas. Cuando lo notaron, la copia buena ya se había sobrescrito.
Cómo hacer un backup en la nube que funcione de verdad
No hace falta volverse experto en infraestructura. Hace falta método. La regla más conocida del sector es la 3-2-1, y es lo bastante simple para caber en una servilleta:
- 3 copias de los datos importantes (la original y dos más).
- 2 tipos distintos de almacenamiento (por ejemplo, el propio sistema y un servicio de almacenamiento aparte).
- 1 copia fuera del lugar principal, en otra región, otro proveedor u otro país.
El caso de AWS es exactamente la falla del "1". Quien tenía todo en una sola región se quedó sin nada.
Para una empresa pequeña o mediana, esto puede ser muy concreto. Imagina una clínica que usa un sistema online de historias clínicas. Un plan razonable sería:
- El sistema principal, donde el equipo trabaja día a día.
- Una exportación automática, cada noche, a un almacenamiento en otro proveedor.
- Una copia semanal guardada en otra región geográfica, con acceso restringido a una o dos personas.
Nada de esto exige un equipo de TI a tiempo completo. Con una automatización bien hecha, corre sola y avisa por WhatsApp o por correo si alguna copia falla.
¿Cuánto tiempo aguanta tu empresa parada?
Antes de elegir una herramienta, conviene responder dos preguntas. Tienen nombre técnico, pero la idea es muy práctica.
¿Cuántos datos aceptas perder? Si el backup corre una vez al día y el problema ocurre a las 17 h, pierdes el trabajo de todo el día. Para una tienda online con 200 pedidos diarios, eso puede ser un desastre. Para una oficina que actualiza una planilla por semana, quizá no cambie nada.
¿Cuánto tiempo aguantas fuera de servicio? ¿Una hora? ¿Un día? ¿Una semana? Cada respuesta cambia el costo de la solución. Volver en minutos cuesta caro. Volver en dos días cuesta mucho menos.
No existe una respuesta correcta universal. Existe la respuesta correcta para tu caja. El error es no haberse hecho nunca la pregunta y descubrir la respuesta en el peor día posible.
Una cuenta rápida ayuda a decidir. Toma la facturación promedio de un día y multiplícala por la cantidad de días que estarías parado. Si tu empresa factura R$ 8 mil por día y estaría 5 días sin sistema, hay R$ 40 mil en juego. Sin contar el cliente que se fue y no vuelve. Al lado de eso, pagar unas decenas de reales al mes en almacenamiento extra parece barato.
El backup que nadie probó
Aquí va mi opinión más fuerte sobre el tema: la mayoría de las empresas que cree tener backup, en realidad, tiene un archivo. Y un archivo no es lo mismo que un plan de recuperación.
Un backup que nunca se restauró no es un backup. Es fe.
Ya vi de todo. Backup que guardaba la carpeta equivocada desde hacía meses. Archivo comprimido con una contraseña que nadie recordaba. Exportación que solo traía los nombres de los clientes, sin teléfono y sin historial. En todos esos casos, la empresa "tenía backup". Hasta que lo necesitó.
La prueba no tiene que ser complicada. Una vez por trimestre, alguien del equipo toma una copia e intenta restaurarla en un entorno separado. ¿Se puede abrir? ¿Los datos están completos? ¿Cuánto tiempo llevó? Anota todo. Si salió mal, genial: lo descubriste en un día tranquilo y no en un lunes de caos.
Es como un extintor. No sirve de nada tener uno colgado en la pared si nadie revisó nunca la fecha de vencimiento. (Y si vas a revisar el extintor de la oficina después de leer esto, no te juzgo).
Un checklist de 15 minutos para hoy
Si quieres salir de este texto con algo práctico, sepárate un rato y responde:
- ¿Cuáles son los 3 sistemas sin los que la empresa se detiene? (Normalmente: ventas, finanzas y atención al cliente).
- ¿Dónde están los datos de cada uno? ¿En qué proveedor y en qué región?
- ¿Existe una copia fuera de ese lugar? ¿Con qué frecuencia se hace?
- ¿Quién en la empresa sabe restaurar esa copia? ¿Esa persona todavía trabaja ahí?
- ¿Cuándo fue la última vez que alguien lo probó?
Si alguna respuesta es "no sé", ya vale la pena la conversación. No por pánico. Por gestión.
El caso de AWS es extremo, claro. La guerra no es el riesgo diario de la mayoría de las empresas brasileñas. Pero la lógica es la misma para una inundación, un ataque de ransomware, un proveedor que cierra sus puertas o un pasante con demasiados permisos. El evento cambia, la pregunta sigue: si todo desaparece, ¿de dónde lo recuperas?
Yo trabajo justamente en ese punto intermedio. Tomo los sistemas que la empresa ya usa y armo las automatizaciones que hacen la copia, la verifican y avisan cuando algo se sale de lo esperado, sin necesitar un equipo de TI entero para eso. Si quieres entender cómo quedaría esto en tu negocio, ven a conocer un poco más de mi trabajo.
Resumen para LinkedIn
AWS admitió que tiene datos de clientes que ya no van a volver. La nube más grande del mundo tuvo edificios alcanzados por ataques en Oriente Medio. Quien guardó todo en una sola región se quedó sin un lugar de donde sacar la copia. La lección sirve para cualquier empresa: la nube se ocupa de la infraestructura, pero tus datos son responsabilidad tuya. Regla 3-2-1: 3 copias, 2 tipos de almacenamiento, 1 fuera del lugar principal. Y un backup que nunca se restauró no es un backup. Es fe. Si todo desapareciera mañana, ¿sabes de dónde lo recuperarías? Si no lo sabes, vale la pena que hablemos. #Backup #ComputacionEnLaNube #SeguridadDeLaInformacion #GestionDeRiesgos #Automatizacion