Proxmox ‘vzdump backup failed’: 10 causas reales y cómo comprobarlas en orden

Guía de diagnóstico rápido (comprobar 1/2/3)

Cuando falla una copia, hay dos objetivos: (1) recuperar una copia exitosa hoy, y (2) evitar que se repita sin convertir la ventana de backup en un proyecto de fin de semana. El camino más rápido suele ser: logs → salud/capacidad del almacenamiento → capacidad de snapshot → transporte (NFS/CIFS/PBS) → permisos/bloqueos.

Comprobación 1: encuentra el punto exacto de fallo en el log

No empieces a “arreglar el almacenamiento” a ciegas. Obtén el primer mensaje de error contundente y el contexto alrededor.

cr0x@server:~$ ls -1t /var/log/vzdump/*.log | head
/var/log/vzdump/qemu-101.log
/var/log/vzdump/lxc-203.log

cr0x@server:~$ tail -n 80 /var/log/vzdump/qemu-101.log
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'nfs'
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: vzdump archive creation failed: write error: No space left on device
INFO: Backup job finished with errors
TASK ERROR: job errors

Decisión: Si ves un error concreto como No space left on device, Permission denied, Input/output error, stale file handle, snapshot failed, detente y sigue esa rama. Si sólo ves ERROR: Backup of VM 101 failed - vma: ... sin causa, salta a la sección “Tareas” abajo y ejecuta las comprobaciones más profundas.

Comprobación 2: confirma que el almacenamiento destino es escribible, está montado y no está lleno

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
local         dir     active       102400000        12233456        90016644    11.94%
backup        nfs     active      2048000000      2039000000         9000000    99.56%
local-lvm     lvmthin active        500000000       310000000       190000000    62.00%

Decisión: Si backup está al 99–100% o muestra espacio disponible anómalo, considéralo lleno. Libera espacio o corrige cuotas/reservas antes de hacer cualquier otra cosa.

Comprobación 3: ¿el fallo está relacionado con snapshots o con transporte?

Los fallos en modo snapshot son estruendosos e inmediatos. Los fallos de transporte (NFS, PBS, discos lentos) suelen parecer timeouts, “broken pipe” o tareas “bloqueadas”.

cr0x@server:~$ grep -E "snapshot|freeze|thaw|qmp|lvm|zfs|ceph|rbd|stale|timeout|broken pipe|i/o error" -i /var/log/vzdump/qemu-101.log | tail -n 30
ERROR: vzdump archive creation failed: write error: No space left on device

Decisión: Las palabras clave de snapshot te dirigen hacia comprobaciones del driver de almacenamiento local (LVM-thin/ZFS/Ceph) y el agente de invitados. Las palabras clave de transporte te llevan a revisar NFS/PBS, la red y la salud/capacidad del servidor destino.

Datos interesantes y contexto (por qué falla así)

• vzdump es anterior a las configuraciones modernas “PBS-first” de Proxmox. Nació como una herramienta de volcado simple y creció hasta convertirse en un motor de flujo de trabajo que coordina snapshots, congelado y archivado.
• Los backups por snapshot son primero una característica del almacenamiento, y segundo de Proxmox. Si el backend no puede snapshotear de forma fiable (o se queda sin espacio de metadatos), vzdump no puede “hacer que funcione”.
• La integración con QEMU guest agent es opcional, pero las consecuencias no lo son. Sin él, obtienes una copia crash-consistent, pero las aplicaciones (bases de datos) pueden quedar en un estado inconsistente.
• VMA es el formato de archivo de VM de Proxmox. Es simple y rápido, pero no hace magia: depende de lecturas estables de los volúmenes de VM y escrituras estables al almacenamiento destino.
• NFS es popular para almacenamiento de copia porque es “fácil”, y por eso también es un punto frecuente de fallo: stale handles, montajes soft, retransmisiones y la síndrome de “ayer funcionó”.
• Los snapshots de ZFS son baratos; los ZFS send no son gratuitos. La explosión de snapshots y la fragmentación del dataset pueden convertir silenciosamente una copia nocturna en un incidente de rendimiento.
• El metadata de LVM-thin es algo separado que puedes llenar. Cuando la metadata thin llega al 100%, no “degradará con gracia”. Se detiene.
• La compresión cambia la forma del I/O. zstd suele ser buena, pero si el nodo está limitado por CPU o el destino es lento, la compresión puede empeorar los timeouts.
• Proxmox usa archivos de bloqueo y logs de tareas para evitar copias dobles. Si un nodo se reinicia a mitad de tarea, esos bloqueos pueden quedar atrás y provocar un fallo de segunda orden.

10 causas reales de “vzdump backup failed” (en el orden en que compruebo)

1) El almacenamiento destino está lleno (o efectivamente lleno por cuotas/reservas)

Este es el culpable aburrido y más frecuente. No siempre es “100% lleno”. Los exports NFS pueden tener cuotas por directorio. Los datasets ZFS pueden tener reservas. Los datastores PBS pueden alcanzar límites de GC de chunks. El síntoma en vzdump suele ser “write error” o “No space left on device”.

Comprobar: usa pvesm status primero, luego verifica en la ruta montada con df -h. Si es NFS, también revisa el lado del servidor. Si es PBS, revisa uso del datastore y ajustes de pruning.

2) El destino de backup no está montado o está mal montado (ruta NFS/CIFS cambiada, carrera de automount)

Si /mnt/pve/backup no es realmente tu share NFS en el momento en que corre el job, vzdump escribe felizmente en el directorio local detrás del punto de montaje (o falla si falta). Así es como “misteriosamente” llenas el disco local mientras las copias “fallan”.

Comprobar: mount, findmnt, y confirma que las opciones de montaje sean sensatas (montaje hard para backups, no soft).

3) La creación del snapshot falla (modo equivocado para el tipo de almacenamiento, o el almacenamiento no puede snapshotear ahora)

Los backups por snapshot requieren cooperación: snapshots LVM-thin, snapshots ZFS o snapshots Ceph RBD. Si estás en storage tipo directory sin soporte de snapshot, el modo snapshot no hará lo que esperas. Si estás en LVM-thin pero la metadata thin está casi llena, los snapshots fallan cuando más los necesitas.

Comprobar: busca errores de “snapshot” en los logs, verifica el tipo de almacenamiento con pvesm status/pvesm config e inspecciona la salud de LVM-thin/ZFS/Ceph.

4) Bloqueo atascado o estado de tarea residual bloquea el job

Perdida de energía, reboot del nodo, fallo de almacenamiento—cualquier cosa que interrumpa una copia puede dejar bloqueos. Entonces la siguiente ejecución falla inmediatamente con errores de “locked”. Proxmox intenta proteger los discos de VM de backups concurrentes; te está haciendo un favor, aunque ruidoso.

Comprobar: lista de tareas y archivos de bloqueo; también verifica que la VM no esté realmente ejecutando ya una copia.

5) Inestabilidad del transporte NFS/CIFS (stale file handles, mapeo de permisos, timeouts)

Los fallos NFS rara vez son educados. Obtendrás “stale file handle”, “permission denied”, “input/output error” o “server not responding”. CIFS/SMB trae su propio repertorio de problemas: rotación de credenciales, quirks de dialecto y comportamientos extraños de locking.

Comprobar: logs del kernel (dmesg), opciones de montaje, retransmisiones y logs del servidor. Si tu red pierde paquetes, tu sistema de backups se convierte en un DDoS distribuido contra tu paciencia.

6) Problemas en el datastore PBS (permisos, datastore lleno, pruning/GC lento, fallos de verificación)

Respaldar a Proxmox Backup Server suele ser más robusto que shares simples, pero igualmente fallan: datastore lleno, desajuste de namespace/permiso, token expirado o contención de verificación/GC durante las ventanas de backup.

Comprobar: los logs del nodo Proxmox mostrarán errores de autenticación/HTTP; PBS mostrará errores del datastore y del chunk store. No adivines: confirma en el lado de PBS.

7) Problemas con QEMU Guest Agent / freeze-thaw que causan bloqueo o timeout del snapshot

Cuando pides un snapshot consistente, Proxmox usa QEMU guest agent para congelar los sistemas de archivos. Si el agente falta, está viejo o está colgado, puedes ver timeouts de freeze. Si lo fuerzas, podrías obtener backups que “funcionan” pero restauraciones que dañan datos.

Comprobar: estado de QMP/agent, busca mensajes de “fsfreeze” y confirma el servicio del agente dentro del guest.

8) Errores de lectura en el almacenamiento de los discos VM (errores checksum ZFS, Ceph degradado, SSD fallando)

Una copia lee cada bloque asignado. Por eso las copias suelen detectar almacenamiento defectuoso antes que los usuarios. Si las lecturas fallan, vzdump aborta. El verdadero culpable está debajo de Proxmox: errores ZFS, mdadm, sectores pendientes SMART o problemas de PG en Ceph.

Comprobar: ZFS zpool status, datos SMART, salud de Ceph y errores I/O en el kernel.

9) Cuellos de botella de rendimiento (CPU, IO wait, ventana de backup pequeña) causan timeouts o solapamiento de jobs

Los backups que fallan por “timeout” suelen ser un problema de programación disfrazado. Tu throughput de backup es menor que tu tasa de cambio y tratas de encajarlo en una ventana que no encaja.

Comprobar: latencia I/O, carga del nodo, tendencia de duración de backups y si los jobs se solapan. Luego arregla el calendario, la concurrencia o el almacenamiento, no el mensaje del log.

10) Fallos en la tubería VMA/compresión (broken pipe, espacio tmp, presión de hilos zstd)

vzdump canaliza datos a través de herramientas (vma, compresión, posiblemente cifrado según destino). Si la tubería se rompe—la escritura destino se queda, un proceso es matado por OOM, tmp se llena—verás “broken pipe”, “killed” o códigos de salida genéricos.

Comprobar: journal de systemd para OOM kills, RAM libre, actividad de swap y el log del backup alrededor del inicio de la compresión.

Chiste #1: Las copias son como los paracaídas—si lo necesitas y no se abre, tendrás un postmortem muy corto.

Tareas prácticas: comandos, significado de la salida y decisiones

Estos son deliberadamente prácticos. Ejecútalos en orden hasta encontrar el “primer error real”. Los fragmentos de salida son representativos; tus cadenas exactas variarán. Lo importante es la decisión que tomes después.

Tarea 1: Identifica rápidamente el job fallido y la VM/CT

cr0x@server:~$ grep -R "TASK ERROR" -n /var/log/vzdump/ | tail -n 5
/var/log/vzdump/qemu-101.log:68:TASK ERROR: job errors
/var/log/vzdump/lxc-203.log:55:TASK ERROR: job errors

Qué significa: Tienes logs por invitado. No te quedes mirando el resumen del GUI; abre el log específico del invitado que falló.

Decisión: Elige el log de fallo más reciente y trabájalo hasta la evidencia antes de perseguir fallos secundarios.

Tarea 2: Extrae la primera línea ERROR y las 30 líneas antes

cr0x@server:~$ awk 'BEGIN{e=0} /ERROR:/{e=NR} {a[NR]=$0} END{for(i=e-30;i<=e+5;i++) if(i>0) print a[i]}' /var/log/vzdump/qemu-101.log
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'nfs'
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: vzdump archive creation failed: write error: No space left on device
INFO: Backup job finished with errors

Qué significa: El primer error significativo suele ser el único que importa.

Decisión: Si está relacionado con escritura destino, detente y arregla capacidad/montaje/permisos antes de tocar parámetros de snapshot.

Tarea 3: Verifica que Proxmox considera activo el almacenamiento de backup

cr0x@server:~$ pvesm status --storage backup
Name    Type  Status  Total        Used        Available   %
backup  nfs   active  2048000000   2039000000  9000000     99.56%

Qué significa: “active” sólo significa “montado” y “respondiendo ahora”. No significa “tiene espacio” ni “es suficientemente rápido”.

Decisión: Si el espacio disponible es mínimo, prunea backups antiguos o expande. Si los totales parecen erróneos (por ejemplo 0), sospecha problema de montaje.

Tarea 4: Confirma que el montaje es real (y no un directorio local)

cr0x@server:~$ findmnt -T /mnt/pve/backup
TARGET         SOURCE               FSTYPE OPTIONS
/mnt/pve/backup 10.10.0.20:/exports/pve-backup nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Qué significa: Si SOURCE está en blanco o parece un dispositivo local, no estás montado donde crees.

Decisión: Si no está montado, no ejecutes más backups. Arregla el montaje y limpia cualquier “backup local accidental” que haya llenado tu nodo.

Tarea 5: Mide el espacio libre real donde vzdump escribe

cr0x@server:~$ df -h /mnt/pve/backup
Filesystem                      Size  Used Avail Use% Mounted on
10.10.0.20:/exports/pve-backup  2.0T  2.0T  9.0G 100% /mnt/pve/backup

Qué significa: Terminaste el diagnóstico. Está lleno.

Decisión: Prunea backups, mueve algunos fuera o expande. Luego vuelve a ejecutar una copia manual para comprobar.

Tarea 6: Comprueba sorpresas de cuota/reserva (común en NFS respaldado en ZFS)

cr0x@server:~$ zfs get -o name,property,value,source quota,reservation,refquota,refreservation tank/pve-backup
NAME            PROPERTY         VALUE  SOURCE
tank/pve-backup quota            2T     local
tank/pve-backup reservation      none   default
tank/pve-backup refquota         none   default
tank/pve-backup refreservation   none   default

Qué significa: Una cuota en el dataset puede hacer que un filesystem “esté lleno” mientras el pool tiene espacio libre.

Decisión: Si la cuota del dataset es estricta, amplíala o implementa pruning que respete la retención.

Tarea 7: Detecta errores de transporte NFS en los logs del kernel

cr0x@server:~$ dmesg -T | egrep -i "nfs|stale|server not responding|timed out|rpc" | tail -n 20
[Thu Dec 26 02:05:11 2025] NFS: server 10.10.0.20 not responding, still trying
[Thu Dec 26 02:05:44 2025] NFS: server 10.10.0.20 OK

Qué significa: Tu “problema de almacenamiento” puede ser en realidad pérdida de paquetes, congestión o un NAS saturado.

Decisión: Si ves esto durante las ventanas de backup, trata la red y el rendimiento del servidor NFS como dependencias de primer orden del backup.

Tarea 8: Detecta jobs vzdump atascados o solapados

cr0x@server:~$ pgrep -a vzdump
21984 /usr/bin/perl /usr/bin/vzdump 101 --storage backup --mode snapshot --compress zstd

cr0x@server:~$ pvesh get /nodes/$(hostname)/tasks --limit 5
┌──────────────┬───────────────────────────────┬───────────┬──────────┬─────────┬──────────────┐
│ upid         │ starttime                     │ type      │ status   │ user    │ id           │
╞══════════════╪═══════════════════════════════╪═══════════╪══════════╪═════════╪══════════════╡
│ UPID:node... │ 2025-12-26T02:00:01Z          │ vzdump    │ running  │ root@pam│ 101          │
└──────────────┴───────────────────────────────┴───────────┴──────────┴─────────┴──────────────┘

Qué significa: El job sigue en ejecución; un email de “fallo” puede haber sido de otro invitado o un intento anterior.

Decisión: Si está realmente atascado (sin progreso, almacenamiento congelado), puede que tengas que detener la tarea y limpiar bloqueos con cuidado.

Tarea 9: Comprueba bloqueos de backup en el invitado

cr0x@server:~$ qm config 101 | egrep -i "lock|backup"
lock: backup

Qué significa: Proxmox cree que hay una copia en progreso (o fue interrumpida).

Decisión: Confirma que ningún proceso vzdump está trabajando realmente. Si no, elimina el bloqueo.

cr0x@server:~$ qm unlock 101
OK

Tarea 10: Verifica la capacidad de snapshot y el tipo de almacenamiento para los discos de la VM

cr0x@server:~$ qm config 101 | egrep -i "scsi|virtio|ide|sata"
scsi0: local-lvm:vm-101-disk-0,size=80G

cr0x@server:~$ pvesm status --storage local-lvm
Name      Type    Status  Total       Used       Available  %
local-lvm lvmthin active  500000000   310000000  190000000  62.00%

Qué significa: LVM-thin soporta snapshots, pero sólo mientras la metadata thin esté sana.

Decisión: Si estás en dir storage (no LVM-thin/ZFS/Ceph) y exiges modo snapshot, espera decepciones.

Tarea 11: Comprueba el uso de metadata de LVM-thin (el asesino silencioso de snapshots)

cr0x@server:~$ lvs -a -o+seg_monitor,metadata_percent,lv_size,data_percent vg0
  LV                VG   Attr       LSize   Pool     Data%  Meta%  Monitor
  data              vg0  twi-aotz--  465.76g          68.12  98.77  monitored

Qué significa: Meta% en ~99% es alerta roja. Snapshots y asignaciones pueden fallar de forma abrupta.

Decisión: Extiende la LV de metadata thin (si está diseñada para eso) o reduce la churn. No “esperes a que se recupere”; no lo hará.

Tarea 12: Comprueba la salud del pool ZFS si los discos VM están en ZFS

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
  scan: scrub repaired 0B in 00:12:44 with 2 errors on Thu Dec 26 01:10:02 2025
config:
        NAME        STATE     READ WRITE CKSUM
        rpool       DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     2

Qué significa: Los errores de checksum durante un scrub no son “sólo una advertencia”. Las copias que leen todo probablemente tropezarán con la misma corrupción.

Decisión: Sustituye/arregla el dispositivo que falla, restaura los datos afectados desde copias buenas conocidas y sólo entonces confía en las copias nuevamente.

Tarea 13: Comprueba la salud de Ceph si usas RBD

cr0x@server:~$ ceph -s
  cluster:
    id:     2c1b2d24-aaaa-bbbb-cccc-6f4f3b2d1b2a
    health: HEALTH_WARN
            Degraded data redundancy: 12/3456 objects degraded
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   3 pools, 256 pgs
    objects: 1.15M objects, 4.2 TiB
    usage:   12 TiB used, 18 TiB / 30 TiB avail
    pgs:     10 degraded, 5 undersized

Qué significa: PGs degradados/undersized pueden hacer que los snapshots sean lentos o fallen, y las lecturas pueden bloquearse.

Decisión: Arregla la salud de Ceph primero. “Hacer más backups” no es una estrategia de reparación de almacenamiento.

Tarea 14: Confirma el estado del agente invitado (para freeze/thaw y mayor consistencia)

cr0x@server:~$ qm agent 101 ping
QEMU guest agent is running

cr0x@server:~$ qm agent 101 fsfreeze-status
thawed

Qué significa: El agente es accesible y puede informar el estado de congelado del sistema de archivos.

Decisión: Si los comandos del agente fallan, arregla el agente dentro de la VM o ajusta expectativas (backup crash-consistent). No finjas que obtienes snapshots consistentes a nivel de aplicación.

Tarea 15: Detecta OOM kills o procesos de compresión asesinados

cr0x@server:~$ journalctl -k --since "2025-12-26 01:50" | egrep -i "oom|killed process" | tail -n 20
Dec 26 02:03:22 node kernel: Out of memory: Killed process 22311 (zstd) total-vm:8123456kB, anon-rss:2147488kB, file-rss:0kB, shmem-rss:0kB

Qué significa: La tubería de backup murió porque el kernel necesitaba memoria más que tu backup.

Decisión: Reduce nivel/threads de compresión, escalona jobs, añade RAM o mueve la compresión fuera del nodo (PBS puede ayudar). Si no, seguirás “fallando con éxito” cada noche.

Tarea 16: Prueba el throughput de escritura al almacenamiento destino (no hagas benchmark eternamente)

cr0x@server:~$ dd if=/dev/zero of=/mnt/pve/backup/.pve-write-test bs=16M count=128 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18 s, 119 MB/s
128+0 records in
128+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18.0832 s, 119 MB/s

cr0x@server:~$ rm -f /mnt/pve/backup/.pve-write-test

Qué significa: Si ves MB/s de un dígito en un sistema que antes hacía 200 MB/s, tu “backup failed” es una regresión de rendimiento.

Decisión: Arregla la red, el NAS o la contención. O ajusta la concurrencia de backups para que tu ventana sea realista.

Tarea 17: Ejecuta un backup manual de un invitado con máxima verbosidad y mínima concurrencia

cr0x@server:~$ vzdump 101 --storage backup --mode snapshot --compress zstd --notes-template '{{guestname}} {{vmid}}' --stdout 0
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd --notes-template {{guestname}} {{vmid}} --stdout 0
INFO: issuing guest-agent 'fsfreeze-freeze'
INFO: creating snapshot 'vzdump'
INFO: starting kvm to execute backup task
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-03_10_01.vma.zst'
INFO: issuing guest-agent 'fsfreeze-thaw'
INFO: archive file size: 14.32GB
INFO: Finished Backup of VM 101 (00:05:54)
INFO: Backup job finished successfully

Qué significa: Una ejecución controlada te dice si el problema es sistémico o debido a concurrencia/horario.

Decisión: Si manual funciona pero el job nocturno falla, arregla la programación, la contención de almacenamiento o los parámetros de job—no la VM.

Chiste #2: Lo único más fiable que un job de backup que falla es el asunto del email que dice que falló “con éxito”.

Tres micro-historias del mundo corporativo (anónimas y plausibles)

Micro-historia 1: La suposición equivocada (NFS es “sólo un disco”)

Tenían un cluster Proxmox que soportaba apps internas: runners de CI, algunas bases de datos y un montón de VMs “temporales” que llevaban tres años siendo temporales. Las copias iban a un share NFS en un appliance NAS. Nada exótico. Funcionó hasta que dejó de hacerlo.

La suposición era simple: “Si el storage sale activo, está montado, así que los backups llegan al NAS.” Eso casi es verdad. El fallo fue que el share NFS fallaba ocasionalmente al montar en el arranque por un problema de orden de dependencias, dejando /mnt/pve/backup como un directorio local vacío. El job de backup se ejecutó, escribió localmente y luego falló cuando el local se llenó. Algunas noches “funcionó” (escribió localmente y no llenó). Otras noches falló. El NAS parecía inocente todo el tiempo.

El ingeniero on-call persiguió al NAS durante una semana: firmware, discos, carga, red. Mientras tanto, el almacenamiento local en un nodo se llenó silenciosamente con archivos parciales .vma.zst. La pista real estaba en los logs: “filesystem type on dumpdir is ‘ext4’” las noches malas y “nfs” las noches buenas. Decía la verdad; nadie escuchó.

La solución no fue ingeniosa: asegurar el orden de montaje (dependencias de systemd), añadir monitorización que alerte si el almacenamiento de backup no es del tipo de filesystem esperado, y hacer que el job falle pronto cuando el montaje no esté presente. También limpiaron los “backups fantasma” locales y añadieron retención para que el NAS no llegara nunca al 99%.

La lección: trata el almacenamiento en red como una dependencia de red, no como un directorio que funciona hoy.

Micro-historia 2: La optimización que salió mal (la compresión se convirtió en un DoS)

Otra organización quiso reducir costos de almacenamiento. Alguien activó zstd con un nivel más alto y permitió múltiples jobs vzdump concurrentes. En pruebas se veía bien: un backup de VM se encogía y no tardaba mucho más. Todos se fueron a casa satisfechos.

En producción, el nodo tenía una mezcla de cargas. Durante la ventana de backup, la CPU se disparó, el IO wait subió y servicios sensibles a la latencia empezaron a fallar. Los backups comenzaron a fallar con “broken pipe” y mensajes ocasionales de “killed process”. En las peores noches, el OOM killer del kernel mató el proceso de compresión. En las segundas peores, mató algo más interesante.

La optimización se basó en un modelo mental erróneo: “la compresión ahorra I/O, así que siempre es más fácil para el sistema.” La compresión ahorra bytes en la red y disco, pero cuesta CPU y ancho de banda de memoria. Si tu destino es lento, puede que estés bien. Si tu destino es rápido y el nodo ya está ocupado, la compresión sólo añade carga.

La solución fue reducir la concurrencia, bajar la compresión a un nivel sensato y programar invitados pesados por separado. También movieron más backups a PBS donde el chunking y la deduplicación cambiaron la economía, y el nodo dejó de hacer tanto trabajo caro durante picos.

La lección: la configuración “óptima” es la que termina de forma fiable sin dañar producción. Los archivos más pequeños son monos; las restauraciones estables mantienen el empleo.

Micro-historia 3: La práctica aburrida que salvó el día (scrubs, chequeos SMART y restores de prueba)

Este equipo ejecutaba Proxmox con ZFS. Nada llamativo: SSDs en mirror para el OS y un pool mayor para almacenamiento de VM. Eran aburridos en el mejor sentido: scrubs semanales, chequeos SMART y un drill de restauración mensual a una red aislada. Al todo el mundo le desagradaba el drill. Llevaba tiempo. Generaba tickets. Requirió atención. También fue la razón por la que no tuvieron un informe de incidente con la palabra “arrepentimiento”.

Un viernes, las copias empezaron a fallar para una VM específica con un error de lectura genérico. La aplicación seguía funcionando. Los usuarios felices. El on-call podría haber apagado las alertas hasta el lunes. En cambio, comprobaron zpool status y vieron errores de checksum. Un scrub confirmó un par de bloques malos en un SSD. No había luces rojas, ni fallo dramático—sólo señales tempranas.

Sustituyeron el dispositivo durante una ventana planificada. Luego ejecutaron el drill de restauración antes de lo previsto: restauraron la copia de la noche anterior en el sandbox, la arrancaron y validaron la salud básica de la aplicación. Funcionó. Eso confirmó la cadena de backups y el procedimiento de recuperación, no sólo la existencia de archivos de copia.

La práctica aburrida valió dos veces: primero por detectar degradación antes de que fuera pérdida de datos, y segundo por probar que las copias eran realmente restaurables. No teóricamente restaurables. No “debería estar bien”. Restaurables.

Una cita (idea parafraseada): Werner Vogels (CTO de Amazon) enfatiza que deberías “diseñar para el fallo” en lugar de asumir que los componentes no se romperán. (idea parafraseada)

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

1) “Almacenamiento activo” pero los backups llenan el disco local

Sintomas: uso de disco local sube; almacenamiento de backup aparenta estar bien; logs de vzdump mencionan ext4 en lugar de nfs; los archivos aparecen bajo /mnt/pve/backup pero esa ruta es local.

Causa raíz: el destino de backup no estaba montado, o el montaje falló de forma transitoria; el directorio existía localmente.

Solución: forzar dependencias de montaje, alertar en caso de mismatch de tipo de filesystem usando findmnt, y hacer que el backup falle pronto si falta el montaje. Limpiar los archivos locales accidentales.

2) El modo snapshot falla solo para ciertos invitados

Sintomas: “snapshot failed” o “unable to create snapshot” para una VM; otras tienen éxito.

Causa raíz: ese invitado tiene un disco en un storage que no hace snapshots (por ejemplo directory), o tiene una configuración no soportada (por ejemplo mapeo de dispositivo raw), o la metadata thin se agotó en el momento de crear el snapshot.

Solución: mueve discos a almacenamiento con snapshot, arregla presión de metadata LVM-thin; verifica config con qm config y el tipo de storage.

3) “stale file handle” en NFS durante la copia

Sintomas: vzdump falla durante la escritura; logs del kernel muestran stale handle; a veces se arregla con remount.

Causa raíz: el export cambió, el servidor se reinició, el filesystem subyacente fue re-exportado o mantenimiento agresivo en el NAS. A veces se dispara al snapshotear el filesystem exportado en el NAS.

Solución: estabiliza los exports; evita cambiar raíces de export; usa montajes hard; coordina snapshots/mantenimiento del NAS fuera de la ventana de backups; remonta y reintenta.

4) “Permission denied” aunque el share sea escribible desde shell

Sintomas: puedes touch un archivo manualmente, pero vzdump falla al crear su archivo.

Causa raíz: root-squash en NFS, propiedad incorrecta en el directorio destino, o el job escribe en un subdir con permisos distintos.

Solución: verifica opciones de export en el servidor; corrige propiedad/permisos en el directorio de dump; usa mapeo UID/GID consistente.

5) Código de salida 1 con “broken pipe”

Sintomas: el log menciona “broken pipe” durante la compresión o creación del archivo.

Causa raíz: el escritor downstream murió: el almacenamiento destino se quedó, se desconectó, sin espacio o el proceso fue matado (OOM).

Solución: busca OOM kills; revisa logs y espacio del almacenamiento destino; reduce compresión o concurrencia; arregla el transporte inestable.

6) Las copias terminan pero las restauraciones son lentas o fallan verificación

Sintomas: backups completan, pero las restauraciones tardan una eternidad o fallan checks/verification (común en PBS si el datastore está degradado).

Causa raíz: degradación del almacenamiento subyacente, problemas en el chunk store, o corrupción silente detectada más tarde.

Solución: verifica la salud del datastore regularmente; ejecuta scrubs/SMART; realiza restores de prueba periódicos.

7) Los backups time out solo en horas de trabajo

Sintomas: los jobs cuelgan/encallan; NFS “server not responding”; picos de latencia en Ceph; spikes de IO wait.

Causa raíz: contención. Los backups compiten con carga de producción en el mismo almacenamiento/red.

Solución: mueve backups a fuera de pico, limita concurrencia, aísla tráfico de backup o mejora el cuello de botella (a menudo red o CPU del NAS).

Listas de verificación / plan paso a paso

Paso a paso: consigue que la copia de esta noche tenga éxito

1. Abre el log específico: /var/log/vzdump/qemu-<vmid>.log o lxc-<ctid>.log. Encuentra el primer ERROR: significativo.
2. Confirma el almacenamiento destino: pvesm status y df -h /mnt/pve/<storage>.
3. Valida la realidad del montaje: findmnt -T /mnt/pve/<storage>. Si no es el fstype/source esperado, detente y arregla eso primero.
4. Libera espacio rápido si hace falta: borra o mueve backups antiguos según tu política de retención. No hagas “rm -rf todo” a menos que te guste cambiar de trabajo.
5. Comprueba bloqueos: qm config <vmid> busca lock: backup; elimina con qm unlock sólo después de verificar que no hay job en ejecución.
6. Si hay errores de snapshot: verifica metadata LVM-thin (lvs ... metadata_percent) o la salud ZFS/Ceph.
7. Ejecuta un backup manual: vzdump <vmid> --storage ... --mode snapshot para probar la solución. No esperes al job programado a que “quizá” funcione.
8. Documenta la causa: una línea: “Backup falló por X; verificado por Y; arreglado por Z; validado por backup manual.” Tu yo futuro te invitará un café.

Paso a paso: evitar repeticiones (reducir probabilidad de fallo)

1. Margen de capacidad: mantén los destinos de backup por debajo del ~80–85% de uso. Por encima de eso, todo se vuelve frágil: fragmentación, presión de GC, sorpresas de cuota.
2. Haz sonoros los fallos de montaje: monitoriza findmnt y alerta si cambia el source/fstype del almacenamiento de backup.
3. Controla la concurrencia: menos backups paralelos suele significar más éxito total. Ajusta para finalización, no para throughput teórico.
4. Separa invitados pesados: programa DB grandes o servidores de archivos en su propia ventana. Dominan el I/O y hacen que los demás parezcan culpables.
5. Rutinas de salud de almacenamiento: cadencia de scrubs ZFS; monitor SMART; gating de salud de Ceph. Las copias no deberían ser tu primera señal de fallo de disco.
6. Pruebas periódicas de restauración: demuestra que puedes restaurar y arrancar, no sólo que puedes escribir archivos.

Hoja de trampa de orden de operaciones (lista imprimible)

1. ¿El log muestra espacio/permiso/IO? Arregla exactamente eso primero.
2. Verifica que el montaje sea real y estable (NFS/CIFS/PBS).
3. Comprueba la capa de snapshot (LVM-thin meta%, ZFS pool, salud Ceph).
4. Revisa bloqueos y jobs atascados.
5. Comprueba regresión de rendimiento (dd test + dmesg + iostat si lo usas).
6. Vuelve a ejecutar un backup manual para confirmar.

FAQ

1) ¿Dónde están los logs reales de vzdump en Proxmox?

Mira en /var/log/vzdump/. Normalmente hay un log por invitado por ejecución (por ejemplo qemu-101.log, lxc-203.log). La vista de tareas del GUI es un resumen, no toda la historia.

2) ¿Por qué vzdump dice “backup failed” cuando el archivo de archivo existe?

Porque crear un archivo no es la definición de éxito. El job puede fallar después de escribir (paso de verificación, finalización, flush, permisos en archivos temporales o hooks post-backup). Revisa el final del log para el error final y si el tamaño del archivo parece coherente.

3) ¿Debo usar modo snapshot o stop?

El modo snapshot es el predeterminado por una razón: evita downtime. Usa stop mode para invitados que no se pueden snapshotear de forma segura (raro) o cuando el almacenamiento no puede snapshotear de forma fiable y necesitas una copia limpia más que uptime.

4) ¿Qué significa “lock: backup” y es seguro desbloquear?

Significa que Proxmox cree que hay una copia en progreso o que fue interrumpida. Desbloquear es seguro sólo después de confirmar que no hay ningún proceso vzdump en ejecución para ese invitado y que no hay una operación de snapshot en el storage todavía activa. Si no, arriesgas estado inconsistente.

5) ¿Cómo sé si NFS es el problema versus disco local?

Dos señales rápidas: findmnt -T /mnt/pve/backup (¿está montado desde el servidor correcto?) y dmesg -T para errores NFS durante la ventana del backup. Si el tipo de filesystem es incorrecto en el log de vzdump, no es NFS—estás escribiendo localmente.

6) ¿Por qué las copias revelan corrupción de almacenamiento antes que los usuarios la noten?

Los backups leen de forma amplia y secuencial los discos VM. Las cargas regulares pueden tocar sólo regiones calientes y nunca encontrar un bloque malo hasta meses después. La copia es una prueba de integridad accidental—no desperdicies esa señal.

7) ¿La compresión más alta siempre es mejor para backups?

No. Mayor compresión puede reducir uso de almacenamiento y red, pero aumenta carga de CPU y presión de memoria, y puede hacer que jobs largos se solapen. Elige una configuración que termine de forma fiable dentro de tu ventana.

8) ¿Qué pasa si los backups a PBS fallan pero los NFS funcionan (o viceversa)?

Normalmente apunta al lado destino: problemas de autenticación/token, datastore lleno, contención de verificación/GC en PBS, o problemas de export/permiso en NFS. Divide el sistema: confirma la red nodo→destino y luego revisa la salud y logs del destino.

9) ¿Cómo demuestro una solución sin esperar hasta mañana?

Ejecuta un backup manual de un invitado representativo inmediatamente después del cambio. Si el job nocturno fallaba por concurrencia, ejecuta dos en paralelo y observa si vuelve el fallo. La evidencia vence a la esperanza.

10) ¿Cuál es el hábito más efectivo para la fiabilidad de backups?

Probar restauraciones con regularidad. No una vez. No después de un incidente. A propósito, rutinariamente. Las copias son tan reales como tu última restauración exitosa.

Conclusión: siguientes pasos que realmente reducen el ruido del pager

Cuando Proxmox dice “vzdump backup failed”, no es que sea críptico; te está diciendo que el fallo ocurrió en una cadena de dependencias. La solución más rápida es identificar el primer error concreto en el log por invitado, validar que el almacenamiento destino es real y escribible, luego comprobar la capacidad de snapshot y la salud del almacenamiento antes de tocar perillas de ajuste.

Haz esto a continuación, en este orden:

1. Añade una comprobación de saneamiento del montaje (tipo de filesystem y source) antes de que corran los backups, y alerta si cambia.
2. Impone margen de capacidad en almacenamiento de backup (retención/pruning, cuotas claras y una política de “parar al 85%”).
3. Audita la preparación de snapshots (porcentaje metadata LVM-thin, salud de pools ZFS, salud de Ceph) y bloquea backups si la plataforma está degradada.
4. Adecua concurrencia y compresión para que los jobs terminen de forma fiable. Tu ventana de backup es un presupuesto; no te lo pases.
5. Programa drills de restauración y trátalos como alarmas de incendio: molestos, necesarios y la diferencia entre un evento controlado y un desastre.