Hay una conversación incómoda que se repite en muchas empresas colombianas. El gerente pregunta: "¿Tenemos respaldos?" El técnico responde: "Sí, hay un backup configurado." Nadie pregunta la única pregunta que importa: "¿Alguien ha comprobado que se puede restaurar?" Casi siempre la respuesta es no. Y un backup que nunca se restauró es solo una carpeta con archivos que quizás sirvan, quizás no.
Por qué el backup configurado no basta
Que una tarea de respaldo se ejecute sin errores no significa que los datos sirvan. Un backup puede estar corriendo durante meses y aun así ser inútil por varias razones:
- Está incompleto. Respalda una carpeta pero no la base de datos, o al revés, y nadie lo notó.
- Está corrupto. El archivo se genera pero al abrirlo está truncado o dañado.
- Está en el lugar equivocado. Vive en el mismo servidor o en la misma red que los datos originales, así que un ransomware o un incendio se los lleva a los dos.
- Es demasiado viejo. La última copia buena es de hace semanas porque el proceso lleva tiempo fallando sin alertas.
- No tiene las credenciales. El respaldo existe pero nadie sabe con qué usuario restaurarlo ni dónde están las llaves.
- Nadie documentó cómo restaurar. Cuando ocurre el desastre, la persona que sabía ya no está.
Un backup sin prueba de restauración no es respaldo, es una esperanza. Y la esperanza no es una estrategia de continuidad.
La regla 3-2-1-1-0
Existe una guía clásica que resume una buena estrategia. Merece la pena entenderla:
- 3 copias de los datos (la original y al menos dos respaldos).
- 2 medios o tecnologías distintas (por ejemplo, un disco local y almacenamiento en la nube, no dos discos del mismo fabricante en la misma caja).
- 1 copia fuera de sitio (en otra ubicación física o en la nube, para sobrevivir a un robo, incendio o inundación).
- 1 copia desconectada o inmutable (que no sea accesible desde la red ni modificable, para protegerse del ransomware).
- 0 errores tras verificar. Es decir, la restauración debe probarse y dar cero fallos.
Ese último cero es justamente el que casi todos descuidan. Los cuatro primeros puntos se resuelven comprando almacenamiento; el quinto exige trabajo y disciplina.
RTO y RPO: las dos preguntas de negocio
Antes de hablar de tecnología, defina con las áreas de negocio:
- RTO (Recovery Time Objective): ¿cuánto tiempo puede estar su empresa sin ese sistema? Una hora, un día, dos días. Eso determina la infraestructura de recuperación.
- RPO (Recovery Point Objective): ¿cuánta información puede permitirse perder? Si respalda una vez al día, puede perder hasta 24 horas de trabajo. Si eso es inaceptable, necesita respaldo más frecuente o replicación.
Sin esas dos cifras, la estrategia de respaldo se diseña a ciegas. Y respaldar "todo cada hora" para datos que no cambian es tan mala idea como respaldar una base de datos transaccional una vez al día.
Cómo probar un respaldo de verdad
Aquí está lo que recomendamos hacer al menos una vez al trimestre. No es teoría: es la prueba que separa un respaldo real de una carpeta decorativa.
- Elija un sistema crítico. Empiece por el que más le dolería perder: facturación, correo, control de producción.
- Restaure en un ambiente separado. Nunca sobre el sistema de producción en una prueba. Monte una máquina o servidor aparte.
- Use el procedimiento documentado. Si no existe, el primer hallazgo es que no hay procedimiento. Ese es el problema a corregir.
- Mida el tiempo real. Cuánto tardó de principio a fin. Compárelo con el RTO que definió el negocio.
- Verifique la integridad de los datos. No basta con que el sistema arranque; confirme que la información está completa y consistente.
- Documente el resultado. Fecha, sistema, quién lo hizo, tiempo, incidencias y acciones correctivas.
- Corrija y repita. Toda prueba revela algo. Lo que no se corrige se convierte en el fallo del próximo incidente.
- Respaldo automático funcionando y con alerta si falla.
- Copias en al menos dos medios distintos.
- Al menos una copia fuera de sitio.
- Al menos una copia desconectada o inmutable.
- Credenciales de restauración documentadas y accesibles a más de una persona.
- Cifrado de las copias, especialmente si salen de su infraestructura.
- Prueba de restauración realizada en los últimos 90 días.
- RTO y RPO definidos con las áreas de negocio, no solo por TI.
El caso del ransomware
El ransomware cambió las reglas. Antes, el enemigo era el disco que fallaba; hoy es un software que cifra sus datos y también intenta cifrar los respaldos. Si su copia está montada en la misma red y es accesible con las credenciales del servidor comprometido, el atacante la va a cifrar también. Por eso la copia inmutable o desconectada dejó de ser un lujo y se volvió obligatoria para cualquier empresa que no quiera pagar rescate. La pregunta no es si su empresa es "suficientemente grande" para ser atacada, sino si sus respaldos sobrevivirían a un ataque que ya está dentro.
Qué exigirle a un proveedor de respaldo
- Que diseñe la estrategia a partir de RTO y RPO, no de un paquete genérico.
- Que monitoree los respaldos y avise cuando fallen, no solo cuando alguien pregunte.
- Que documente y ejecute pruebas de restauración periódicas, con evidencia.
- Que explique dónde quedan las copias y quién tiene acceso.
- Que entregue las credenciales y la documentación a su empresa, no que las retenga.
Empiece esta semana
No necesita un proyecto de meses para mejorar. Haga esto: identifique su sistema más crítico, intente restaurarlo en un ambiente de prueba y cronometre cuánto tarda. Con ese solo ejercicio va a descubrir si su respaldo sirve o no. Si no sirve, mejor saberlo un martes tranquilo que un domingo de madrugada con la operación caída.
Si quiere acompañamiento para diseñar una estrategia de respaldo y continuidad acorde con su operación, escríbanos. También puede ver nuestro servicio de cloud e infraestructura, donde el respaldo es una pieza central.