El panel muestra copias completadas cada noche. Todo aparece en verde. Entonces falla una base de datos, alguien elimina un fichero o una actualización deja la aplicación inutilizable.
La pregunta importante deja de ser si existe un backup. Pasa a ser: ¿podemos recuperar un servicio útil, cuánto tardaremos y qué datos perderemos?
Una agencia que mantiene soluciones para varios clientes puede tener decenas de copias y, aun así, no disponer de un procedimiento de recuperación repetible. El problema suele permanecer oculto hasta el peor momento.
Una copia no contiene necesariamente el servicio
Una aplicación rara vez es solo una base de datos. También puede depender de:
- objetos o documentos almacenados;
- variables de entorno y secretos;
- versiones concretas de contenedores;
- configuración de red y DNS;
- colas con trabajo pendiente;
- índices de búsqueda o bases vectoriales;
- permisos e identidades;
- infraestructura definida fuera del repositorio;
- servicios externos y sus credenciales.
Restaurar una tabla no garantiza que el sistema vuelva a procesar documentos, que un agente recupere el contexto correcto o que los webhooks pendientes no se dupliquen.
El objeto de recuperación debe ser el servicio completo, no el fichero de backup.
RPO y RTO sin jerga
Dos preguntas convierten una expectativa vaga en una decisión operativa.
El RPO responde a cuánto trabajo se puede perder. Si el último punto recuperable tiene cuatro horas, todo lo ocurrido después puede desaparecer.
El RTO responde a cuánto tiempo puede permanecer interrumpido el servicio. Incluye detectar el fallo, decidir recuperar, conseguir acceso, restaurar, validar y volver a abrir el tráfico.
Decir “hacemos backup diario” no responde ninguna de las dos preguntas. Puede significar una pérdida aceptable de datos para un proyecto interno y resultar inasumible para un proceso que recibe pedidos o documentación de clientes.
Cinco fallos que una pantalla verde no muestra
1. La copia está en el mismo lugar que el fallo
Una cuenta comprometida, una política mal aplicada o un error de automatización puede alcanzar al servicio y a sus copias. La separación lógica, los permisos restringidos y las políticas de retención reducen ese radio de impacto.
2. Nadie conoce la secuencia
Base de datos primero, aplicación después, DNS al final. O quizá no. Cuando el orden solo está en la memoria de una persona, la recuperación comienza con una investigación.
3. Faltan secretos o configuración
El código está en Git y los datos en una copia, pero nadie puede reconstruir identidades, certificados o variables. La infraestructura reproducible debe incluir una estrategia para recuperar configuración sensible sin copiar secretos de forma insegura.
4. Restaurar genera efectos secundarios
Repetir eventos puede enviar dos veces una factura, reprocesar documentos o disparar notificaciones antiguas. Los procesos necesitan idempotencia y una forma de distinguir trabajo recuperado de trabajo nuevo.
5. El backup nunca se ha abierto
Una tarea puede terminar correctamente y producir una copia incompleta, corrupta o incompatible con la versión actual. La única comprobación convincente es restaurarla y validar el servicio.
Un ejercicio de recuperación pequeño pero real
No hace falta simular la caída de toda la región el primer día. Se puede empezar con un cliente y un escenario limitado:
- elegir una pérdida concreta, como una base de datos eliminada;
- declarar el RPO y el RTO esperados;
- asignar a una persona que no haya diseñado el sistema;
- recuperar en un entorno aislado;
- validar datos, accesos y funciones críticas;
- registrar el tiempo y cada paso improvisado;
- convertir esos pasos en automatización o documentación;
- repetir el ejercicio hasta que el resultado sea predecible.
La validación no debería limitarse a “la aplicación abre”. Conviene comprobar una transacción completa: subir un documento, ejecutar el procesamiento, consultar el resultado y revisar que métricas y alertas vuelven a funcionar.
Recuperación en una operación multi-cliente
Cuando cada cliente usa una arquitectura distinta, cada recuperación se convierte en un proyecto. Una base de entrega multi-cliente permite reutilizar:
- políticas de copia y retención;
- procedimientos de restauración;
- plantillas de infraestructura;
- criterios de validación;
- responsables y canales de incidente;
- registro del último ejercicio realizado.
Estandarizar no obliga a dar el mismo RPO a todos. Permite aplicar niveles distintos mediante un proceso conocido.
El coste debe formar parte del servicio
Una retención larga, copias inmutables y recuperación rápida tienen coste. También lo tienen los ejercicios periódicos. Si esas capacidades se prometen pero no se presupuestan, terminan dependiendo del tiempo libre del equipo.
Cada propuesta de mantenimiento debería aclarar:
- qué componentes se copian;
- con qué frecuencia;
- durante cuánto tiempo;
- dónde se guardan;
- quién puede restaurarlos;
- qué RPO y RTO se han acordado;
- cuándo se probó por última vez;
- qué queda fuera del alcance.
No todas las soluciones necesitan recuperación inmediata. Todas necesitan una expectativa honesta.
La pregunta que descubre el riesgo
Escoge un cliente y pregunta a una persona distinta de quien construyó la solución:
Si hoy perdemos producción, ¿qué restauras primero y cómo demuestras que el servicio vuelve a ser fiable?
Si la respuesta empieza buscando accesos, preguntando qué se copiaba o leyendo mensajes antiguos, el problema no es el backup. Es la ausencia de un sistema de recuperación.
