Copias Proxmox a PBS fallan: errores comunes de fragmentos/espacio y qué hacer

enero 15, 2026 • febrero 3, 2026 • Lectura: 26 min • Views: 8

¿Te fue útil?

Programaste las copias, viste que las primeras funcionaron y mentalmente archivaste todo como “resuelto”.
Luego una prueba de restauración (o, peor, un incidente real) revela que las copias han estado fallando durante días con mensajes sobre
fragmentos, espacio, bloqueos o “EOF inesperado”. Esto es el equivalente en backups a descubrir que el detector de humo estuvo pitando
en un edificio vacío.

Proxmox Backup Server (PBS) es ingeniería sólida, pero es un sistema de almacenamiento con sus propias reglas: fragmentos deduplicados, índices, snapshots,
recolección de basura y un datastore que aplica la física sin piedad. Cuando las copias fallan, normalmente te enfrentas a una de
cuatro realidades: falta de espacio, falta de inodos, comportamiento defectuoso del almacenamiento o una inconsistencia de metadatos/índice. El truco es identificar cuál
rápidamente y actuar sin empeorar la situación.

Cómo se ven realmente las fallas de PBS (y por qué confunden)

Los mensajes de error de PBS suelen mencionar “fragmentos”, “índices”, “catálogo”, “snapshot”, “datastore” o “verificación”.
Si vienes de backups estilo copia de ficheros, esto se siente innecesariamente abstracto. En PBS, el flujo de backup se corta en
fragmentos (de tamaño variable), se hashea y se deduplica. Los metadatos (índices) mapean la imagen VM/CT a esos fragmentos. Datos y metadatos
son ambos necesarios para una restauración.

Así que puedes tener fallas en al menos cinco capas:

Transporte/autenticación: PVE no puede autenticar con PBS, o TLS falla.
Repositorio/datastore: ruta no escribible, datastore bloqueado, permisos incorrectos.
Capacidad: bytes, inodos o restricciones de “espacio reservado” detienen escrituras a mitad de flujo.
Integridad del almacenamiento: el disco subyacente devuelve errores de E/S, o el sistema de ficheros empieza a mentir.
Desajuste índice/fragmento: fragmento ausente, índice corrupto, fallos de verificación.

Tu trabajo como adulto de guardia es identificar primero la restricción más estrecha. No persigas el mensaje;
persigue el cuello de botella que hace que el mensaje sea inevitable.

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

Si tienes diez minutos antes de la próxima reunión furiosa, haz esto en orden. Está optimizado para “lo que más se rompe” y
“lo que puedes confirmar más rápido”, no para elegancia.

1) Comprobación de realidad de capacidad: bytes, inodos y salud del pool

En PBS: comprueba espacio libre (df -h) e inodos (df -i) en el punto de montaje del datastore.
Si es ZFS: revisa zpool list, zpool status y uso de datasets (zfs list).
Busca condiciones del 80–90% de uso. En sistemas copy-on-write, ahí es donde el rendimiento y la fragmentación se ponen duros.

2) Identifica rápidamente el trabajo que falla y la clase de error

En PVE: lee el log del trabajo en la UI, pero confirma con journalctl para contexto y marcas temporales.
En PBS: lee journalctl -u proxmox-backup. La misma falla puede mostrar causas más claras en el servidor.
Decide: ¿es espacio, permiso/bloqueo, E/S o integridad índice/fragmento?

3) Deja de empeorar la situación: pausa trabajos, protege lo que está bien

Si el datastore está casi lleno: detén los trabajos de backup, ejecuta prune/GC deliberadamente y no inicies “verificación de todo” ahora mismo.
Si el pool está degradado o muestra errores de checksum: detén escrituras, repara hardware y luego verifica.
Si es un lío de bloqueos/permisos: limpia bloqueos obsoletos con cuidado (no borrando archivos al azar), y vuelve a ejecutar un único trabajo.

Una verdad operativa: cuando te quedas sin espacio, todo parece corrupción. Cuando estás corrupto, todo parece espacio.
Tu trabajo es separar ambas cosas.

Hechos interesantes y contexto (lo que explica las rarezas)

Backups deduplicados no son “archivos más pequeños”. PBS almacena datos como fragmentos referenciados por índices. El uso de espacio depende de la reutilización de fragmentos, no del tamaño de archivo.
El chunking está definido por el contenido. Como en sistemas clásicos de deduplicación, PBS divide datos según hashes rodantes, lo que ayuda a deduplicar incluso cuando los bloques se desplazan.
La “verificación” es una característica de primera clase. Muchas pilas de backup tratan las comprobaciones de integridad como opcionales y rara vez las ejecutan. PBS espera que verifiques.
La recolección de basura es separada del prune. Prune elimina referencias a snapshots; GC recupera fragmentos no referenciados. La gente olvida el segundo paso.
Los sistemas CoW odian estar al 95%. ZFS y btrfs necesitan espacio para metadata y asignaciones; “df dice 5% libre” no es tranquilizador.
El agotamiento de inodos todavía existe. Puedes tener terabytes libres y aun así fallar escrituras si el sistema de ficheros se queda sin inodos (especialmente con muchos archivos pequeños y ciertos diseños de FS).
Las copias de seguridad estresan rutas de E/S distintas a producción. Lecturas secuenciales de discos de VM más escrituras aleatorias al datastore pueden sacar a la luz bugs de controladoras/firmware que la carga normal no muestra.
La corrupción silenciosa es algo que hay que asumir. Los sistemas modernos de backup asumen que el bit rot ocurre; los checksums y la verificación existen porque los discos a veces mienten.
La mayoría de problemas de “PBS lento” son por el layout de almacenamiento. ashift equivocado, recordsize pequeño o un solo HDD intentando comportarse como array harán que PBS parezca culpable.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales que puedes ejecutar hoy. Cada una incluye: un comando, qué significa la salida típica y la decisión que tomas.
Ejecuta comandos en el host correcto (PVE vs PBS). No uses opciones destructivas improvisadas hasta identificar la clase de fallo.

Task 1: Confirmar ruta de montaje del datastore y espacio libre (PBS)

cr0x@pbs:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda2      ext4   917G  812G   59G  94% /
tmpfs          tmpfs   32G     0   32G   0% /dev/shm

Significado: 94% usado es zona de peligro para escrituras de backup y tareas de mantenimiento del sistema de ficheros.
Decisión: detener o escalonar trabajos, ejecutar prune/GC y liberar espacio antes de relanzar backups grandes.

Task 2: Comprobar uso de inodos (PBS)

cr0x@pbs:~$ df -i
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2     61054976 60980012  74964  100% /

Significado: Te quedaste sin inodos. Las escrituras fallan incluso si hay bytes disponibles.
Decisión: podar snapshots antiguos, ejecutar GC y considerar migrar el datastore a un sistema de ficheros/dataset con ratio de inodos adecuado. También revisar layout de fragmentos/índices y retención.

Task 3: Identificar qué datastore está configurado (PBS)

cr0x@pbs:~$ proxmox-backup-manager datastore list
┌───────────┬───────────────┬────────────┬───────────┐
│ Name      │ Path          │ PruneOpts  │ Comment   │
╞═══════════╪═══════════════╪════════════╪═══════════╡
│ mainstore │ /mnt/datastore│ keep-daily │ primary   │
└───────────┴───────────────┴────────────┴───────────┘

Significado: Ahora sabes la ruta para revisar con df, ls y herramientas del sistema de ficheros.
Decisión: enfocar diagnósticos en el montaje correcto, no adivinar “/ está lleno”.

Task 4: Comprobar salud del pool ZFS (PBS, si aplica)

cr0x@pbs:~$ zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 02:11:45 with 3 errors on Thu Dec 19 03:12:10 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz1-0  DEGRADED     0     0     0
            sdb     ONLINE       0     0     2
            sdc     ONLINE       0     0     1
            sdd     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/pbs@somefile

Significado: existen errores de checksum. Esto no es un “bug de PBS”; es un evento de integridad de almacenamiento.
Decisión: pausar escrituras intensivas, reparar hardware, volver a hacer scrub y luego ejecutar verificación en PBS y planear restauraciones para snapshots afectados.

Task 5: Localizar fallo de backup en logs de PBS (PBS)

cr0x@pbs:~$ journalctl -u proxmox-backup --since "today" | tail -n 30
Dec 26 01:12:01 pbs proxmox-backup[2211]: upload failed: No space left on device (os error 28)
Dec 26 01:12:01 pbs proxmox-backup[2211]: failed to finalize backup: unable to write index
Dec 26 01:12:01 pbs proxmox-backup[2211]: job failed: datastore "mainstore" is full

Significado: claro “ENOSPC” y fallo de escritura de índice. Los fragmentos pueden haberse subido pero los metadatos no pudieron finalizar.
Decisión: liberar espacio primero y luego reintentar. También programar prune/GC para no repetir esto la próxima semana.

Task 6: Verificar contexto de error en el lado PVE (PVE)

cr0x@pve1:~$ journalctl --since "today" | grep -E "vzdump|proxmox-backup-client" | tail -n 20
Dec 26 01:11:58 pve1 vzdump[18277]: INFO: starting new backup job: vzdump 101 --mode snapshot --storage pbs-main --notes-template '{{guestname}}'
Dec 26 01:12:01 pve1 vzdump[18277]: ERROR: Backup of VM 101 failed - upload failed: No space left on device (os error 28)
Dec 26 01:12:01 pve1 vzdump[18277]: INFO: Failed at 2025-12-26 01:12:01

Significado: el mismo ENOSPC aparece. No hace falta perseguir fantasmas de red.
Decisión: detener nuevas copias hasta recuperar espacio en el datastore.

Task 7: Verificar que el montaje no esté “mintiendo” (PBS, común con NFS/iSCSI)

cr0x@pbs:~$ mount | grep /mnt/datastore
192.0.2.50:/export/pbs on /mnt/datastore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Significado: El datastore está en NFS. Esto puede funcionar, pero es donde nacen muchas historias de “fragmentos perdidos”.
Decisión: si ves corrupción de fragmentos o E/S intermitente, considera mover los datastores de PBS a discos locales o a una pila de almacenamiento con checksums de extremo a extremo.

Task 8: Buscar errores de E/S en el sistema de ficheros (PBS)

cr0x@pbs:~$ dmesg -T | tail -n 20
[Thu Dec 26 01:10:44 2025] blk_update_request: I/O error, dev sda, sector 194512345 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 01:10:44 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 26 01:10:44 2025] EXT4-fs (sda2): Remounting filesystem read-only

Significado: un disco o controladora provocó que ext4 se remonte en modo solo-lectura. PBS fallará de maneras extrañas después de esto.
Decisión: detener trabajos de backup, reparar hardware, ejecutar fsck si es necesario y solo entonces intentar nuevos backups. Asume que las copias recientes están incompletas hasta verificarlas.

Task 9: Comprobar estado y uso del datastore (PBS)

cr0x@pbs:~$ proxmox-backup-manager datastore status mainstore
┌──────────────┬──────────────────────────────┐
│ Key          │ Value                        │
╞══════════════╪══════════════════════════════╡
│ name         │ mainstore                    │
│ path         │ /mnt/datastore               │
│ total        │ 8.00 TiB                      │
│ used         │ 7.62 TiB                      │
│ avail        │ 0.38 TiB                      │
│ read-only    │ false                        │
└──────────────┴──────────────────────────────┘

Significado: solo quedan 0.38 TiB. Eso puede desaparecer rápido con backups grandes, o incluso por crecimiento de metadatos/índices.
Decisión: ajustar retenciones, añadir capacidad o repartir cargas entre datastores. No te fíes de “la deduplicación nos salvará”.

Task 10: Ejecutar una verificación dirigida (PBS)

cr0x@pbs:~$ proxmox-backup-manager verify start mainstore --ns vm --group vm/101
starting verification of datastore 'mainstore'
verifying group 'vm/101'
OK: verified snapshot 'vm/101/2025-12-25T01:10:02Z'
FAILED: snapshot 'vm/101/2025-12-26T01:10:02Z' - missing chunk "3f2c...d91a"
TASK OK: verify datastore mainstore

Significado: un snapshot tiene un fragmento faltante. Esto es pérdida de almacenamiento subyacente, escrituras interrumpidas o inconsistencia índice/fragmento.
Decisión: preserva el estado del datastore (no “limpies” al azar), inspecciona la salud del almacenamiento y planifica re-ejecutar ese backup tras arreglar espacio/estabilidad.

Task 11: Simular prune antes de borrar (PBS)

cr0x@pbs:~$ proxmox-backup-manager prune list mainstore --ns vm --group vm/101 --dry-run
found 14 snapshots
would keep: 7
would remove: 7
  remove vm/101/2025-12-01T01:10:02Z
  remove vm/101/2025-12-02T01:10:02Z
  remove vm/101/2025-12-03T01:10:02Z

Significado: puedes ver lo que la retención eliminaría sin comprometer nada.
Decisión: si el espacio es escaso, procede con prune y luego ejecuta GC. Si hay requisitos legales/compliance, detente y ajusta la política con las partes interesadas.

Task 12: Ejecutar recolección de basura (PBS)

cr0x@pbs:~$ proxmox-backup-manager garbage-collection start mainstore
starting garbage collection on datastore 'mainstore'
found 18234 unreferenced chunks
removed 18190 chunks, reclaimed 412.7 GiB
TASK OK: garbage collection

Significado: espacio recuperado. Este es el paso que la gente olvida tras el prune.
Decisión: volver a comprobar espacio libre; solo entonces reiniciar los horarios de backup.

Task 13: Inspeccionar presión por número de ficheros en el datastore (PBS)

cr0x@pbs:~$ find /mnt/datastore/.chunks -type f | wc -l
58492312

Significado: decenas de millones de ficheros pueden tensar tablas de inodos, búsquedas en directorios y backups del mismo servidor de backups.
Decisión: si estás en ext4 con agotamiento de inodos o dolor de rendimiento, planifica una migración de datastore (ratio de inodos mayor, o diseño de dataset ZFS) y reconsidera la retención.

Task 14: Confirmar conectividad y autenticación del repositorio (PVE)

cr0x@pve1:~$ proxmox-backup-client login pbs01 --repository backup@pbs@pbs01:mainstore
Password for "backup@pbs@pbs01":
Login succeeded.

Significado: la autenticación y la red básica funcionan. Si los trabajos siguen fallando, es probable que sea capacidad o integridad, no credenciales.
Decisión: no empieces a rotar contraseñas en pánico y vuelve al diagnóstico del datastore.

Task 15: Buscar síntomas de bloqueos obsoletos (PBS)

cr0x@pbs:~$ journalctl -u proxmox-backup --since "today" | grep -i lock | tail -n 10
Dec 26 00:59:03 pbs proxmox-backup[2144]: unable to acquire lock on snapshot: resource busy
Dec 26 00:59:03 pbs proxmox-backup[2144]: backup failed: datastore is locked by another task

Significado: otra tarea (backup, verify, GC, prune) mantiene el bloqueo, o una tarea previa falló dejando estado atrás.
Decisión: verifica tareas en ejecución en la UI y en el host; no borres archivos de bloqueo a ciegas. Si una tarea está atascada, arregla primero el problema de E/S subyacente.

Task 16: Confirmar sincronización horaria (PVE y PBS)

cr0x@pbs:~$ timedatectl
               Local time: Fri 2025-12-26 01:20:11 UTC
           Universal time: Fri 2025-12-26 01:20:11 UTC
                 RTC time: Fri 2025-12-26 01:20:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: la hora está sincronizada. Esto importa más de lo que la gente admite: certificados expirados, “snapshots en el futuro” y programación rara pueden parecer problemas de almacenamiento.
Decisión: si los relojes están mal, arregla NTP primero y luego reintenta las operaciones fallidas.

Errores de fragmentos: qué significan y qué hacer

Los errores de fragmentos aparecen como “fragmento faltante”, “coincidencia de checksum”, “imposible decodificar fragmento” o fallos al finalizar índice.
Trátalos como un espectro: desde snapshots incompletos inocuos (trabajo murió antes del commit) hasta corrupción genuina del almacenamiento.

Fragmento faltante

Síntoma típico: verify informa fragmentos faltantes; la restauración falla para un snapshot específico.

Causas raíz comunes:

Escritura de backup interrumpida (ENOSPC a mitad de flujo, crash del servidor, sistema de ficheros remontado RO).
Inconsistencia del almacenamiento subyacente (picos de NFS, caché de controladora RAID que miente, disco defectuoso).
Limpieza humana (“Borré algunos archivos de fragmentos para liberar espacio.” Por favor, no lo hagas.)

Qué hacer:

Confirma que el sistema de ficheros del datastore está sano: revisa dmesg, SMART, RAID, scrubs ZFS.
Verifica si solo el snapshot más reciente está afectado. Si es así y coincide con ENOSPC o un crash, reejecuta el backup tras arreglar capacidad.
Si múltiples snapshots en el tiempo tienen fragmentos faltantes, asume que el almacenamiento está perdiendo escrituras o corrompiendo datos. Detén y arregla eso primero.

Coincidencia de checksum / errores de decodificación

Aquí dejas de culpar a PBS y empiezas a culpar a la entropía. Los checksums existen porque los discos devuelven bits erróneos ocasionalmente.

Causas raíz: RAM mala (sí, de verdad), un disco que devuelve datos antiguos o un problema de controladora/firmware. En PBS virtualizado, la pila de almacenamiento del hipervisor también puede estar implicada.

Qué hacer: haz scrubs y pruebas del almacenamiento; ejecuta tests de memoria si la corrupción se repite; verifica snapshots recientes; y para cargas afectadas, asegúrate de tener una segunda copia (otro PBS, cinta, objeto, lo que permita tu gobernanza).

Fallas al escribir/finalizar índice

A menudo aparece como “unable to write index”, “failed to finalize backup”, “unexpected EOF”. El flujo de backup puede subir muchos fragmentos
y luego fallar al final cuando el índice/catálogo debe ser comprometido. Si el espacio está justo, ese commit final es donde pierdes todo.

Qué hacer: trata los errores de índice como “backup inválido hasta verificarlo”. Arregla espacio o el estado RO del FS, reejecuta el backup y luego verifica.

Broma #1: Un fragmento faltante es como un calcetín perdido—molesto, misterioso y siempre desaparece cuando ya vas tarde.

Errores de espacio: no solo “disco lleno”

“No space left on device” es contundente. El problema es que Linux lo lanza por al menos cuatro tipos diferentes de “espacio”, y PBS
lo mostrará cuando intente comprometer datos o metadatos. Aquí están las trampas de espacio que golpean a operadores de PBS en producción.

1) Agotamiento de bytes (disco lleno clásico)

Sencillo: df -h marca 100%. Pero el problema más interesante es “no está al 100% todavía, pero efectivamente lleno”.
ZFS, btrfs e incluso ext4 bajo alta fragmentación pueden comportarse mal mucho antes del 100%.

Regla: no mantengas un datastore deduplicado por encima de ~80–85% a largo plazo si te importa el rendimiento y un GC exitoso.
Puedes picos breves, pero si vives ahí, pagarás en timeouts y rarezas.

2) Agotamiento de inodos

Las tiendas de fragmentos de PBS pueden crear un número enorme de ficheros. Algunos sistemas de ficheros (y elecciones de tamaño de inodos) te castigarán.
Si df -i está alto, puedes obtener ENOSPC mientras df -h parece bien.

Solución: prune y GC para reducir el conteo de fragmentos, luego planear migración de datastore dimensionada para muchos ficheros. Si estás construyendo desde cero, diseña para presión de inodos.

3) Restricciones de metadatos/transacciones (realidad CoW)

En ZFS puedes tener “espacio libre” pero no suficiente espacio contiguo (o margen de metadatos) para completar asignaciones eficientemente.
Un pool lleno puede hacer que GC funcione dolorosamente lento, lo que significa que no puedes recuperar espacio lo suficientemente rápido para desbloquear backups. Esto se vuelve un bucle.

Solución: mantén pools con margen; no asumas que “cabe” es éxito. Añade vdevs/capacidad antes de tocar el acantilado. Considera vdevs especiales solo si entiendes dominios de fallo.

4) “Bloques reservados” y espacio solo para root (matiz ext4)

ext4 típicamente reserva un porcentaje de bloques para root. Si PBS se ejecuta como root (común), puede aún escribir donde otros procesos no pueden.
O viceversa, dependiendo del usuario del servicio y la configuración de montaje. Esto puede crear fallos parciales confusos.

Solución: entiende tus ajustes de reserva y permisos del servicio. Pero no “tunes” las reservas de seguridad solo para exprimir unas cuantas copias más. Ahí es donde terminas con un sistema muerto a las 3 a.m.

Bloqueos, permisos y “ayer funcionaba”

Los sistemas de backup son máquinas de estado con filos afilados. Los bloqueos existen para prevenir modificaciones concurrentes del mismo grupo de snapshots.
Cuando los bloqueos quedan obsoletos, o los permisos cambian de debajo, las fallas parecen aleatorias.

Errores de permisos (ruta del datastore, propiedad, opciones de montaje)

Síntomas: “permission denied”, “read-only filesystem”, “failed to create directory” o trabajos que fallan inmediatamente.

Chequeo de realidad: “Puedo escribir ahí como root” no es lo mismo que “el servicio PBS puede escribir ahí en su contexto de ejecución”.
Además, una exportación NFS puede cambiar silenciosamente de comportamiento tras un reinicio o evento de red.

Solución: confirma opciones de montaje, permisos reales de la ruta y que el sistema de ficheros sea RW y estable.

Errores de bloqueo

Los bloqueos suelen ser un síntoma, no la enfermedad. Un verify de larga duración, un GC atascado o un sistema de ficheros colgado por E/S pueden mantener bloqueos y causar fallos.
La acción correcta no es “eliminar bloqueos”, es “¿por qué está la tarea atascada?”.

Una idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla, todo el tiempo; diseña sistemas para que la falla sea rutinaria, no catastrófica.”

Prune y garbage collection: el tren que avanza lento

La retención en PBS es un baile de dos pasos:

Prune elimina referencias a snapshots según la política.
Garbage collection recupera fragmentos que ya no son referenciados por ningún snapshot.

Si solo prunes, tu datastore puede seguir pareciendo lleno. Si solo haces GC, nada sucede porque los snapshots aún referencian fragmentos.
Si haces ambos mientras el pool está al 95% y es inestable, ambas operaciones se vuelven lentas y frágiles.

Guía operativa (con opinión, porque la necesitas)

Programa prune y GC en ventanas de baja I/O, pero no tan raramente que golpees acantilados.
No superpongas verify intensivo con GC en sistemas pequeños. Tus discos pasarán la noche peleando entre sí.
Mantén la retención realista. “Guardar todo para siempre” es una orden de compra de almacenamiento, no una política.
Verifica restauraciones, no solo backups. La verificación captura fragmentos faltantes; las pruebas de restauración detectan brechas operativas (claves, permisos, red).

Broma #2: La recolección de basura es como el presupuesto corporativo—nada se recupera hasta que alguien demuestra que está verdaderamente en desuso.

Tres mini-historias corporativas desde la trinchera de backups

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

Una empresa mediana ejecutaba PBS en un estante de almacenamiento nuevo. El equipo supuso que “controladora RAID con caché con batería” era suficiente para hacer las escrituras seguras.
También asumieron que porque las VM de producción funcionaban bien, las escrituras de backup eran “menos importantes” y podían tolerar altibajos ocasionales.

La primera señal de problema fueron fallos de verificación: fragmentos faltantes repartidos entre distintos grupos de VM. No solo el snapshot más reciente.
Las restauraciones funcionaban a veces y fallaban en otras. La gente culpó actualizaciones de PBS, luego la red, luego la “complejidad de la deduplicación”.

El punto de inflexión fue correlacionar timestamps de verify de PBS con logs de la controladora que mostraban advertencias de destaging de caché y reinicios ocasionales.
Las escrituras de backup son de alto rendimiento y en ráfagas; golpean la controladora de una manera que la carga de VM no hacía. El array a veces reconocía escrituras
y luego las perdía durante una ventana de reinicio. PBS hizo su trabajo: se quejó cuando los fragmentos no estaban después.

La solución fue aburrida: actualización de firmware, reemplazo de la controladora y mover el datastore de PBS a ZFS con checksums de extremo a extremo en un host con RAM ECC.
La verificación dejó de fallar. También añadieron un segundo destino PBS réplica para cargas críticas, porque “una copia” no es una estrategia.

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

Otro equipo quería backups más rápidos. Pusieron el datastore PBS en una exportación NFS respaldada por un NAS rápido. En papel, era genial: mucha capacidad,
expansión fácil, aprobación del equipo de almacenamiento. Ajustaron rsize/wsize de NFS, se sintieron listos y declararon victoria.

Durante un mes todo pareció bien. Luego vieron errores periódicos de “unable to decode chunk” y algunos snapshots que no podían verificarse.
Los fallos fueron esporádicos—vibraciones clásicas de “siempre es la red”. El equipo de almacenamiento insistía en que el NAS estaba sano. El equipo de virtualización decía que PBS era quisquilloso.

El problema real fue sutil: stalls intermitentes de NFS durante operaciones intensivas en metadata y un evento de failover que cambió el comportamiento del export brevemente.
Los ficheros de fragmentos y los índices son sensibles a escrituras parciales y sincronización. El NAS estaba optimizado para cargas secuenciales grandes, no para millones de objetos de fragmentos
con constante churn de metadata.

Revirtieron la “optimización” y colocaron el datastore en espejos ZFS locales con un objetivo de espacio libre sensato. Las copias en papel se hicieron un poco más lentas,
pero se volvieron consistentes y verificables. La mejor métrica de rendimiento es “las restauraciones funcionan”, no “el gráfico se ve bonito”.

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

Una compañía regulada tenía la aburrida costumbre de: pruebas de restauración semanales de una VM por clúster, rotando en una lista.
No un simulacro—solo una tarea programada con ticket, una casilla, y una persona que debía adjuntar captura de consola y un archivo checksum.

Una semana, la prueba de restauración falló con un fragmento faltante en el snapshot más nuevo, pero los snapshots más antiguos restauraron bien.
El operario escaló inmediatamente y el equipo pausó nuevas copias para evitar que el ruido sobrescribiera la situación.

Descubrieron que el datastore estaba rondando el 92% y GC no había recuperado espacio porque prune había corrido, pero GC estaba programado en otra ventana
y había estado fallando silenciosamente por timeouts. El sistema no estaba corrupto; simplemente se estaba asfixiando.

Liberaron espacio, ejecutaron GC, reejecutaron el backup fallido y lo verificaron. Sin drama. Lo importante es que la prueba de restauración lo detectó
antes de que un incidente real forzara una restauración bajo presión.

La lección: la práctica “aburrida” no son los backups. Es demostrar que los backups son utilizables.

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

1) “No space left on device” durante finalize

Síntomas: las subidas de backup suben la mayor parte de los datos y fallan al final; los logs mencionan finalize de índice.

Causa raíz: datastore demasiado lleno; metadata/índice necesita espacio al hacer commit.

Solución: prune snapshots, ejecutar GC, mantener datastore bajo un umbral razonable; re-ejecutar y verificar.

2) Backups fallan mientras `df -h` muestra espacio

Síntomas: ENOSPC pero “60% libre”.

Causa raíz: agotamiento de inodos o restricciones de cuota/reserva.

Solución: comprobar df -i; en ZFS revisar cuotas/reservas de dataset; reducir número de snapshots via prune; planear migración si el layout de inodos es inadecuado.

3) “Fragmento faltante” en verificación solo para el snapshot más reciente

Síntomas: solo el snapshot más nuevo falla verify; los antiguos OK.

Causa raíz: backup interrumpido (se acabó el espacio, crash, FS en RO).

Solución: arreglar capacidad/salud; re-ejecutar el backup; verificar de nuevo; considerar alertas por ENOSPC y remontado RO.

4) “Fragmento faltante” disperso en muchos snapshots

Síntomas: fallos de verify a través del tiempo y grupos.

Causa raíz: corrupción del almacenamiento subyacente o comportamiento no fiable del FS remoto.

Solución: detener escrituras, ejecutar diagnóstico del almacenamiento (scrub, SMART, logs de controladora), remediar hardware y luego re-verificar y re-seed de backups.

5) Backups se cuelgan o van lentos, luego fallan por timeouts

Síntomas: trabajos duran horas; GC nunca termina; errores de bloqueo ocasionales.

Causa raíz: datastore demasiado lleno (dolor CoW), o discos saturados por verify/GC/backup concurrentes.

Solución: reducir concurrencia; separar ventanas de verify; mantener espacio libre; mover datastore a discos más rápidos o añadir vdevs.

6) “Datastore is locked”

Síntomas: nuevos trabajos fallan inmediatamente; los logs mencionan locks.

Causa raíz: otra tarea en ejecución, o una tarea atascada por stalls de E/S.

Solución: identificar tareas en ejecución; resolver problemas de E/S; evitar borrado manual de estado; re-ejecutar un trabajo para validar.

7) “Read-only filesystem” durante el backup

Síntomas: fallos repentinos y generalizados; dmesg muestra ext4 remount RO o fallo ZFS.

Causa raíz: errores de E/S hardware o respuesta del sistema de ficheros a corrupción.

Solución: detener, reparar hardware/sistema de ficheros y luego verificar consistencia del datastore y capacidad de restauración.

8) “Authentication failed” después de “sin cambios”

Síntomas: trabajos fallan al inicio; login falla; errores TLS.

Causa raíz: certificados expirados, deriva horaria, rotación de contraseñas descoordinada o typo en la cadena del repositorio.

Solución: comprobar timedatectl; verificar repositorio; re-autenticar con proxmox-backup-client login; actualizar credenciales en la configuración de almacenamiento de PVE.

Listas de verificación / plan paso a paso

Checklist A: Cuando las copias empiezan a fallar esta noche

Detener la hemorragia: pausar horarios de backup si los fallos son por espacio o errores de E/S.
Clasificar: espacio (bytes/inodos), integridad (E/S, checksum), bloqueos/permisos o auth/red.
Confirmar salud del montaje del datastore: df -hT, df -i, mount, dmesg.
Leer logs en el servidor: journalctl -u proxmox-backup cerca del timestamp del fallo.
Si ENOSPC: prune (dry-run primero), luego GC. Re-chequear espacio libre.
Si errores de E/S: detener escrituras, reparar almacenamiento, luego verificar snapshots.
Re-ejecutar un backup para una VM/CT representativa y verificarlo inmediatamente.

Checklist B: Cuando necesitas recuperar espacio de forma segura

Listar retenciones y ejecutar prune en dry-run para un grupo que puedas eliminar con seguridad.
Prune intencionalmente snapshots (no borrar ficheros a ojo).
Ejecutar garbage collection para recuperar fragmentos.
Volver a comprobar bytes libres e inodos.
Ajustar políticas de retención para no repetir la misma emergencia semanal.

Checklist C: Cuando la verificación informa errores de fragmentos

Determinar si es solo el snapshot más reciente o historial disperso.
Comprobar dmesg y salud del almacenamiento (resultados de scrub ZFS / SMART / logs RAID).
Si es solo el más reciente y coincide con ENOSPC/crash: arreglar causa, re-ejecutar backup y verificar de nuevo.
Si está disperso: tratar como incidente de integridad del almacenamiento. Detener escrituras. Remediar hardware/pila de almacenamiento.
Tras la remediación: ejecutar verificación amplia y pruebas de restauración para cargas críticas.

Preguntas frecuentes

1) ¿Por qué PBS habla de “fragmentos” en lugar de archivos?

PBS deduplica y verifica a nivel de fragmento. Tu backup es un conjunto de índices que referencian fragmentos hasheados, no un único archivo monolítico.
Por eso los fragmentos faltantes rompen las restauraciones incluso si “la mayor parte de los datos se subieron”.

2) Si hago prune de snapshots, ¿por qué no recupero espacio de inmediato?

Porque prune elimina referencias; no borra fragmentos compartidos que aún puedan ser usados por otros snapshots. La recolección de basura es lo que realmente recupera
fragmentos no referenciados.

3) ¿Puedo almacenar datastores de PBS en NFS?

Puedes, pero es un intercambio de riesgos. Si tu servidor NFS es extremadamente estable y está afinado para cargas intensivas en metadata, puede funcionar.
En la práctica, muchos problemas de “fragmentos faltantes” se trazan al comportamiento de sistemas de ficheros remotos bajo estrés o failover.

4) ¿Qué objetivo de espacio libre debo mantener?

Para operaciones sanas y GC predecible, reserva un margen significativo. Si regularmente estás por encima del ~85% de uso, espera ralentizaciones y fallos,
especialmente en sistemas CoW. Dimensiona capacidad y retención acorde.

5) Tengo ENOSPC pero aún veo espacio libre. ¿Cómo?

Inodos, cuotas, reservas o restricciones específicas del FS pueden causar ENOSPC. Comprueba siempre df -i, y si usas ZFS, revisa cuotas/reservas de dataset.

6) ¿Debería ejecutar verificación cada noche?

La verificación es excelente, pero consume I/O. En sistemas pequeños, prográmala para que no se solape con backups o GC intensivos.
Para datos críticos, verificaciones frecuentes más pruebas periódicas de restauración superan a la fe ciega.

7) ¿Es seguro arreglar “datastore locked” borrando archivos de bloqueo?

Por lo general no. Los bloqueos suelen estar porque una tarea está en ejecución o atascada por problemas de E/S. Eliminar bloqueos puede crear estado inconsistente.
Encuentra la tarea, encuentra por qué está atascada y resuélvelo.

8) ¿Los errores de fragmentos siempre significan que mi almacenamiento está corrupto?

No siempre. Si el snapshot más reciente falló durante ENOSPC o un crash, puedes tener fragmentos faltantes solo en ese snapshot.
Si los errores de fragmentos aparecen a lo largo del tiempo en muchos snapshots, asume problemas de integridad de almacenamiento hasta demostrar lo contrario.

9) ¿Cuál es el hábito único mejor para evitar sorpresas en backups?

Alerta sobre la utilización del datastore (bytes e inodos) y ejecuta pruebas de restauración programadas. Los logs de éxito son reconfortantes; las restauraciones son evidencia.

Siguientes pasos (haz esto, no aquello)

Si estás enfrentando fallos de backup de PBS hoy, haz estos pasos siguientes en orden:

Consigue evidencia firme: extrae el error desde el lado PBS con journalctl -u proxmox-backup y clasifícalo (espacio vs integridad vs bloqueo vs auth).
Arregla capacidad primero: bytes e inodos. Prune con dry-run. Luego ejecuta garbage collection. Rechequea utilización.
Verifica tras la recuperación: ejecuta verify dirigido en los grupos que fallaron; no asumas que “el próximo backup funcionó” lo arregla todo.
Deja de confiar en almacenamiento inestable: si ves patrones de corrupción reales, pausa escrituras y remedia la pila de almacenamiento antes de crear más backups dudosos.
Haz la falla aburrida la próxima vez: añade alertas para utilización y remontados RO, programa prune/GC sensatamente y ejecuta pruebas de restauración.

El objetivo no es una recuperación heroica. El objetivo es un sistema de backups tan predecible que la única sorpresa sea lo rara que es tu intervención.
Y cuando falle, quieres que falle alto, rápido y con suficiente detalle para arreglarlo antes de necesitar una restauración.