Proxmox PBS: Copias de seguridad exitosas pero restauraciones fallidas — La lista de verificación que las detecta

Fallos de restauración: un modelo mental que realmente ayuda

PBS está diseñado para copias eficientes, desduplicadas e incrementales. Ese diseño es exactamente la razón por la que “la copia fue exitosa” no es una prueba sólida de que “la restauración funcionará”. Una copia exitosa puede consistir mayormente en transmitir nuevos chunks hacia un datastore, mientras que una restauración debe localizar, descifrar, verificar y rehidratar un grafo potencialmente enorme de chunks a través del tiempo, entre snapshots, entre namespaces, y a veces atravesando permisos y rutas de red diferentes a la ruta de la copia.

Las copias son mayormente “ruta de escritura”; las restauraciones son “ruta de lectura bajo estrés”

Las copias tienden a ser escrituras secuenciales más algunas actualizaciones de metadatos. Las restauraciones están amplificadas en lectura: muchas lecturas de chunks aleatorias, descompresión, verificación opcional, y mayor sensibilidad a la latencia. Si tu backend de almacenamiento tiene peculiaridades (caché de atributos NFS, mismatch de recordsize en ZFS, SAN thin-provisioned que miente, un controlador RAID con políticas de caché sorprendentes), las restauraciones las encontrarán.

Tres capas deben coincidir: identidad, integridad y ubicación

• Identidad: Debes estar autorizado (PBS ACLs), y tu cliente debe presentar las credenciales o el token API esperado. Las herramientas de restauración a menudo se ejecutan bajo una identidad diferente que los trabajos de copia.
• Integridad: El almacén de chunks debe ser consistente. Chunks faltantes, corruptos o una recolección de basura incompleta pueden permanecer ocultos hasta que ejecutas una restauración o una verificación.
• Ubicación: La ruta de red, DNS, firewall, MTU, proxy, confianza TLS y el tiempo deben alinearse. Las copias pueden atravesar una ruta; las restauraciones otra (especialmente si restauras en un nodo distinto).

Una heurística decente: si las copias están en verde pero las restauraciones fallan, asume primero ruta de lectura + permisos + trabajos de ciclo de vida, y asume “mi software de backup mintió” al final.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el flujo para “detener la hemorragia”. Hazlo en orden. No improvises. El objetivo es encontrar el cuello de botella rápidamente y profundizar sólo donde sea necesario.

Primero: identifica qué tipo de fallo de restauración tienes

1. Fallo duro inmediato: permiso denegado, error de autenticación, coincidencia de fingerprint, repositorio no encontrado, errores TLS.
2. Fallo duro a mitad de flujo: chunks faltantes, errores de checksum, errores de E/S, sistema de archivos en sólo lectura.
3. Fallo suave (colgado/lento): atascado al 0%, “aún en ejecución”, ETA irreal.

Segundo: confirma lo básico que hace las restauraciones diferentes a las copias

1. ¿Quién realiza la restauración? ¿El mismo usuario/token de PBS que el trabajo de backup? ¿Mismo namespace? ¿Misma ruta ACL?
2. ¿Dónde estás restaurando? ¿Nodo Proxmox distinto, red distinta, objetivo de almacenamiento distinto?
3. ¿PBS está bajo carga por prune/GC/verify? Esos trabajos pueden “estar bien” durante las copias y ser brutales durante las restauraciones.

Tercero: elige una vía de análisis profundo

• Vía Auth/ACL/TLS si el error aparece antes de que empiece el movimiento de datos.
• Vía integridad del datastore si ves chunks faltantes, errores de verificación o fallos de lectura durante la restauración.
• Vía rendimiento de almacenamiento si las restauraciones son lentas/colgadas y el datastore está en NFS/Ceph/ZFS-on-RAID.
• Vía red si ves timeouts, reseteos, comportamientos MTU raros, o las restauraciones fallan sólo desde un nodo.

Datos y contexto interesantes (por qué PBS se comporta así)

• PBS usa un almacén de chunks con desduplicación: las restauraciones pueden depender de chunks creados semanas atrás, no sólo de la copia de la noche anterior.
• Prune y garbage collection son conceptos separados: prune elimina referencias a snapshots; GC recupera chunks no referenciados más tarde. Un snapshot puede desaparecer “lógicamente” antes de que el espacio se recupere “físicamente”.
• La verificación no es sólo un botón para sentirse bien: es tu sistema de alerta temprana para corrupción de chunks o escrituras incompletas que no salieron durante la copia.
• Las copias incrementales reducen la carga de escritura pero pueden aumentar la profundidad de dependencia de restauración: cuanto más dependas del historial, más necesitarás integridad de chunks a largo plazo.
• El cifrado del lado cliente cambia la forma de falla: una clave incorrecta o un archivo de clave ausente suele parecer “los datos existen pero no pueden leerse”, porque es literalmente así.
• Las restauraciones son sensibles a la latencia: un datastore en almacenamiento de alta latencia (o NFS con malas opciones) puede hacer copias bien pero restaurar dolorosamente por la amplificación de lectura.
• Namespaces y ACLs son poderosos y afilados: es fácil otorgar derechos de copia sin otorgar derechos de restauración, especialmente cuando los tokens están muy limitados.
• El tiempo importa más de lo que se piensa: TLS, validación de tickets y correlación de logs se vuelven confusos cuando los nodos derivan. Puedes “autenticarse” y aun así romper transferencias largas.
• “Copia exitosa” a menudo significa “el servidor aceptó el stream”: no garantiza que el backend de almacenamiento lo haya preservado correctamente para lecturas posteriores (hola, discos defectuosos y semánticas NFS).

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas tareas están pensadas para ejecutarse en un entorno típico Proxmox VE + PBS. Ajusta nombres de host, nombres de datastore e IDs. Cada tarea incluye: comando, qué significa la salida y qué decisión tomar a continuación.

Tarea 1: Comprobar la salud del servicio PBS (lado servidor)

cr0x@pbs01:~$ systemctl status proxmox-backup
● proxmox-backup.service - Proxmox Backup Server API and daemon
     Loaded: loaded (/lib/systemd/system/proxmox-backup.service; enabled)
     Active: active (running) since Tue 2026-02-04 08:11:02 UTC; 3h 12min ago
       Docs: man:proxmox-backup-api(1)
             man:proxmox-backup-proxy(1)
   Main PID: 1123 (proxmox-backup)
      Tasks: 14 (limit: 154225)
     Memory: 312.4M
        CPU: 19min 22.341s
     CGroup: /system.slice/proxmox-backup.service
             ├─1123 proxmox-backup-api
             └─1131 proxmox-backup-proxy

Significado: Si no está activo/en ejecución, las restauraciones fallarán de maneras creativas (timeouts, 500s, conexión rechazada).

Decisión: Si no está en ejecución, arregla PBS primero (servicio, disco lleno, config corrupta). No persigas fantasmas del lado cliente.

Tarea 2: Lee los logs del tiempo de restauración, no los de la copia

cr0x@pbs01:~$ journalctl -u proxmox-backup --since "30 min ago" --no-pager
Feb 04 11:52:18 pbs01 proxmox-backup-api[1123]: authentication failed for user 'backup@pbs'
Feb 04 11:52:18 pbs01 proxmox-backup-api[1123]: permission check failed: missing Datastore.Read on /datastore/vmstore
Feb 04 11:52:21 pbs01 proxmox-backup-api[1123]: client disconnected (TLS error: alert bad certificate)

Significado: PBS frecuentemente te dice exactamente qué permiso o condición TLS falló. “Datastore.Read” faltante es la clásica brecha ACL sólo para restauración.

Decisión: Si ves errores de auth/ACL/TLS aquí, detente y arregla identidad/confianza antes de tocar el almacenamiento.

Tarea 3: Confirma que el datastore está montado y escribible (host PBS)

cr0x@pbs01:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
vmstore      dir        active      70368744177664    4966055936000   65402688241664    7%

Significado: “active” es bueno. Si falta/inactivo, PBS puede aceptar metadata pero fallar al leer chunks, o fallar a mitad de restauración.

Decisión: Si está inactivo, arregla el montaje (NFS caído, pool ZFS degradado, permisos) antes de intentar restaurar de nuevo.

Tarea 4: Comprueba errores a nivel filesystem (los remount a sólo lectura son reales)

cr0x@pbs01:~$ dmesg -T | tail -n 20
[Mon Feb  4 11:41:07 2026] EXT4-fs error (device sdb1): ext4_find_entry:1453: inode #262145: comm proxmox-backup: reading directory lblock 0
[Mon Feb  4 11:41:07 2026] Aborting journal on device sdb1-8.
[Mon Feb  4 11:41:07 2026] EXT4-fs (sdb1): Remounting filesystem read-only

Significado: Si el filesystem se remonta en sólo lectura, las restauraciones fallarán (a veces después de “empezar bien”). Las copias podrían haberse completado antes de que ocurriera el problema.

Decisión: Trata esto como un incidente de almacenamiento. Detén las escrituras de PBS, repara el filesystem y valida la integridad del datastore después.

Tarea 5: Verifica la sincronización horaria (TLS y sesiones largas odian la deriva)

cr0x@pbs01:~$ timedatectl
               Local time: Tue 2026-02-04 12:03:44 UTC
           Universal time: Tue 2026-02-04 12:03:44 UTC
                 RTC time: Tue 2026-02-04 12:03:45
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: Si “System clock synchronized: no” en PBS o nodos PVE, espera comportamientos raros en validación de certificados, expiración de tokens y logs desalineados.

Decisión: Arregla la hora primero. Es rápido y elimina toda una clase de fallos “imposibles”.

Tarea 6: Confirma conectividad API y fingerprint (confianza del cliente)

cr0x@pve01:~$ proxmox-backup-manager cert info
Subject Name: /CN=pbs01
Issuer Name: /CN=pbs01
Valid Since: 2025-09-14 09:20:48
Valid Until: 2035-09-12 09:20:48
Fingerprint (sha256): 7E:1A:3B:9F:4B:41:2C:2A:9B:AD:9C:3D:25:0C:11:1A:AF:3A:0F:DE:41:19:92:33:6E:9B:7A:45:4F:0C:8A:21

Significado: La discrepancia de fingerprint entre lo que el cliente confía y lo que PBS presenta causa fallos súbitos tras reinstalación o regeneración de certificados.

Decisión: Si PBS fue reconstruido o su cert cambió, vuelve a confiar en el nuevo fingerprint en los nodos PVE (y documenta el cambio).

Tarea 7: Valida la configuración del repositorio en el nodo que realiza la restauración

cr0x@pve01:~$ cat /etc/pve/storage.cfg
pbs: pbs-vmstore
        datastore vmstore
        server pbs01
        content backup
        fingerprint 7E:1A:3B:9F:4B:41:2C:2A:9B:AD:9C:3D:25:0C:11:1A:AF:3A:0F:DE:41:19:92:33:6E:9B:7A:45:4F:0C:8A:21
        username backup@pbs
        token backup-token
        namespace prod

Significado: Las restauraciones se realizan desde la perspectiva del nodo PVE. Namespace incorrecto, username/token equivocado o fingerprint obsoleto romperán la restauración incluso si las copias desde otro nodo siguen funcionando.

Decisión: Alinea storage.cfg en todos los nodos que puedan realizar restauraciones. No asumas que el “nodo de backup” es el “nodo de restauración”.

Tarea 8: Comprueba los ACLs de PBS para permisos de restauración (lado servidor)

cr0x@pbs01:~$ proxmox-backup-manager acl list
/path /datastore/vmstore, user backup@pbs, role DatastoreBackup
/path /datastore/vmstore, user restore-ops@pbs, role DatastoreReader
/path /, user root@pam, role Administrator

Significado: Un rol como “DatastoreBackup” puede ser suficiente para copias pero no para explorar/restaurar, según tu configuración y herramientas. Los permisos de lector (o más) pueden ser requeridos para el flujo de restauración.

Decisión: Asegura que la identidad usada para restaurar tenga los permisos de lectura necesarios sobre el path del datastore y el namespace correcto. Si usas tokens API, asegúrate de que el token no esté más restringido que el usuario.

Tarea 9: Lista snapshots y asegúrate de restaurar lo que crees

cr0x@pbs01:~$ proxmox-backup-client snapshot list --repository backup@pbs@pbs01:vmstore --ns prod | head
vm/101/2026-02-03T01:00:12Z
vm/101/2026-02-02T01:00:10Z
vm/101/2026-02-01T01:00:09Z
ct/203/2026-02-03T01:10:05Z
ct/203/2026-02-02T01:10:02Z

Significado: Si el snapshot que quieres no aparece bajo el namespace que estás usando, las restauraciones “fallarán” al no encontrar nada.

Decisión: Confirma namespace y tipo de grupo de backup (vm vs ct vs host). No pierdas una hora restaurando la cosa equivocada a la perfección.

Tarea 10: Ejecuta un verify del datastore e interpreta los resultados (vía integridad)

cr0x@pbs01:~$ proxmox-backup-manager datastore verify vmstore --ignore-verified 1
starting datastore verify: vmstore
found 8123 snapshot(s)
verified 131072 chunks (12.5 GiB)
ERROR: missing chunk 3a2f0f9d3c0a... referenced by vm/101/2026-02-03T01:00:12Z
ERROR: verification failed: 1 errors found

Significado: “missing chunk” no es un problema cosmético. Ese snapshot (y posiblemente otros) no pueden restaurarse completamente.

Decisión: Deja de asumir. Ahora haces triage de incidente: identifica el radio de daño (qué grupos/snapshots), comprueba la salud del backend de almacenamiento y decide si puedes restaurar desde un snapshot anterior o desde otro datastore/replica.

Tarea 11: Revisa horarios de prune/GC y tareas en ejecución (vía contención)

cr0x@pbs01:~$ proxmox-backup-manager task list --running 1
UPID:pbs01:0000A1B3:0001C2D4:67A1F2C3:garbage_collection:vmstore:root@pam:
UPID:pbs01:0000A1C0:0001C2F1:67A1F2DA:verify:vmstore:root@pam:

Significado: GC + verify mientras intentas una restauración grande es como programar obras viales durante una evacuación. Puede funcionar, pero es una elección.

Decisión: Para restauraciones urgentes, pausa o reprograma tareas de mantenimiento pesado. Luego reintenta la restauración y observa si el modo de fallo cambia de “timeout/lento” a “funciona”.

Tarea 12: Mide la latencia de I/O del datastore de forma simple (¿el almacenamiento miente?)

cr0x@pbs01:~$ iostat -x 1 5
Linux 6.5.11 (pbs01)  02/04/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.12    0.00    2.98   22.45    0.00   70.45

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sdb              82.0   310.0  9120.0 50240.0  87.35   3.12  99.80

Significado: Alto await y utilización cercana al 100% indican que el subsistema de disco está saturado o sufre. Las restauraciones son las primeras en castigarse porque son intensivas en lectura y sensibles a la latencia.

Decisión: Si await es alto, no estás depurando PBS; estás depurando rendimiento y contención de almacenamiento. Considera mover el datastore, añadir caché o reducir trabajos concurrentes.

Tarea 13: Confirma estabilidad de red y supuestos de MTU (vía timeout)

cr0x@pve01:~$ ping -M do -s 8972 -c 3 pbs01
PING pbs01 (10.10.10.20) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- pbs01 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Significado: Alguien supuso que las jumbo frames existían end-to-end. Estaban equivocados. Las copias pueden tolerar fragmentación o patrones de flujo distintos; las restauraciones pueden golpear una ruta que no lo hace.

Decisión: O arregla MTU de forma consistente en toda la ruta o deja de fingir y usa 1500 en todas partes. MTU mixto es un generador de outage en cámara lenta.

Tarea 14: Confirma DNS y reverse DNS (el culpable aburrido)

cr0x@pve01:~$ getent hosts pbs01
10.10.10.20     pbs01 pbs01.internal

Significado: Si la resolución de nombres difiere entre nodos, puedes terminar confiando en un nombre de certificado pero conectando por otro, o enrutando distinto para restauraciones.

Decisión: Estandariza cómo los nodos PVE se refieren a PBS (nombre vs IP), y haz que el CN/SAN del certificado coincida con esa realidad.

Tarea 15: Intenta montar la restauración a nivel de archivos (prueba la ruta de lectura sin sobrescribir VMs)

cr0x@pve01:~$ proxmox-backup-client mount vm/101/2026-02-03T01:00:12Z drive-scsi0 --repository backup@pbs@pbs01:vmstore --ns prod /mnt/pbs-test
mounted file system at "/mnt/pbs-test"

Significado: Si el mount falla con chunks faltantes o errores de permiso, has reproducido el fallo de restauración de forma de bajo riesgo.

Decisión: Usa esto como prueba previa después de cualquier arreglo. Si el mount funciona y navegar archivos es correcto, una restauración completa tiene muchas más probabilidades de funcionar.

Tarea 16: Inspecciona la propiedad del grupo de backup y el modo de cifrado (cuando las claves son el problema)

cr0x@pve01:~$ proxmox-backup-client snapshot list --repository backup@pbs@pbs01:vmstore --ns prod --output-format json | head -n 5
[
  {"backup-id":"101","backup-time":1706922012,"backup-type":"vm","comment":null},
  {"backup-id":"101","backup-time":1706835610,"backup-type":"vm","comment":null},
  {"backup-id":"101","backup-time":1706749209,"backup-type":"vm","comment":null},
  {"backup-id":"203","backup-time":1706922605,"backup-type":"ct","comment":null},

Significado: El listado de snapshots funciona, pero la restauración aún puede fallar si las claves de cifrado faltan en el host de restauración. Listar metadata es menos costoso que descifrar payload.

Decisión: Si usas cifrado del lado cliente, valida que los archivos de clave estén presentes y accesibles en el nodo de restauración (y protegidos adecuadamente). No “desactives temporalmente” el cifrado por comodidad y luego lo olvides.

Chiste #1: Las copias de seguridad son como los paracaídas: tener uno está bien, pero sólo sabes si funciona cuando ya estás teniendo un mal día.

Errores comunes: síntoma → causa raíz → solución

1) “Permiso denegado” durante restauración, pero las copias se ejecutan cada noche

Síntoma: La restauración falla inmediatamente; los logs muestran falta de Datastore.Read o permisos de namespace.

Causa raíz: El token/usuario de backup tiene derechos para enviar copias pero no para explorar/restaurar snapshots, o la restauración se intenta desde un nodo diferente con un token distinto.

Solución: Otorga a la identidad de restauración permisos de lectura en el path del datastore y el namespace correcto. Alinea /etc/pve/storage.cfg entre nodos. Prefiere una identidad “restore-ops” dedicada con alcance controlado.

2) “Fingerprint mismatch” tras mantenimiento de PBS

Síntoma: El cliente se niega a conectar; errores sobre fingerprint de certificado o certificado inválido.

Causa raíz: El certificado de PBS fue regenerado (reinstalación, cambio de hostname), pero los nodos PVE aún confían en el fingerprint antiguo en storage.cfg.

Solución: Actualiza el fingerprint en todos lados. Estandariza la identidad de PBS (hostname estable) y trata la regeneración de certs como un cambio controlado.

3) Restauración falla a mitad con “missing chunk” o errores de verificación

Síntoma: La restauración inicia y luego falla con referencias a chunks faltantes; verify del datastore muestra errores.

Causa raíz: Corrupción en el almacenamiento subyacente, escrituras incompletas, errores de filesystem, discos defectuosos, o un datastore movido/copied incorrectamente (rsync sin xattrs/permisos, inconsistencia de snapshots).

Solución: Detén la carga de escritura, repara la capa de almacenamiento (SMART, RAID, ZFS scrub, fsck donde corresponda), ejecuta verify, identifica el último snapshot conocido bueno y restaura desde allí. Si tienes un datastore replicado, haz failover a él.

4) La restauración “se cuelga” o es extremadamente lenta; las copias están bien

Síntoma: El job de restauración corre pero el progreso es muy lento; iowait se dispara; PBS se siente lento.

Causa raíz: Amplificación de lectura contra almacenamiento lento (latencia NFS, discos SMR, RAID HDD sobrecargado, ZFS afinado para throughput no latencia), o prune/GC/verify ejecutándose concurrentemente.

Solución: Pausa tareas de mantenimiento pesadas durante restauraciones, mide latencia de disco (iostat), y mueve el datastore a almacenamiento diseñado para lecturas aleatorias (SSD, caché apropiada, nivel RAID sensato). Si estás en NFS, revisa opciones de montaje y rendimiento del servidor.

5) “Snapshot existe pero no puede encontrarse” en la UI o CLI

Síntoma: Las copias aparecen en una vista pero no para el flujo de restauración; errores “group not found”.

Causa raíz: Mismatch de namespace, definición de repositorio distinta, o intentar restaurar un backup de VM como CT (o viceversa).

Solución: Confirma --ns y tipo de grupo. Lista snapshots desde el mismo nodo y la misma identidad usada por la restauración.

6) Las restauraciones fallan solo desde un nodo Proxmox

Síntoma: Restauración funciona desde pve02 pero falla desde pve01 con timeouts o errores TLS.

Causa raíz: Deriva en storage.cfg por nodo, reglas de firewall, routing, diferencias DNS o mismatch de MTU en una ruta específica.

Solución: Compara configuraciones. Ejecuta las mismas pruebas de conectividad desde ambos nodos. Estandariza y automatiza la distribución de configuración cuando sea posible.

7) Las restauraciones fallan tras “optimizar” retenciones/GC

Síntoma: Tras cambiar el prune o la retención, las restauraciones antiguas fallan, o las restauraciones se vuelven lentas en horario laboral.

Causa raíz: GC se trasladó a horario pico, o las políticas de prune eliminaron snapshots que asumías aún tenías. A veces “keep-last” funciona hasta que te das cuenta que necesitabas “keep-daily” por cumplimiento.

Solución: Programa GC y verify fuera de horas. Modela políticas de retención según requisitos reales de restauración (RPO/RTO y auditoría), no por ansiedad de uso de disco.

Tres mini-historias corporativas (cómo falla esto en la vida real)

Mini-historia 1: El incidente causado por una suposición equivocada

La empresa tenía un clúster Proxmox limpio y un único appliance PBS en almacenamiento lo suficientemente rápido. Las copias estuvieron verdes durante meses. Nadie se preocupó. Luego un host falló y necesitaron restaurar una VM de producción a un nodo distinto. La restauración falló al instante: permiso denegado.

La suposición equivocada fue sutil: “el token que puede hacer backup también puede restaurar.” Su token de backup estaba muy acotado (buena intención), pero sólo tenía derechos alineados con el flujo de copia. Nunca probaron restauraciones desde un nodo no primario, y el token almacenado en /etc/pve/storage.cfg en los otros nodos era… distinto. Un ingeniero había copiado un snippet de configuración semanas antes y usado un usuario placeholder que no tenía derechos de lectura del datastore.

Perdieron tiempo depurando almacenamiento y red porque los logs de backup parecían perfectos. Mientras tanto, los logs de PBS fueron claros: falta Datastore.Read. Una vez que alinearon la configuración del repositorio entre nodos y crearon un rol de restauración dedicado con ACLs explícitas, las restauraciones funcionaron de inmediato.

El seguimiento fue la solución real: añadieron un simulacro mensual de “restaurar desde un nodo aleatorio” y trataron storage.cfg como configuración que no debe derivar. La marca verde de copia volvió a ser una señal útil, no una mentira reconfortante.

Mini-historia 2: La optimización que salió mal

Otra organización tuvo una semana de recorte de costos. Movieron el datastore de PBS de discos locales a un filer NFS existente porque “son sólo backups”. Las copias siguieron bien: escrituras secuenciales grandes por la noche, dedupe trabajando, nadie se quejaba. Entonces una simulación de ransomware se convirtió en simulación de restauración. Las restauraciones fueron tan lentas que eran funcionalmente inútiles.

El backend NFS tenía buen throughput pero latencia mediocre bajo concurrencia. Las restauraciones lo atacaron con lecturas de chunks mientras el filer también servía directorios home y artefactos de CI. Durante la ventana de restauración, GC también se ejecutó porque alguien reprogramó mantenimiento “para aprovechar que había gente disponible”. Esa decisión transformó una restauración lenta en algo desesperado.

Intentaron afinar opciones de montaje NFS y añadir ancho de banda. Ayudó algo, pero no lo suficiente. El problema subyacente fue físico: las restauraciones chunked y desduplicadas no son carga secuencial, y castigarán latencia y rendimiento de metadatos. Finalmente movieron PBS de nuevo a almacenamiento local con SSD y pusieron GC/verify en horas fuera de producción.

Aprendieron una lección cruel: optimizar para “éxito de backup” no es optimizar para “recuperación del negocio”. Son objetivos relacionados, no idénticos.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un entorno regulado. Mucho proceso. El tipo de lugar donde no puedes simplemente “SSH y ver qué pasa”. El equipo de almacenamiento insistió en pruebas de restauración trimestrales con evidencia: restaurar a una red aislada, validar arranque y comparar checksum de un dataset conocido. Todos refunfuñaron porque era trabajo predecible y nadie se promocionaba por hacerlo.

Un trimestre, la prueba de restauración falló. No catastróficamente: sólo un error de missing chunk en un subconjunto de snapshots. Como la prueba era rutinaria, ocurrió lo suficientemente pronto como para que los datos afectados aún estuvieran disponibles desde un snapshot más antiguo y desde una copia offline. Lo trataron como un incidente de integridad de almacenamiento, no como un fallo aislado.

La causa raíz resultó ser errores intermitentes de disco en el host PBS que aún no habían disparado alarmas obvias. Los contadores SMART subían, pero el sistema “seguía funcionando”. La verificación lo detectó. Las pruebas de restauración demostraron que importaba. Reemplazaron los discos, re-verificaron y documentaron el incidente con lenguaje calmado y acciones claras.

Cuando meses después necesitaron una restauración real de producción, funcionó. Nadie aplaudió. Ese es el punto.

Listas de verificación / plan paso a paso (haz las restauraciones aburridas)

Checklist A: Cuando una restauración falla ahora mismo (triage)

1. Captura el error exacto desde la UI/CLI de restauración y el journal de PBS alrededor de la misma marca temporal.
2. Clasifica: auth/ACL/TLS vs chunks faltantes vs timeout/lento vs errores del almacenamiento objetivo.
3. Confirma identidad: mismo usuario/token/namespace en el nodo que realiza la restauración.
4. Confirma estado del datastore: montado, escribible, sin remount a sólo lectura, sin degradación de pool.
5. Revisa tareas en ejecución: pausa GC/verify si necesitas la restauración rápido.
6. Haz una prueba de bajo riesgo: montaje a nivel de archivos del snapshot (prueba la ruta de lectura) antes de la restauración completa de VM.
7. Si hay errores de integridad: ejecuta datastore verify, determina el radio de daño y elige el último punto de restauración conocido bueno.

Checklist B: Higiene semanal que previene “copias verdes, restauraciones muertas”

1. Ejecuta datastore verify en un cronograma ajustado al tamaño del datastore y la tasa de cambio. Rota snapshots si es necesario.
2. Revisa timing de prune y GC para que nunca compitan con ventanas de restauración o picos productivos.
3. Chequea salud del almacenamiento (SMART, RAID, ZFS scrubs) y alerta por señales tempranas, no sólo por fallos.
4. Estandariza la configuración del repositorio en todos los nodos PVE; trata la deriva como un bug.
5. Realiza un simulacro de restauración (mount + restauración selectiva de archivos + restauración completa de VM trimestral como mínimo).

Checklist C: Decisiones de hardening (lo que yo haría realmente)

• Identidades separadas: un token para trabajos de backup, otro para operaciones de restauración; ambos con menos privilegios pero sin sabotearse mutuamente.
• Preferir datastore local con SSD para PBS si te importa el RTO. NFS puede funcionar, pero debes diseñar para latencia y metadatos, no sólo throughput.
• Usar replicación si el datastore importa: es tu seguro contra corrupción y fallo de un solo host. Las copias que no se pueden restaurar son arte performance.
• Programar verify + GC intencionalmente: fuera de horas y nunca solapándolos con el pico de ingest de backups si puedes evitarlo.
• Documentar el proceso de fingerprint de certificados y tratar las reconstrucciones de PBS como cambios que requieren pasos de re-trust.

Chiste #2: Si tu política de retención es “conservar todo para siempre”, felicidades—has inventado una manera muy cara de evitar tomar decisiones.

Una cita operativa para mantenerte honesto

Todo falla, todo el tiempo. — Werner Vogels

Es corta, no reconforta y es operativamente correcta. Diseña tu práctica de restauración alrededor de ello.

Preguntas frecuentes

1) ¿Por qué pueden tener éxito las copias si el datastore tiene problemas de integridad?

Porque la ruta de copia puede tener éxito aceptando nuevos chunks y escribiendo metadata aun cuando chunks antiguos estén faltantes/corruptos. Las restauraciones a menudo necesitan esos chunks antiguos para reconstruir un snapshot. La verificación y los simulacros de restauración son lo que saca esto a la luz.

2) ¿Cuál es la prueba de restauración más rápida y segura sin sobrescribir una VM?

Usa proxmox-backup-client mount contra un snapshot reciente y explora algunos archivos. Ejercita autenticación, acceso a namespace, lecturas de chunks y descompresión con riesgo mínimo.

3) ¿Es NFS una mala idea para datastores PBS?

No inherentemente, pero es fácil hacerlo mal. Las copias son tolerantes a escritura; las restauraciones son sensibles a latencia. Si tu servidor NFS es compartido, tiene picos de latencia o cachés peculiares, las restauraciones sufrirán primero. Si debes usar NFS, mide rendimiento de restauración bajo carga y programa trabajos de mantenimiento con cuidado.

4) ¿Cómo causan los namespaces problemas de “restauración no encontrada”?

Los namespaces particionan grupos de backup. Si tu nodo PVE está configurado con namespace prod pero las copias fueron escritas al namespace root (u otro), el listado puede diferir y las restauraciones no encontrarán el snapshot donde lo esperas. Confirma siempre con snapshot list usando el mismo --ns.

5) ¿Cuál es la relación entre prune y garbage collection?

Prune elimina referencias a snapshots según retención. Garbage collection recupera chunks no referenciados. Puedes hacer prune agresivo y no recuperar espacio hasta que GC corra. A la inversa, ejecutar GC en mal momento puede dejar sin I/O a restauraciones y copias.

6) Las restauraciones fallan sólo desde un nodo. ¿Qué debo comparar primero?

/etc/pve/storage.cfg (username/token/namespace/fingerprint), resolución DNS (getent hosts), diferencias de routing/firewall y ajustes de MTU. En la práctica, la deriva de configuración por nodo es el culpable más común.

7) ¿Con qué frecuencia debo ejecutar datastore verify?

Con la frecuencia suficiente para detectar corrupción antes de que tu ventana de retención elimine puntos de restauración buenos. En muchos entornos: verify diario o semanal de snapshots recientes, más un verify rodante en snapshots más antiguos. El calendario exacto depende del tamaño del datastore y de la capacidad de rendimiento.

8) ¿Qué significa “missing chunk” usualmente, y puede repararse?

Significa que falta un archivo de chunk referenciado en el datastore, típicamente por pérdida de almacenamiento, corrupción o una migración/copia incompleta. La reparación no es mágica; normalmente restauras desde un snapshot diferente que no referencia el chunk faltante, desde un datastore replicado o desde una copia independiente.

9) ¿Necesito tokens separados para backup y restore?

No los necesitas, pero deberías usarlos. Reduce el radio de impacto y facilita auditoría. Simplemente no limites tanto el token de backup que nadie pueda restaurar bajo presión.

10) ¿Por qué las restauraciones exponen problemas de rendimiento más que las copias?

Las restauraciones desduplicadas son intensivas en lecturas de chunks y pueden generar I/O aleatorio elevado. Las copias tienden a ser más secuenciales y tolerantes. Si tu backend de almacenamiento tiene alta latencia o se satura, las restauraciones serán lo primero en parecer “rotas”.

Siguientes pasos (qué hacer esta semana)

1. Ejecuta un simulacro de restauración desde un nodo no primario: monta un snapshot y luego restaura una VM a una red aislada. Registra los pasos y tiempos.
2. Programa verify y GC intencionalmente: fuera de horas, sin solaparse con la ingest de backups y no durante tu ventana realista de restauración.
3. Audita identidades y ACLs: asegura que la ruta de restauración tenga Datastore.Read y acceso al namespace correcto. Deja de depender de “funcionó para backups”.
4. Mide la latencia de almacenamiento bajo carga tipo restauración: si iostat muestra await feo, trátalo como diseño de almacenamiento, no como bug de PBS.
5. Estandariza la configuración del repositorio: mismo fingerprint, mismas convenciones de namespace, misma gestión de tokens en todos los nodos PVE.

El objetivo final no es “copias exitosas”. El objetivo final es “restauraciones aburridas”. Si puedes restaurar bajo presión, sin heroísmos, has construido algo real.