Teníamos un hermoso motor de respaldos. Encriptación AES-256-GCM. 13 proveedores de almacenamiento. Compresión por chunks. Un pipeline de restauración. Un programador con expresiones cron. El dashboard tenía una página de respaldos con modales, un componente CronBuilder, configuración de proveedores de almacenamiento, y asistentes de tres pasos.
Luego un usuario hizo clic en "Respaldar ahora." El botón giró. Un toast dijo "Respaldo disparado." El respaldo apareció en la lista del historial con una insignia amarilla "pending."
Y se quedó pendiente. Para siempre.
El motor de respaldos existía. La infraestructura de programación existía. La UI existía. Pero nadie había cableado el disparador al motor. El manejador de API trigger_backup creaba un registro en la base de datos con status: "pending" y devolvía 202 Accepted. Nunca llamaba BackupEngine::create_backup().
Esta es la historia de todo lo que estaba roto, y cómo lo arreglamos en una sesión.
Bug 1: El manejador que no hacía nada
El manejador validaba la solicitud, insertaba una fila en la tabla backups, y devolvía. El BackupEngine nunca era invocado. La corrección fue agregar execute_existing_backup() y ejecutarlo como tarea en segundo plano con tokio::spawn.
Bug 2: El programador que nunca fue generado
El BackupScheduler existía, tenía tests unitarios, pero nunca fue instanciado en main.rs. No se había agregado el bloque spawn.
Bug 3: Los respaldos de volumen golpeaban el filesystem del host
La función backup_volume() intentaba crear un archivo tar en el filesystem del host. Los volúmenes Docker no son accesibles como rutas del host. La corrección fue usar la API de archivos de Docker: copy_from_container.
Bug 4: pg_dump intentaba respaldar "flin-postgres"
El motor usaba el nombre de la app como nombre de base de datos. El nombre real de la base de datos estaba enterrado en variables de entorno encriptadas. La corrección fue descifrar las env vars y extraer POSTGRES_DB.
Bug 5: La ruta de volumen por defecto era "/data"
PostgreSQL almacena datos en /var/lib/postgresql/data. MySQL usa /var/lib/mysql. La corrección fue un mapa de rutas por defecto consciente del stack.
Bug 6: "0 bases de datos disponibles"
Las apps de base de datos desplegadas vía plantillas se almacenan en la tabla apps, no en databases. La corrección fue detectar apps tipo base de datos por su campo stack.
Lo que la sesión produjo
Once correcciones. El motor de respaldos pasó de "se ve completo en revisión de código" a "realmente funciona de extremo a extremo."
La lección
Un motor de respaldos que nunca fue disparado es peor que no tener motor de respaldos. Crea falsa confianza. El pipeline de etapas era individualmente correcto. La integración -- la sola línea que llama engine.execute_existing_backup() -- faltaba.
La verdadera corrección no es solo el código. Es agregar tests de integración que verifiquen el flujo de extremo a extremo.
Siguiente en la serie: Cuando pg_dump no puede encontrar tu base de datos -- cómo las bases de datos desplegadas por plantilla almacenan credenciales, por qué app.name no es db_name, y el pipeline de descifrado de env vars.