“Tenemos backups” suena tranquilizador… hasta que ocurre un incidente. La pregunta incómoda es: ¿puedes restaurar la operación completa dentro del tiempo que el negocio tolera? Porque respaldar datos y recuperar servicios son dos cosas muy diferentes.
En la práctica, muchas organizaciones descubren que sus respaldos “existen”, pero:
- No están completos o están corruptos.
- No incluyen configuraciones críticas (red, identidades, apps).
- Tardan demasiado en restaurarse.
- Dependen de credenciales o sistemas que también están caídos.
- Se guardan en el mismo entorno que fue comprometido.
Respaldos no es lo mismo que recuperación
Un respaldo es una copia de información. La recuperación ante desastres (DRP) es un conjunto de procesos y decisiones para volver a operar: infraestructura, aplicaciones, accesos, seguridad, comunicaciones y validación final.
Piensa en esto: si pierdes tu sistema de facturación, ¿sirve tener la base de datos si no puedes levantar el servidor, la aplicación, los certificados, la conectividad y los permisos? Para el negocio, “recuperar datos” sin “recuperar el servicio” es casi lo mismo que no recuperar nada.
La conversación correcta: RTO y RPO
Dos métricas aterrizan la continuidad a una realidad tangible:
- RTO (Recovery Time Objective): cuánto tiempo máximo puedes estar caído.
- RPO (Recovery Point Objective): cuánta información máxima puedes perder.
Cuando no se definen, el DRP se vuelve un deseo. Cuando se definen mal, se invierte en lo incorrecto. Y cuando se definen bien, se convierte en un mapa de prioridades: qué se recupera primero, con qué recursos y en qué orden.
El enemigo silencioso: el “restore gap”
Hay organizaciones que hacen backups diarios, pero el negocio no puede perder 24 horas de transacciones. O hacen backups cada 4 horas, pero el tiempo de restauración toma 12. Ese desajuste se llama “restore gap”: el espacio entre lo que necesitas y lo que puedes.
La forma de cerrarlo no es solo comprar más almacenamiento. Es diseñar una estrategia completa:
- Clasificación de sistemas críticos (lo que “no puede caer”).
- Estrategia por capa: datos, app, infraestructura, identidad.
- Automatización de restauración (runbooks y orquestación).
- Pruebas periódicas (no una vez al año “por auditoría”).
Buenas prácticas que sí funcionan
1) Regla 3-2-1 (y su versión moderna):
- 3 copias de la información
- 2 medios distintos
- 1 copia fuera del sitio
Hoy suele ampliarse con: copias inmutables (no se pueden alterar) y/o almacenamiento con “air gap” lógico.
2) Backups inmutables y protección contra ransomware
El ransomware ya no solo cifra producción: intenta borrar respaldos. Si tus backups están en la misma red con permisos amplios, tu “plan de continuidad” puede caer en minutos.
3) Restauración por “servicio”, no por “archivo”
Recuperar archivos es útil. Recuperar servicios completos es lo que evita pérdidas. Tu plan debe incluir dependencias: DNS, Active Directory/identidad, certificados, llaves, acceso remoto, monitoreo, etc.
4) Pruebas realistas y repetibles
Una prueba útil responde:
- ¿Cuánto tardamos realmente?
- ¿Qué falló?
- ¿Qué faltó documentar?
- ¿Quién decide qué se recupera primero?
- ¿Cómo validamos que “ya opera” (no solo que “enciende”)?
5) “Lista de verificación” de recuperación
Una recuperación exitosa no termina cuando levantas un servidor, sino cuando:
- Los usuarios entran,
- Los procesos críticos corren,
- Los datos están consistentes,
- La seguridad está aplicada,
- Y existe evidencia para auditoría/seguimiento.
Señales de alerta
Si alguna te suena, hay riesgo real:
- “Nunca hemos hecho una restauración completa.”
- “Los backups los administra una sola persona.”
- “El repositorio de respaldos está en el mismo dominio/red.”
- “No sabemos el RTO/RPO de cada sistema.”
- “Confiamos en que ‘la nube’ se encarga.”
Si quieres convertir respaldos en recuperación real, Pulse (marca de Grupo Scanda) puede acompañarte a definir RTO/RPO, diseñar un DRP accionable y ejecutar pruebas de restauración con evidencia y mejora continua.
FAQ
1) ¿Un backup en la nube ya es DRP? No necesariamente. DRP incluye procesos, prioridades, accesos, pruebas y validación operativa.
2) ¿Cada cuánto debo probar mi DRP? Idealmente al menos anual “end-to-end” y pruebas parciales trimestrales, o ante cambios críticos.
3) ¿Qué es una copia inmutable? Un respaldo que no puede modificarse o borrarse durante un periodo, incluso si hay cuentas comprometidas.
4) ¿Qué diferencia hay entre alta disponibilidad y DRP? Alta disponibilidad reduce caídas; DRP te recupera cuando ya caíste (o te comprometieron).
5) ¿Qué es más importante: RTO o RPO? Depende del proceso. Facturación suele ser sensible a RPO; operación crítica suele ser sensible a RTO.
