Velocidad de restauración en Proxmox: ajustar PBS, elegir compresión y por qué las restauraciones son lentas

Cómo funcionan realmente las restauraciones en PBS (y por qué no es solo “copiar el archivo de vuelta”)

PBS no es un repositorio tonto de archivos tar. Es un almacén de chunks direccionados por contenido con deduplicación y backups incrementales.
Durante el backup, el cliente divide los datos en chunks, calcula checksums, comprime los chunks y envía los chunks “nuevos” al servidor.
Eso es una carga de escritura mayormente secuencial más algo de hashing. A los sistemas modernos les encantan las escrituras secuenciales.

La restauración es el inverso pero no simétrica. Restaurar una VM o un contenedor requiere leer muchos chunks, en un orden específico,
reensamblar los datos, verificar la integridad, descomprimir y transmitirlos al almacenamiento objetivo. Las lecturas de chunks pueden ser menos secuenciales
de lo que esperas, especialmente cuando el backup está muy deduplicado a lo largo del tiempo o entre máquinas. La deduplicación es excelente para capacidad.
Puede ser medianamente ruda con el rendimiento de la restauración si tu almacenamiento subyacente es débil en lecturas aleatorias o operaciones de metadatos.

El pipeline de restauración (modelo mental)

• Host PVE solicita a PBS el contenido del snapshot (vía proxmox-backup-client / herramientas integradas).
• PBS lee metadatos de chunks, localiza archivos de chunk, los lee desde el datastore y verifica checksums.
• PBS descomprime los chunks (dependiendo de cómo se almacenaron los datos).
• Host PVE recibe un stream y lo escribe en tu almacenamiento objetivo (ZFS, LVM-thin, Ceph, directorio, etc.).
• Almacenamiento objetivo realiza su propio trabajo: asignación, copy-on-write, checksumming, paridad, comportamiento TRIM, etc.

La velocidad de restauración es básicamente el mínimo de cuatro techos:
lecturas/throughput del datastore, CPU para descompresión/checksums,
ancho de banda/latencia de red y comportamiento de escritura del almacenamiento objetivo.
Solo necesitas que uno de ellos esté mal para que todo vaya mal.

Una de las verdades más molestas: la “velocidad de backup” suele estar limitada por la tasa de cambio, los ahorros de compresión y la eficiencia de dedup.
La “velocidad de restauración” está limitada por la rapidez con la que puedes recrear la imagen completa, no solo el delta.

Datos interesantes y contexto histórico (porque los sistemas no se volvieron extraños por accidente)

1. La deduplicación se volvió mainstream en backups empresariales a mediados-finales de los 2000 porque el disco era más barato que las bibliotecas de cintas y los enlaces WAN eran dolorosos.
2. El almacenamiento direccionado por contenido (almacenar bloques por hash) tiene raíces en sistemas de investigación anteriores, pero explotó con herramientas como Git porque es confiable y amigable con dedup.
3. Los valores predeterminados de compresión modernos cambiaron de gzip a zstd en muchos ecosistemas a finales de los 2010 porque zstd ofrece buenas ratios con decodificación mucho más rápida que codecs antiguos.
4. Los backups “incremental forever” a menudo se optimizan para ventanas de backup, no para ventanas de restauración; el camino de restauración puede convertirse en un montón de indirectas.
5. ZFS popularizó el checksumming de extremo a extremo en almacenamiento commodity; eso es excelente para corrección, pero cada checksum sigue siendo trabajo de CPU en la restauración.
6. Las penalizaciones de escritura de RAID5/6 son vieja noticia; menos recordado es que la paridad RAID también puede ser pobre en lecturas aleatorias bajo carga, lo que los almacenes de chunks pueden desencadenar.
7. NVMe cambió las expectativas de “velocidad de disco” tanto que muchos equipos ahora culpan primero a la red— a veces incorrectamente, a veces con razón.
8. Los trabajos de verificación de backups son una reacción cultural a incidentes de corrupción silenciosa de los 1990 y principios de los 2000; valen la pena, pero pueden chocar con restauraciones.

Una frase que la gente de operaciones repite por una razón: La esperanza no es una estrategia. — General Gordon R. Sullivan.
Un plan de restauración que asume “será lo suficientemente rápido” es solo esperanza con una línea en el presupuesto.

Guía rápida de diagnóstico (encuentra el cuello de botella en minutos)

Las restauraciones son sensibles al tiempo. No tienes tiempo para “optimizar todo”. Necesitas identificar rápidamente el factor limitante
y luego cambiar la única cosa que eleva el techo.

Primero: ¿es lado lectura de PBS, red, o escritura del objetivo?

1. Comprueba el throughput en ambos extremos. Si los discos de PBS están al máximo pero el host objetivo está inactivo, la limitación es lectura. Si la red está saturada, es la red. Si el almacenamiento objetivo está ocupado (alto iowait) mientras PBS está bien, la limitación es escritura.
2. Comprueba la CPU. Si un núcleo está caliente y otros inactivos durante la restauración, podrías estar limitado por un hilo único en algún sitio (descompresión, checksum o un driver de almacenamiento).
3. Comprueba la contención. Si GC/verify/prune se están ejecutando en PBS, puede que te estés peleando a ti mismo. Detén los trabajos de fondo durante una restauración urgente.

Segundo: ¿el datastore se comporta como “muchas lecturas pequeñas” o “grandes lecturas secuenciales”?

• Si tu datastore PBS está en HDD RAID y ves MB/s bajos con presión alta de IOPS, el comportamiento de lectura aleatoria de chunks te está mordiendo.
• Si está en SSD/NVMe y sigue lento, revisa CPU, cifrado/compresión o problemas de offload de la red.

Tercero: ¿es el almacenamiento objetivo el villano silencioso?

• ZFS con recordsize pequeño, sync forzado o ashift inadecuado puede arruinar las escrituras.
• LVM-thin bajo presión de metadatos puede colapsar.
• Restaurar a Ceph/RBD tiene sus propias realidades de replicación y backfill.

Broma #1: Una restauración es como un simulacro de incendio— excepto que el edificio está realmente en llamas y de repente todos recuerdan que tienen “preguntas”.

Elección de compresión: zstd vs lzo vs ninguna, y lo que realmente pagan las restauraciones

La compresión es la perilla más malentendida en sistemas de backup. Los equipos eligen un algoritmo por la ventana de backup,
luego se sorprenden cuando el día de la restauración les cobra intereses.

Qué estás intercambiando

• CPU: la compresión y descompresión cuestan ciclos. La descompresión suele ser más barata que la compresión, pero no es gratis.
• Red: los datos comprimidos reducen bytes en la red; eso puede mejorar mucho la restauración si estás limitado por la red.
• I/O del datastore: menos bytes leídos puede ayudar si estás limitado por throughput, pero si estás limitado por lecturas aleatorias, la CPU puede convertirse en el siguiente cuello de botella.
• Eficiencia de dedup: algunas estrategias de compresión interactúan con chunking/dedup. Generalmente, el chunking se hace sobre datos crudos y los chunks se comprimen después; esto mantiene la dedup razonable.

Regla práctica que suele cumplirse en producción

• zstd (niveles moderados) es la opción sensata por defecto. Buena ratio, decodificación rápida, en general amigable para restauraciones.
• lzo puede ser atractivo por su bajo coste de CPU, pero pagas con más datos (más lecturas de disco, más red). En 10GbE+ puede seguir siendo aceptable; en 1GbE suele ser doloroso.
• sin compresión rara vez es la respuesta a menos que estés totalmente limitado por CPU y tengas ancho de banda y disco absurdamente rápidos.

Realidad de la restauración: la trampa “backup rápido, restore lento” por compresión

Es común subir el nivel de compresión para hacer los backups más baratos o reducir el uso de almacenamiento. Eso puede volverse en tu contra.
La restauración requiere descomprimir todo el conjunto de datos que quieres recuperar, no solo los bloques cambiados. Si tu PBS tiene CPU modesta
y elegiste un nivel de compresión pesado, puedes quedarte limitado por CPU en el servidor durante la restauración.

La mejor práctica es aburrida: elige una configuración de compresión que mantenga tanto el backup como la restauración dentro de tu RTO.
Luego valídalo con pruebas reales de restauración, no con sensaciones.

El camino de almacenamiento importa: discos del datastore PBS, ZFS, RAID, SSD y mitos sobre cache

El rendimiento de PBS depende abrumadoramente del datastore. No de la UI. No del catálogo. El datastore: donde viven los archivos de chunk.
Si guardas tu datastore en discos lentos, las restauraciones te lo recordarán.

Patrones de I/O del datastore PBS en términos sencillos

• Ingesta de backup: muchas escrituras mayormente secuenciales de nuevos chunks más actualizaciones de metadatos.
• Restauración: muchas lecturas de archivos de chunk, que pueden ser parcialmente secuenciales pero con frecuencia se vuelven “con saltos” dependiendo de la distribución de chunks e historial de dedup.
• Verify: lee muchos chunks para confirmar integridad; compite directamente con la restauración por ancho de lectura.
• GC (garbage collection): puede hacer trabajo sustancial de metadatos y lecturas de disco; no es gratis.

Recomendaciones de colocación del datastore (con opinión)

• Mejor: espejo NVMe (o SSD redundantes) dedicados al datastore PBS, especialmente para muchas VMs y restauraciones frecuentes.
• Bueno: SSD RAID10 o espejo ZFS con capacidad decente. Las lecturas aleatorias importan.
• Aceptable: HDD RAID10 para archivos más grandes donde las restauraciones son raras y el RTO es flexible.
• Evitar: RAID de paridad (RAID5/6) de HDD para cargas activas de restauración, a menos que lo hayas probado y aceptado el tiempo de restauración.
• También evitar: poner el datastore PBS en el mismo pool que ejecuta cargas de VM. Eso es autoflagelación con pasos extra.

Aspectos específicos de ZFS (porque muchas cajas PBS acaban en ZFS)

ZFS puede ser excelente para PBS: checksumming, snapshots y comportamiento predecible. Pero debes respetar cómo ZFS asigna y cachea.
Un datastore PBS es una carga de archivos con muchas lecturas y búsquedas de metadatos. Eso presiona ARC y puede implicar lecturas de bloques pequeños.

• Tamaño de ARC: suficiente RAM ayuda a metadatos y chunks calientes. No tener RAM suficiente significa más lecturas a disco y restauraciones más lentas.
• Recordsize: para un sistema de archivos que almacena archivos de chunk, el recordsize por defecto suele estar bien. No tunées recordsize al azar a menos que conozcas la distribución de tamaños de chunk y hayas medido resultados.
• SLOG: generalmente irrelevante para restauraciones en PBS; SLOG afecta escrituras síncronas, no lecturas. Si alguien intenta “arreglar la velocidad de restauración con SLOG”, has encontrado a un adivinador confiado.
• L2ARC: puede ayudar si tu conjunto de trabajo de chunks es cacheable y repetido. Para restauraciones puntuales de desastre, a menudo se calienta despacio y hace poco.

Broma #2: L2ARC es como un becario—útil después del periodo de incorporación, pero no te salvará el día uno del incidente.

Red y transporte: cuando 10GbE aún restaura como en 2009

Los problemas de red son aburridos hasta que dejan de serlo. Una restauración es un flujo sostenido que hace visibles cada ajuste malo de NIC y cada
switch sobre suscrito de repente.

Qué vigilar

• Desajustes de MTU: jumbo frames en un extremo y no en el otro provocan fragmentación o blackholing. El rendimiento se vuelve “misteriosamente malo”.
• CPU por paquete: paquetes pequeños a altas tasas pueden saturar un núcleo. Esto ocurre más de lo que la gente admite.
• Errores en bonding/LACP: puede que no obtengas throughput agregado para un único flujo; muchas restauraciones son un solo stream TCP.
• Firewall/IPS: la inspección profunda de paquetes en la VLAN de backup es una excelente forma de convertir restauraciones en arte de rendimiento.

La latencia importa más de lo que crees

Los patrones de fetch de chunks deduplicados pueden implicar muchas lecturas pequeñas y búsquedas de metadatos. Si la interacción cliente-servidor requiere
muchos ciclos request/response, la latencia y la pérdida de paquetes importan. Por eso “10GbE” no es una garantía. Es un techo.

Ajustes de PBS que realmente mueven la aguja

PBS no tiene 400 perillas ocultas de rendimiento, lo cual es una ventaja. Las ganancias son mayormente arquitectónicas:
almacenamiento rápido, CPU suficiente, RAM suficiente y programar trabajos en segundo plano para que no compitan con las restauraciones.

Programación y contención: la victoria más sencilla

• Los jobs de verify son importantes pero no deberían ejecutarse durante horas laborales si las restauraciones necesitan ser rápidas.
• GC debe programarse con conocimiento de las ventanas de restauración. GC más restauración son discos tristes.
• Prune suele ser más ligero pero aún puede causar churn si los snapshots son enormes y frecuentes.

Consideraciones de cifrado

Si usas cifrado, añades sobrecarga de CPU. En CPUs modernas con AES-NI suele estar bien. Pero “suele” no es “siempre”.
Si tu PBS es una máquina antigua reutilizada del laboratorio de alguien, el cifrado puede convertirse en el cuello de botella durante la restauración.

Diseño del datastore

Mantén el datastore en una pila de sistema de archivos y dispositivo de bloque que entiendas. Capas exóticas (sistemas de archivos remotos, cifrado en capas,
thin provisioning sobre thin provisioning) tienden a producir comportamientos impredecibles bajo presión de restauración.

Lado de Proxmox en la restauración: QEMU, LVM-thin, ZFS zvols y dónde muere la velocidad

La gente disfruta culpar a PBS porque es “la cosa de backups”. Pero las restauraciones escriben en algo. Ese algo puede ser lento.

Almacenamiento objetivo ZFS

Restaurar una VM grande en un ZFS zvol significa que ZFS está asignando, checksumming y escribiendo. Si el pool objetivo está fragmentado,
casi lleno o respaldado por HDD, se notará. Además: si tienes sync=always o una carga que fuerza escrituras síncronas,
puedes castrar el throughput.

Almacenamiento objetivo LVM-thin

Los thin pools pueden restaurar rápidamente cuando están sanos. Cuando la metadata del thin está bajo presión, o cuando el pool está cerca del lleno,
el rendimiento puede colapsar. Falla como un adulto: silenciosa, lentamente y durante la única restauración que importa.

Ceph / almacenamiento replicado

Restaurar en Ceph significa que escribes objetos replicados, potencialmente desencadenando backfill o recovery si el clúster no está perfectamente calmado.
La velocidad de restauración pasa a ser “lo que el clúster pueda ingerir de forma segura sin desequilibrarse”.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Estos no son “ejecuta esto y siéntete productivo”. Cada uno te dice dónde se está estrangulando la restauración y qué hacer a continuación.
Ejecútalos durante una prueba de restauración o una restauración real, porque los sistemas inactivos mienten.

Tarea 1: Identificar si PBS está limitado por CPU durante la restauración

cr0x@pbs1:~$ top -H -b -n 1 | head -n 25
top - 10:14:21 up 42 days,  3:11,  2 users,  load average: 11.42, 10.98, 9.87
Threads: 412 total,   9 running, 403 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.1 us,  3.2 sy,  0.0 ni,  1.8 id,  2.9 wa,  0.0 hi,  0.0 si,  0.0 st
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
51231 backup    20   0 5348128 612144  28740 R  198.0   3.8  12:41.22 proxmox-backup
51244 backup    20   0 5348128 612144  28740 R  183.5   3.8  12:39.08 proxmox-backup

Qué significa: Si los hilos de proxmox-backup consumen mucha CPU y el iowait es bajo, probablemente estás limitado por CPU (descompresión, cifrado, checksum).

Decisión: Bajar el nivel de compresión para backups futuros, escalar la CPU de PBS o mover el datastore a almacenamiento más rápido para que la CPU no pierda tiempo esperando.

Tarea 2: Confirmar utilización de disco del datastore y iowait en PBS

cr0x@pbs1:~$ iostat -xm 1 5
Linux 6.2.16-20-pve (pbs1) 	12/28/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.54    0.00    6.91   41.33    0.00   29.22

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s  w_await aqu-sz  %util
nvme0n1         220.0  85432.0     0.0    0.0    3.12   388.3      15.0   6240.0   8.90   1.20   78.0

Qué significa: Alto iowait y alta utilización del dispositivo sugiere que el datastore es el cuello de botella. Mira r_await: si es alto (decenas de ms en SSD, cientos en HDD), las lecturas se están bloqueando.

Decisión: Mover el datastore a medios más rápidos, añadir discos (RAID10) o detener jobs competidores (verify/GC).

Tarea 3: Confirmar si verify o GC compiten con las restauraciones

cr0x@pbs1:~$ systemctl list-units --type=service | egrep 'proxmox-backup-(garbage|verify|prune)'
proxmox-backup-garbage-collection.service loaded active running Proxmox Backup Garbage Collection
proxmox-backup-verify.service              loaded active running Proxmox Backup Verify Job

Qué significa: Si GC/verify se ejecutan durante una restauración, estás creando contención de lectura a propósito.

Decisión: Detener o reprogramar estos jobs durante restauraciones urgentes; establecer ventanas de jobs que respeten el RTO.

Tarea 4: Inspeccionar los logs de tareas de PBS para fases lentas

cr0x@pbs1:~$ proxmox-backup-manager task list --limit 5
┌──────────┬──────────────────────────┬───────────────┬─────────┬──────────┬───────────┐
│  upid    │          starttime       │     worker    │  type   │ status   │ duration  │
╞══════════╪══════════════════════════╪═══════════════╪═════════╪══════════╪═══════════╡
│ UPID:... │ 2025-12-28T09:58:03Z     │ reader        │ restore │ running  │ 00:16:22  │
└──────────┴──────────────────────────┴───────────────┴─────────┴──────────┴───────────┘

Qué significa: La lista de tareas muestra lo que PBS cree que está haciendo y por cuánto tiempo. Combínalo con métricas del sistema.

Decisión: Si las tareas de restauración duran mucho mientras el sistema está inactivo, sospecha del lado cliente/red. Si el sistema está cargado, sospecha del almacenamiento/CPU de PBS.

Tarea 5: Validar espacio libre del datastore y riesgo de fragmentación

cr0x@pbs1:~$ df -h /mnt/datastore
Filesystem      Size  Used Avail Use% Mounted on
rpool/pbsdata   7.1T  6.5T  0.6T  92% /mnt/datastore

Qué significa: Sistemas de archivos muy llenos pueden ralentizar asignaciones y actualizaciones de metadatos, especialmente en sistemas CoW.

Decisión: Prune agresivo, ampliar almacenamiento o añadir un segundo datastore. Mantén margen; 80–85% es un lugar más feliz.

Tarea 6: Comprobar salud del pool ZFS y latencia en PBS (si el datastore está en ZFS)

cr0x@pbs1:~$ zpool iostat -v 1 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                       6.50T   600G   1200     80   140M  10.2M
  mirror                    6.50T   600G   1200     80   140M  10.2M
    nvme0n1                 -      -       600     40   70.0M  5.1M
    nvme1n1                 -      -       600     40   70.0M  5.1M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Confirma si los vdevs ZFS son el factor limitante y si el ancho de lectura coincide con lo esperado.

Decisión: Si el ancho de banda es bajo y las ops son altas, estás limitado por IOPS; mejora a NVMe o añade vdevs (con cuidado) para aumentar paralelismo.

Tarea 7: Comprobar presión de ARC (caché ZFS) en PBS

cr0x@pbs1:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:20:01  3420  1210     35  1100  91    110   9     0   0   28.5G  32.0G
10:20:02  3588  1402     39  1280  91    122   9     0   0   28.5G  32.0G

Qué significa: Alto miss% durante la restauración significa que ZFS va frecuentemente a disco. Algunos misses son normales; misses persistentes sugieren que la RAM es limitante o que la carga no cachea bien.

Decisión: Añadir RAM si los metadatos/chunks podrían cachearse, o aceptar que esta restauración está limitada por disco y mejorar los discos.

Tarea 8: Medir throughput de red y retransmisiones durante la restauración

cr0x@pve1:~$ ip -s link show vmbr0
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    8123456789  7212345      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    6234567890  6123456      0       0       0       0

Qué significa: Drops en el bridge/NIC durante una restauración son una señal roja. Las pérdidas provocan retransmisiones y hunden el throughput.

Decisión: Arreglar la capa física/red: consistencia de MTU, buffers del switch, offloads de NIC, o mover el tráfico de restauración fuera de segmentos congestionados.

Tarea 9: Validar MTU de extremo a extremo (asesino silencioso común)

cr0x@pve1:~$ ping -M do -s 8972 -c 2 10.10.10.20
PING 10.10.10.20 (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

--- 10.10.10.20 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Qué significa: Este host no está configurado para jumbo frames. Si esperabas MTU 9000, no lo tienes.

Decisión: Estandarizar en 1500 en todas partes o configurar jumbo frames en todos lados (NICs, bridges, switches). “En algún sitio” no es un MTU válido.

Tarea 10: Comprobar rendimiento de escritura del lado cliente (datastore objetivo en PVE)

cr0x@pve1:~$ iostat -xm 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.87   55.21    0.00   29.80

Device            r/s     rkB/s   r_await  w/s     wkB/s   w_await  %util
dm-3              1.0      8.0     2.10  920.0  94208.0   34.90   99.0

Qué significa: Si el dispositivo objetivo está alrededor del 99% de utilización y el iowait es alto, la restauración está limitada por escritura en el host PVE.

Decisión: Restaurar a un almacenamiento más rápido, cambiar el objetivo (por ejemplo, restaurar a NVMe local y luego migrar), o arreglar el pool/array subyacente.

Tarea 11: Comprobar si el thin pool está cerca del lleno (LVM-thin)

cr0x@pve1:~$ lvs -a -o+seg_monitor,metadata_percent,data_percent vg0
  LV               VG  Attr       LSize   Pool Origin Data%  Meta%  Monitor
  vmdata           vg0 twi-aotz--  2.50t             93.12  78.55  monitored
  [vmdata_tmeta]   vg0 ewi-ao----  4.00g
  [vmdata_tdata]   vg0 ewi-ao----  2.50t

Qué significa: Un thin pool con 93% de uso de datos es un problema de rendimiento y riesgo; metadata alrededor de 79% tampoco es ideal.

Decisión: Expandir el thin pool, liberar espacio o mover restauraciones a otro lugar. También considera trimming y monitorización antes de llegar al límite.

Tarea 12: Comprobar el llenado del pool ZFS objetivo y riesgo de fragmentación

cr0x@pve1:~$ zfs list -o name,used,avail,refer,mountpoint
NAME            USED  AVAIL  REFER  MOUNTPOINT
rpool           1.92T   110G   192K  /rpool
rpool/ROOT       32G   110G    32G  /
rpool/vmdata    1.88T   110G   1.88T  -

Qué significa: 110G disponibles en un pool de varios terabytes es “vivir peligrosamente”. El rendimiento de ZFS se degrada a medida que los pools se llenan.

Decisión: Liberar espacio o añadir capacidad de vdevs antes de hacer restauraciones masivas; apunta a un pool con margen.

Tarea 13: Confirmar la ruta y el proceso de restauración en el host PVE

cr0x@pve1:~$ ps aux | egrep 'proxmox-backup-client|qemu-img|vma' | grep -v egrep
root     144233  110  2.1 2154320 342112 ?      Sl   10:02   8:14 proxmox-backup-client restore vm/102/2025-12-28T09:40:12Z drive-scsi0.img.fidx --repository pbs@pam@10.10.10.20:pbs --target /dev/zvol/rpool/vm-102-disk-0

Qué significa: Muestra qué herramienta y ruta objetivo están en juego. Restaurar en un zvol vs un archivo vs LVM cambia el comportamiento.

Decisión: Si estás escribiendo en un backend lento, cambia el objetivo de restauración (restaurar en un directorio en NVMe rápido y luego importar/migrar).

Tarea 14: Comprobar offloads de NIC evidentes (sanidad rápida)

cr0x@pve1:~$ ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Qué significa: Offloads desactivados pueden aumentar el coste de CPU por paquete. Offloads activados pero con bugs también pueden perjudicar, pero empieza por lo básico.

Decisión: Si la CPU está pegada en softirq durante la restauración, prueba a alternar offloads (con cuidado) y valida versiones de driver/firmware.

Tarea 15: Prueba rápida y tosca de throughput de disco en el datastore PBS (fuera de horario)

cr0x@pbs1:~$ fio --name=readtest --directory=/mnt/datastore --rw=read --bs=1M --iodepth=16 --numjobs=1 --size=8G --direct=1 --runtime=30 --time_based
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
read: IOPS=820, BW=820MiB/s (860MB/s)(24.0GiB/30001msec)

Qué significa: Esto aproxima lecturas secuenciales; las restauraciones pueden ser más aleatorias. Aun así, si tu datastore no puede hacer buenas lecturas aquí, no restaurará rápido.

Decisión: Si el BW está muy por debajo de lo que debería hacer el hardware, investiga ajustes del controlador, diseño del pool y salud de discos.

Tarea 16: Detectar discos lentos o errores en PBS

cr0x@pbs1:~$ dmesg -T | egrep -i 'error|reset|timeout|nvme|ata' | tail -n 10
[Sat Dec 27 22:14:09 2025] nvme nvme1: I/O 123 QID 4 timeout, reset controller
[Sat Dec 27 22:14:10 2025] nvme nvme1: Abort status: 0x371

Qué significa: Timeouts y resets de controladora destrozan rendimiento y fiabilidad. Una restauración amplificará el dolor.

Decisión: Reemplazar medios inestables, actualizar firmware y dejar de tratar errores como “ruido”.

Tres mini-historias corporativas desde las trincheras

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

Una empresa mediana consolidó backups en PBS y celebró: las ventanas de backup se redujeron, el crecimiento de almacenamiento se desaceleró y los dashboards parecían tranquilos.
El equipo asumió que la restauración escalaría igual porque “es solo leer lo que escribimos”.

La primera prueba real llegó durante una caída de aplicación que requirió restaurar rápidamente una VM de varios terabytes. La restauración arrancó y luego avanzó a paso de tortuga.
Los gráficos de red mostraban mucho margen. Los gráficos de CPU estaban bien. Los discos del datastore PBS estaban a alta utilización con latencias de lectura feas.

El datastore vivía en un gran RAID de paridad de HDD. Se había elegido por capacidad por dólar y era excelente en escrituras de streaming.
Las restauraciones, sin embargo, desencadenaron un patrón de lectura intensiva de chunks que se comportó como I/O semi-aleatorio. El arreglo hizo lo que hacen las matrices de paridad HDD bajo esa carga: sufrió con educación.

Lo arreglaron moviendo el datastore activo a SSDs espejados (y dejando datos más antiguos y fríos en el pool de HDD). Los tiempos de restauración se volvieron predecibles.
La suposición equivocada no era sobre PBS; era sobre asumir que el comportamiento de lectura sería igual al de escritura. El almacenamiento nunca te prometió simetría.

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

Otra organización quiso reducir costos de almacenamiento de backup. Alguien propuso aumentar la compresión agresivamente porque los backups “eran mayormente lo mismo”
y “la CPU es barata”. Giraron la perilla y vieron aplanarse el uso del datastore. El cambio parecía brillante.

Meses después tuvieron que restaurar múltiples VMs simultáneamente tras un parche malo. Las restauraciones fueron dolorosamente lentas y con jitter.
La CPU de PBS estaba saturada, pero no de una manera “usando recursos eficientemente”—más bien “no puedo respirar”.

El nivel de compresión que eligieron estaba bien para backups nocturnos, pero la restauración es una carga de emergencia diurna. La descompresión se convirtió en el cuello de botella,
y como varias restauraciones corrían a la vez, amplificaron la contención de CPU. El almacenamiento era rápido. La red estaba bien. La CPU no lo estaba.

La solución no fue heroica: bajaron la compresión a un zstd moderado, añadieron algo de CPU y—esto es lo que nadie quiere oír—testearon restauraciones trimestralmente.
Los costos de almacenamiento subieron modestamente. El RTO mejoró drásticamente. La “optimización” había optimizado lo equivocado.

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

Una empresa regulada tenía una regla poco glamorosa: cada trimestre, elegir una VM al azar y hacer una restauración completa estilo bare-metal en una VLAN aislada.
Registraban el tiempo, el cuello de botella y los pasos necesarios. A nadie le encantaba. Tomaba horas y no producía ninguna característica brillante.

Un trimestre, la restauración fue más lenta de lo esperado. El entorno de prueba mostró pérdida de paquetes en un puerto de switch y un contador creciente de errores RX.
La VM aún se restauró—eventualmente—pero la nota del postmortem decía: “arreglar la ruta de red antes de que importe”.

Dos meses después, falló un host. Restauraron varias VMs bajo presión. Las restauraciones corrieron cerca de sus números probados, porque el puerto de switch malo ya se había cambiado.
Nadie aplaudió. Nadie compró pastel. El canal de incidentes se mantuvo aburrido, que es el mejor resultado que operaciones obtiene.

La práctica no era ingeniosa. Era repetible. Les salvó de aprender sobre su red durante un outage real.

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

1) “Los backups son rápidos, las restauraciones son lentas” (clásico)

Síntoma: Los jobs de backup terminan rápido; las restauraciones se arrastran, especialmente para VMs grandes.

Causa raíz: Datastore optimizado para escritura secuencial, no para lecturas intensivas de chunks (HDD en RAID de paridad, pool ocupado o baja IOPS).

Solución: Poner el datastore activo en SSD/NVMe espejo/RAID10. Separar datastore “hot restore” del archivo frío.

2) La velocidad de restauración varía salvajemente hora a hora

Síntoma: A veces las restauraciones van bien; a veces son inservibles.

Causa raíz: Contención con verify/GC/prune, o almacenamiento compartido con otras cargas.

Solución: Programar jobs en background; aislar el almacenamiento PBS; limitar concurrencia en horas laborales.

3) La restauración se queda atascada en un porcentaje y “estimación” parece bloqueada

Síntoma: El progreso en la UI apenas se mueve; los logs muestran pausas largas.

Causa raíz: Picos de latencia de lectura de disco, discos SMR, timeouts de controladora o medios fallando causando reintentos.

Solución: Revisar dmesg, logs SMART/NVMe e iostat de latencia. Reemplazar discos inestables; evitar SMR para datastore activo.

4) Enlace 10GbE, pero la restauración se queda en 80–150 MB/s

Síntoma: La red “debería” dar más, pero el throughput se mantiene bajo.

Causa raíz: Límites de flujo único, desajuste de MTU, pérdidas de paquetes, overhead de firewall/IPS o saturación de softirq en CPU.

Solución: Validar MTU extremo a extremo; comprobar drops y retransmisiones; mover tráfico de restauración; ajustar offloads de NIC y afinidad de IRQ si hace falta.

5) CPU está saturada en PBS durante la restauración

Síntoma: Alto uso de CPU, baja utilización de disco; las restauraciones son lentas.

Causa raíz: Nivel de compresión pesado, sobrecarga por cifrado o pocos cores para restauraciones concurrentes.

Solución: Usar zstd moderado; escalar CPU; limitar restauraciones concurrentes; considerar separar ingest y restore (PBS más grande o segundo PBS).

6) Restaurar en ZFS es más lento de lo esperado

Síntoma: PBS está bien; el host PVE muestra alto iowait y las escrituras son lentas.

Causa raíz: Pool objetivo casi lleno, diseño de vdev lento, fragmentación o settings de sync.

Solución: Añadir capacidad, mantener margen libre, restaurar a almacenamiento temporal más rápido y luego migrar; verificar diseño de pool ZFS (espejos para IOPS).

7) Restauraciones en LVM-thin empiezan rápido y luego degradan

Síntoma: Los primeros minutos son buenos; luego se cae en picado.

Causa raíz: Thin pool o metadata cerca del límite; contención de I/O de metadata.

Solución: Expandir thin pool; liberar espacio; monitorizar Data% y Meta%; evitar operar thin pools con alta utilización.

8) Múltiples restauraciones a la vez lo hacen todo inutilizable

Síntoma: Una restauración está bien; tres restauraciones son terribles.

Causa raíz: Cuello de botella compartido (IOPS del datastore, CPU de PBS, colas de red o límites de escritura del almacenamiento objetivo).

Solución: Limitar concurrencia; escalonar restauraciones; mejorar el cuello de botella compartido; considerar datastores o nodos PBS separados.

Listas de verificación / plan paso a paso

Paso a paso: hacer las restauraciones más rápidas sin tuning cargo-cult

1. Elige un objetivo de restauración: define un RTO para “una VM crítica” y “peor día: 5 VMs críticas”. Si no puedes nombrar números, no puedes afinar.
2. Haz una prueba real de restauración durante una ventana tranquila. Mide throughput extremo a extremo (disco PBS, CPU PBS, red, disco PVE).
3. Elimina contención: programa verify/GC fuera de las ventanas de restauración. No compartas el datastore PBS con cargas de VM.
4. Decide tu cuello de botella usando la guía rápida de diagnóstico. No actualices tres cosas a la vez.
5. Si el lado lectura es el cuello de botella: mueve el datastore a SSD/NVMe, prefiere espejos/RAID10, asegura RAM suficiente para cache de metadatos.
6. Si la CPU es el cuello de botella: baja el nivel de compresión, asegúrate de aceleración AES si está cifrado, añade cores y limita restauraciones concurrentes.
7. Si la red es el cuello de botella: valida MTU, elimina pérdidas, limpia la ruta (sin inspección sorpresa) y verifica throughput por flujo esperado.
8. Si la escritura objetivo es el cuello de botella: restaura a almacenamiento local rápido y luego migra; arregla headroom en ZFS; expande thin pools.
9. Reprueba después de cada cambio y registra el resultado. “Se siente más rápido” no es una métrica.
10. Institucionaliza la práctica aburrida: simulacros trimestrales de restauración, con tiempos y cuellos de botella registrados.

Checklist día de restauración (cuando ya está en llamas)

• Detener/suspender temporalmente verify y GC de PBS si compiten por I/O de lectura.
• Ejecutar iostat en PBS y PVE para decidir lectura vs escritura limitada.
• Comprobar saturación de CPU en PBS y iowait en PVE.
• Comprobar drops de NIC y signos de desajuste de MTU.
• Limitar restauraciones concurrentes hasta entender el cuello de botella.
• Si el almacenamiento objetivo es lento, restaurar a un objetivo temporal más rápido y migrar después.

Preguntas frecuentes

1) ¿Por qué mis backups terminan rápido pero las restauraciones tardan una eternidad?

Los backups pueden ser incrementales y deduplicados—por eso mayormente envías chunks cambiados. Las restauraciones reconstruyen la imagen completa de la VM y pueden desencadenar muchas lecturas de chunks más descompresión.
Las IOPS de lectura y la latencia del datastore importan mucho más en la restauración que en el backup.

2) ¿La velocidad de restauración de PBS es mayormente disco, CPU o red?

Es lo que peor esté en ese camino. En la práctica, la latencia de lectura del disco del datastore es el limitador más común, seguido por el rendimiento de escritura del objetivo.
La CPU se vuelve limitadora cuando la compresión/cifrado es pesada o PBS está infra-provisionado.

3) ¿Debo usar zstd o lzo para mejores restauraciones?

Moderado zstd suele ser la mejor opción general: buena compresión con descompresión rápida. lzo reduce CPU pero incrementa bytes leídos/transferidos.
Si estás limitado por red (1GbE), zstd a menudo restaura más rápido. Si estás limitado por CPU y tienes almacenamiento/red muy rápidos, lzo puede ayudar.

4) ¿La deduplicación ralentiza las restauraciones?

La dedup puede complicar el patrón de lectura, lo que perjudica en almacenamiento con malas lecturas aleatorias. En SSD/NVMe, la penalización suele ser pequeña.
Dedup suele valer la pena; solo no pongas el datastore en discos que odien las lecturas aleatorias.

5) ¿Agregar un dispositivo SLOG acelerará las restauraciones?

No de forma material. SLOG ayuda la latencia de escrituras síncronas, no el throughput de lectura. Las restauraciones son intensivas en lectura en PBS y en escritura en el objetivo.
Invierte en medios más rápidos para el datastore y en mejor rendimiento de escritura del objetivo.

6) ¿Debo ejecutar jobs de verify diariamente?

Verificar integridad es bueno. Ejecutarlo cuando choque con restauraciones es malo. Programa verify cuando la urgencia de restauración sea baja,
y dimensiona el datastore para que verify no te tome todo el día.

7) ¿Por qué restaurar muchas VMs a la vez es mucho más lento que una VM?

Aumentas la contención en recursos compartidos: IOPS del datastore, CPU de PBS, colas de red y escrituras del almacenamiento objetivo.
Si necesitas restauraciones paralelas, diseña para ello: más IOPS (mirrors NVMe), más CPU y una ruta de red limpia.

8) ¿Es mejor restaurar a almacenamiento local y luego migrar, en vez de restaurar directamente a almacenamiento compartido?

A menudo sí. Restaurar a NVMe local rápido puede reducir drásticamente el tiempo hasta el primer arranque.
Luego puedes migrar la VM a almacenamiento más lento/replicado cuando el incidente haya pasado y la gente esté menos alterada.

9) ¿Cuánto espacio libre debo mantener en el datastore PBS y en pools ZFS?

Suficiente para no vivir constantemente al borde del precipicio. Un objetivo práctico es mantener 15–20% de margen en pools que necesitan rendimiento y asignaciones previsibles.
Si estás al 90%+, espera sorpresas en el rendimiento.

10) ¿Cuál es la mejora de mayor impacto para las restauraciones?

Poner el datastore PBS en SSD/NVMe con un layout que entregue IOPS (espejos/RAID10). Los arreglos HDD optimizados por capacidad de paridad son un cuello de botella común en restauraciones.
Después de eso, asegúrate de que el almacenamiento objetivo pueda aceptar escrituras al ritmo que restauras.

Conclusión: las próximas acciones que rinden

El rendimiento de restauración no es místico. Es un pipeline con puntos de estrangulamiento predecibles. Si tus restauraciones son lentas, deja de adivinar y mide:
latencia de lectura del datastore, CPU de PBS, salud de la red y comportamiento de escritura del objetivo. Usualmente encontrarás un recurso gritando más fuerte que los demás.

Pasos prácticos siguientes que suelen producir mejora inmediata:

• Programar GC/verify para que nunca compitan con ventanas de restauración.
• Mover el datastore activo a espejos SSD/NVMe (o RAID10) si te importa la velocidad de restauración.
• Elegir compresión sensata (zstd moderado) y validar con simulacros trimestrales de restauración.
• Mantener margen en datastore PBS y pools objetivo; sistemas llenos son sistemas lentos.
• Documentar un runbook de restauración que incluya los comandos de diagnóstico rápido, para no depurar con adrenalina.

El objetivo no es hacer las restauraciones “rápidas”. El objetivo es hacerlas predecibles. Las restauraciones predecibles son las que te permiten dormir por la noche.
O al menos dormir hasta que llegue el siguiente incidente distinto.