En la mayoría de las empresas medianas con las que conversamos, la respuesta a la pregunta «¿Tienen respaldos de sus sistemas críticos?» es un rotundo sí. Generalmente, el encargado de TI abre una consola y nos muestra un panel limpio, lleno de “checks” verdes que indican que la copia de seguridad de la noche anterior se completó con éxito.
Ahí radica el sesgo de seguridad más peligroso de la infraestructura tecnológica: confundir la capacidad de respaldar con la capacidad de recuperar.
Tener un archivo .bak o una snapshot almacenada de forma segura en un almacenamiento local o en la nube no garantiza absolutamente nada si el día en que la infraestructura principal falle (sea por un ataque de ransomware, un error humano catastrófico o un fallo físico de hardware), el equipo no tiene certeza de cuánto tiempo tardará en levantar los servicios o si esos datos realmente son íntegros.
El análisis de Aleph Server: Por qué fallan las estrategias de backup tradicionales
Cuando evaluamos la resiliencia operativa en una empresa mediana, no nos enfocamos en el software de backup que contrataron. Nos enfocamos en las métricas reales de negocio y en la fricción técnica del proceso de restauración. Estos son los tres puntos ciegos habituales que detectamos:
- La falacia del “Check” Verde: Un respaldo puede completarse sin errores de transferencia, pero contener datos corruptos o tablas inconsistentes. Si no existen pruebas periódicas de restauración automatizada en un entorno aislado (sandbox), el respaldo es solo un acto de fe.
- El cuello de botella del tiempo (RTO subestimado): Supongamos que se cuenta con 4 Terabytes de datos respaldados de forma segura en la nube. Si el enlace de internet local o la tasa de lectura del almacenamiento de respaldo está limitada, descargar, montar y levantar esa información puede tomar 36 o 48 horas. ¿Puede el negocio operar dos días enteros con los sistemas abajo? El costo de la inactividad suele ser exponencialmente mayor que el costo de optimizar la velocidad de restauración.
- La dependencia del procedimiento, no de la herramienta: Si el procedimiento para reconstruir la infraestructura y montar los respaldos solo está en la cabeza de la persona de TI que configuró el sistema hace tres años, el riesgo no es técnico, es organizacional. Si esa persona no está disponible durante la crisis, el respaldo se vuelve inaccesible.
El criterio de continuidad: Pasar del Backup al DRP (Disaster Recovery Plan)
Para que una estrategia de recuperación funcione en una empresa mediana, debe bajar de la teoría de los folletos de software a un checklist práctico e incómodo. En Aleph Server aplicamos cuatro reglas mínimas antes de considerar que la información de un cliente está realmente a salvo:
- Medir el RTO (Recovery Time Objective) real, no el teórico: No asumas cuánto tardará. Haz una simulación un sábado por la tarde. Apaga un servidor virtual secundario, intenta restaurarlo desde cero en otra máquina física (aprovechando, por ejemplo, la flexibilidad de entornos virtualizados robustos como Proxmox VE) y mide el tiempo exacto con cronómetro en mano.
- Automatizar la verificación de integridad: No dependas de revisiones manuales porque el equipo de TI suele estar sobrepasado con el día a día. El sistema de respaldo debe ser capaz de montar la copia de forma automatizada en un entorno de pruebas semanal, verificar que los servicios esenciales (como el motor de base de datos) inicien correctamente y destruir la instancia tras enviar un reporte de éxito real.
- Documentar para el peor escenario: El manual de restauración debe estar escrito en frío, asumiendo que el administrador principal de la red no está disponible y que el sistema debe ser levantado por un ingeniero de soporte externo. Pasos claros, direcciones IP de contingencia predefinidas y mapas de dependencias de servicios explícitos.
- Definir el RPO (Recovery Point Objective) para cada sistema crítico: ¿cuánta pérdida de datos es aceptable, medida en tiempo desde el último respaldo válido? Un sistema que se restaura en 2 horas pero cuyo último backup verificado tiene 24 horas de antigüedad puede generar un impacto operacional mayor que el propio tiempo de inactividad. La frecuencia del respaldo debe derivarse del RPO definido —no de la conveniencia operacional. Un ERP transaccional con operaciones continuas puede requerir un RPO de 1 hora o menos; un sistema de reportes interno puede tolerar un RPO de 24 horas. La diferencia entre ambos debe estar definida antes de que ocurra el incidente, no durante.
RTO y RPO orientativos por tipo de sistema
Como punto de partida para que el equipo TI de cada empresa pueda hacer su propio diagnóstico:
| Tipo de sistema | RTO orientativo | RPO orientativo | Justificación |
| ERP / sistema transaccional | < 4 horas | < 1 hora | Impacto directo en operación y registro de transacciones |
| Base de datos operacional | < 2 horas | < 30 minutos | Dependencia de múltiples sistemas aguas arriba |
| Servidor de archivos compartido | < 8 horas | < 4 horas | Acceso crítico pero tolerancia mayor que transaccional |
| Sistema de correo corporativo | < 4 horas | < 2 horas | Comunicación durante la crisis depende de él |
| Sistema de reportes interno | < 24 horas | < 24 horas | Uso periódico, menor criticidad operacional inmediata |
Conclusión
Los respaldos son un costo de infraestructura; la capacidad de recuperación es una póliza de supervivencia para el negocio. Dejar de mirar el panel de backups y empezar a medir el tiempo real que toma volver a operar es el primer paso para mitigar un riesgo que ninguna empresa mediana puede permitirse ignorar.
