Tener copias de seguridad y poder recuperarse no son lo mismo. Son dos preguntas distintas que se suelen confundir: ¿existe una copia de este sistema? y ¿puede este sistema volver a estar en producción, con sus dependencias, en el tiempo que el negocio necesita? La primera se responde mirando un panel de backups en verde. La segunda solo se responde probando la recuperación completa, y esa prueba suele hacerse tarde, o no hacerse nunca.
La diferencia entre ambas preguntas no se nota en el día a día. Se nota el día del incidente, que suele ser el peor momento posible para descubrir que la copia existía pero la recuperación no funcionaba como se pensaba.
RTO y RPO: lo que dice el papel y lo que dice el cronómetro
RTO (tiempo objetivo de recuperación) y RPO (punto objetivo de recuperación) son las dos métricas que definen cuánto se puede tardar en volver y cuánto se puede permitir perder. El problema no es definirlas, la mayoría de organizaciones tiene un documento con esos números. El problema es que esos números casi nunca se han medido de verdad.
Un RTO de cuatro horas escrito en un documento de continuidad de negocio (una de las obligaciones que impone la NIS2) y un RTO de cuatro horas verificado con un ejercicio de recuperación real son cosas distintas. El primero es una aspiración. El segundo es un dato. Solo el ejercicio real revela cuánto tiempo se va realmente en localizar la última copia válida, en levantar la infraestructura de destino, en restaurar en el orden correcto y en verificar que el servicio funciona de extremo a extremo, no solo que el proceso de restauración terminó sin errores.
Las dependencias ocultas que rompen un restauro
En casi todas las pruebas de recuperación aparece lo mismo, y casi nunca es la copia en sí. Lo que falla suele ser el contexto que rodea al sistema restaurado:
- DNS: la máquina restaura bien, pero apunta a un registro que ya no existe o que ahora resuelve a otra dirección.
- Certificados: el certificado caducó hace tiempo y nadie lo renovó porque el servicio llevaba meses sin desplegarse desde cero.
- Credenciales: las claves o cuentas de servicio que usaba el sistema original ya no son válidas, o dependían de un secreto que solo existía en el entorno de producción.
- Licencias: el software restaurado pide una activación o un límite de instalaciones que no contempla un entorno de recuperación temporal.
- Orden de arranque: el servicio vuelve, pero depende de una base de datos, una cola de mensajes o un servicio de autenticación que todavía no está disponible.
Ninguna de estas dependencias aparece en un backup exitoso. Todas aparecen en una recuperación real. Por eso probar solo que la copia se puede restaurar, sin levantar el entorno completo, deja fuera la parte que de verdad falla.
El orden de arranque importa tanto como la copia
Un sistema moderno rara vez es una sola máquina. Es una cadena de servicios que dependen unos de otros: base de datos, caché, cola de mensajes, servicio de autenticación, balanceador y, encima de todo, la aplicación. Si el orden de arranque no está documentado y probado, la recuperación se convierte en un proceso de prueba y error justo cuando menos tiempo hay para improvisar. Documentar ese orden, y probarlo, es tan parte del backup como la propia copia de los datos.
La única prueba que vale es la prueba completa
Restaurar un archivo suelto para comprobar que la copia «funciona» no dice nada sobre si el servicio completo se recupera. La prueba que aporta valor real es la que reproduce el escenario de un incidente: levantar el sistema en un entorno distinto, con sus dependencias, y comprobar que responde igual que en producción, dentro del RTO que se ha prometido. Herramientas como Proxmox Backup Server facilitan automatizar y programar ese tipo de pruebas de forma periódica, en lugar de dejarlas para una fecha que nunca llega.
Qué hacer ya
- Programar una prueba de recuperación completa, no solo de restauración de archivos, al menos una vez al trimestre.
- Documentar y verificar el orden de arranque real de cada servicio crítico y sus dependencias.
- Revisar certificados, credenciales y licencias asociadas a los sistemas que se restauran, no solo a los que están en producción.
- Medir el RTO y el RPO reales durante el ejercicio, y compararlos con los que figuran en el documento de continuidad.
- Tratar cada prueba fallida como información, no como un problema que ocultar: es la única forma de saber si el backup salva de verdad.
Un backup que nunca se ha probado no es una garantía, es una suposición. La diferencia entre las dos solo se conoce el día que hace falta, y para entonces ya es tarde para elegir cuándo enterarse. El equipo de infraestructuras cloud y servicios IT de Irontec diseña y prueba estos planes de recuperación como parte de la operación habitual, no como un ejercicio puntual.
