Un backup que no se restaura es una carpeta grande con nombre tranquilizador

Hasta finales de agosto el homelab no tenía backups de ningún tipo. Un fallo del disco del sistema se habría llevado la configuración del cortafuegos, el vault de contraseñas y todos los contenedores. Así que monté Proxmox Backup Server, un trabajo diario a las 02:30 sobre las nueve máquinas, retención de siete diarios, cuatro semanales y seis mensuales. La interfaz decía que sí a todo.

Antes de dar el sistema por bueno hice lo que casi nadie hace: restaurar de verdad, de extremo a extremo, y comprobar que lo restaurado servía.

La restauración

Restauré el contenedor del gestor de contraseñas a un contenedor nuevo, sin tocar el de producción y sin arrancarlo automáticamente: heredaría la configuración de red del original y habría dos máquinas pidiendo la misma IP. Luego lo arranqué a mano y miré el dato que importaba:

db.sqlite3          286720 bytes   <- el vault
db.sqlite3-wal           0 bytes   <- sin transacciones a medias
rsa_key.pem           1675 bytes   <- firma los tokens de sesión

Cada fichero confirma una cosa distinta. El WAL a cero bytes era precisamente mi duda con el modo snapshot, que hace la copia con el contenedor en marcha: salió limpio. Y sin la clave RSA, todos los dispositivos tendrían que volver a autenticarse. Lo destruí y me quedé tranquilo. Con razón, pero con menos razón de la que creía.

El hueco

Al día siguiente subí las primeras 4.133 fotos a Immich. Y antes de borrarlas del iPhone, comprobé que estuvieran respaldadas.

No lo estaban. La señal fue la duración: un backup manual del contenedor de Immich terminó con TASK OK en tres minutos. Para 44 GB sobre un disco USB era imposible. El datastore ocupaba lo mismo que antes de subir la biblioteca. Y el log lo decía, en una línea fácil de pasar por alto entre las demás:

INFO: including mount point rootfs ('/') in backup
INFO: excluding bind mount point mp0 ('/library') from backup (not a volume)

La herramienta de respaldo del hipervisor trabaja sobre volúmenes gestionados por Proxmox. La biblioteca de fotos no estaba en uno: estaba en un montaje enlazado desde el disco grande hacia el contenedor, precisamente para que no ocupara en el disco del sistema. Y esos montajes no entran en la copia. Nunca. No es una opción: es diseño. Probé a añadir backup=1 al punto de montaje y no sirvió de nada, porque esa opción solo aplica a volúmenes.

Sin error, sin aviso, sin nada en rojo. El trabajo terminaba correctamente porque estaba haciendo exactamente lo que sabe hacer. Lo único que faltaba era que yo asumiera que cubría algo que nunca prometió cubrir.

La solución

Tres opciones: el cliente de PBS desde el host respaldando el directorio directamente al datastore, rsync a otro disco, o convertir el montaje en un volumen gestionado. Elegí la primera porque reutiliza la infraestructura que ya había: proxmox-backup-client programado con un timer de systemd a las 03:15, una hora después del trabajo general, con su propia retención.

El mismo razonamiento aplicaba a la carpeta de películas, que también es un montaje enlazado. Ahí lo dejé sin respaldar a propósito: si se pierden, se vuelven a descargar. Si se pierden las fotos, no.

La forma general del error

Este fallo no va de una herramienta concreta. Va de que verde no significa completo. Un trabajo automático te dice que ha hecho su tarea, no que su tarea sea la que tú crees.

Cuatro cosas que me llevo:

1. Un backup que termina bien no significa que contenga lo que crees. Hay que comprobar qué respalda, no solo que se ejecute.
2. La duración y el tamaño son señales diagnósticas. Si un backup de 44 GB tarda tres minutos, algo falta. Los números demasiado buenos merecen una comprobación.
3. du -sh sobre el datastore es la verificación más directa. Si no crece cuando debería, no está entrando el dato.
4. Verificar antes de destruir el original. Lo comprobé antes de borrar las fotos del teléfono. De haberlas borrado primero, la única copia habría sido el disco USB, sin respaldo y sin saberlo.

La única comprobación que no se puede falsear es la restauración. Todo lo demás es confianza. Y ahora con un matiz: tener un backup que se ejecuta no es lo mismo que tener respaldados los datos que importan.

Lo que sigue mal

Todas las copias viven en el mismo disco físico y en la misma casa que los datos originales. Contra un fallo del disco del sistema, un borrado accidental o una corrupción, estoy cubierto. Contra un incendio, un robo, una sobretensión o un fallo del propio disco de copias, no.

Lo escribo porque la solución es un disco de sesenta euros que se conecta una vez al mes, y ponerlo por escrito hace más probable que lo compre. Y porque he apuntado una restauración de prueba cada tres meses: es la que más se olvida y la única que demuestra que el sistema sigue funcionando.