Problema

En entornos de virtualización donde los discos de las máquinas virtuales se alojan en RAID de HDD, es frecuente que el administrador necesite replicar varios terabytes a una ubicación remota. El enlace suele ser fibra de 2.5 GbE, suficiente para tasas de ~400 MiB/s, pero la conexión no es 100 % estable: los ISP realizan mantenimientos nocturnos que provocan caídas de 1‑2 minutos.

Cuando se ejecuta un backup completo de 18 TB, la ventana de transferencia supera las 18 horas. La pregunta central es: ¿qué ocurre si la red se interrumpe a mitad del proceso? Además, se busca saber si es posible:

  • Ajustar los timeouts del cliente/servidor.
  • Confiar en la fiabilidad de los deltas (incrementales) después de una reconexión.
  • Evaluar si rsync con verificación de checksums es una alternativa viable.

El objetivo es diseñar una solución que sobreviva a interrupciones breves sin perder datos ni volver a copiar bloques ya enviados.

Causa

Las interrupciones pueden originarse en varios puntos:

  1. Mantenimiento del ISP – cortes programados de 1‑2 minutos son típicos en enlaces de fibra compartida.
  2. Equipamiento intermedio – switches o NICs que reinician o pierden buffers bajo carga.
  3. Timeouts predeterminados – tanto el cliente pbs-client como el daemon proxmox-backup-proxy usan valores de espera que pueden cerrar la sesión antes de que la red se recupere.
  4. Fragmentación del flujo de datos – en discos HDD con muchos small writes, el rendimiento varía y el buffer de envío puede vaciarse, provocando retransmisiones que el protocolo interpreta como pérdida de conexión.

En un backup incremental, PBS genera chunks (bloques de 4 MiB por defecto) y los almacena con hash SHA‑256. Si la transferencia se interrumpe, los chunks ya aceptados permanecen en el repositorio; el cliente simplemente reintenta los que faltan. El problema surge cuando el cliente abandona la sesión antes de que el proxy vuelva a estar disponible, lo que obliga a iniciar un nuevo job y a volver a calcular el estado del backup.

Solución

Una estrategia robusta combina ajustes de timeout, uso de proxy y reintentos automáticos, y la configuración de retención de jobs para evitar duplicados. Los pasos son los siguientes:

1. Configurar un Proxmox Backup Proxy dedicado

El proxy actúa como intermediario entre el cliente y el repositorio. Colocarlo en la misma red que el NAS QNAP reduce la latencia y permite que el proxy mantenga la conexión al repositorio mientras el cliente se reconecta.

apt-get install proxmox-backup-proxy
systemctl enable --now proxmox-backup-proxy

En /etc/proxmox-backup/proxy.cfg añadir:

listen = 0.0.0.0:8007
max-connections = 10

2. Ajustar timeouts en el cliente

pbs-client permite sobrescribir los valores por defecto mediante variables de entorno o flags en pbs-backup. Los más relevantes son:

  • --timeout – tiempo máximo de espera para respuestas del proxy.
  • --retries – número de intentos antes de abortar.
  • --retry-delay – pausa entre reintentos.

Ejemplo de comando de backup con valores ampliados:

pbs-backup backup \
  --repository [email protected]:backup \
  --proxy 192.168.1.10:8007 \
  --timeout 300 \
  --retries 10 \
  --retry-delay 30 \
  --compression lz4 \
  vm/101

Timeout de 300 s (5 min) cubre la mayoría de los cortes de ISP. Con 10 reintentos y 30 s entre ellos, el job puede sobrevivir a varios minutos de inestabilidad sin abortar.

3. Habilitar resume de jobs

PBS guarda el estado de cada job en /var/lib/proxmox-backup/jobs. Si el cliente se reinicia, basta con volver a lanzar el mismo job con el mismo ID para que continúe desde el último chunk aceptado.

pbs-backup backup \
  --job-id 20240623-001 \
  --repository [email protected]:backup \
  --proxy 192.168.1.10:8007 \
  vm/101

El --job-id persistente evita la creación de entradas duplicadas en el historial y facilita la auditoría.

4. Usar backups incrementales (deltas) de forma predeterminada

PBS crea automáticamente un full cada 7‑14 días (configurable en datastore.cfg). Entre fulls, los backups son incrementales que solo envían chunks modificados. Esto reduce la ventana de transferencia y, en caso de interrupción, la re‑carga de datos es mínima.

En datastore.cfg:

[datastore:local]
type = cifs
path = //nas/backup
max-snapshots = 30
full-backup-interval = 14d

5. Evaluar rsync como alternativa

rsync con la opción --inplace --partial --append-verify permite reanudar transferencias interrumpidas, pero carece de la deduplicación de chunks que PBS ofrece. En entornos con muchos discos HDD y escrituras pequeñas, el ahorro de espacio de PBS es significativo. Además, rsync no gestiona automáticamente la retención de snapshots ni la compresión de forma centralizada. Por lo tanto, se recomienda usar rsync solo para:

  • Copias de emergencia de archivos de configuración.
  • Validación puntual de integridad (comparar hashes de los backups PBS).

Cuándo aplicar esta solución

Escenarios válidos

  • Backups diarios de varios terabytes sobre enlaces 2.5 GbE o superiores.
  • ISP con mantenimientos programados que generan cortes de 1‑2 min.
  • Infraestructura basada en HDD donde la deduplicación y la compresión reducen el I/O.
  • Necesidad de mantener una política de retención de snapshots sin intervención manual.

Señales de que la solución es necesaria

  • Jobs de backup que abortan después de 5‑10 min de inactividad.
  • Alertas de “connection reset by peer” en los logs de proxmox-backup-proxy.
  • Crecimiento descontrolado del repositorio por falta de deduplicación.

Casos donde no aplica

  • Entornos con SSD exclusivamente y tasas de transferencia >1 GiB/s (el timeout de 5 min puede ser excesivo).
  • Backups que se realizan en la misma LAN sin riesgo de interrupciones externas.
  • Necesidad de replicación en tiempo real (se requieren soluciones de DRBD o Ceph).

Código

# Instalar y habilitar el proxy
apt-get update && apt-get install -y proxmox-backup-proxy
systemctl enable --now proxmox-backup-proxy

# Configurar proxy (ejemplo minimalista)
cat > /etc/proxmox-backup/proxy.cfg <<'EOF'
listen = 0.0.0.0:8007
max-connections = 10
EOF
systemctl restart proxmox-backup-proxy

# Backup con timeout y reintentos ampliados
pbs-backup backup \
  --repository [email protected]:backup \
  --proxy 192.168.1.10:8007 \
  --timeout 300 \
  --retries 10 \
  --retry-delay 30 \
  --compression lz4 \
  --job-id 20240623-001 \
  vm/101

Verificación

  1. Comprobar que el proxy está activo 
    netstat -tulnp | grep 8007
  2. Iniciar un backup y observar los logs 
    journalctl -u proxmox-backup-proxy -f
tail -f /var/log/proxmox-backup/client.log
    • Verificar que, al simular una caída (desconectar el cable 30 s), el cliente muestra “retrying” y continúa sin crear un nuevo job.
  3. Validar la integridad del snapshot 
    pbs-manager snapshot list vm/101
pbs-manager snapshot verify vm/101 --snapshot <id>
  4. Revisar la deduplicación 
    pbs-manager datastore info local | grep "Unique chunks"

Si los logs indican “resume” y el número de chunks únicos no aumenta drásticamente, la configuración está funcionando.

Notas adicionales

  • Monitoreo: Añade una regla en Prometheus o Zabbix que alerte cuando el tiempo de ejecución de un job supere el 150 % del promedio esperado.
  • Compresión: LZ4 ofrece buen equilibrio entre velocidad y reducción de espacio; evita algoritmos más pesados en enlaces de 2.5 GbE donde el CPU es el cuello de botella.
  • Retención: Configura prune-policy en datastore.cfg para eliminar automáticamente snapshots viejos y evitar que el repositorio se llene.
  • Pruebas de resistencia: Programa una prueba mensual donde se corta la red durante 2 minutos y se verifica que el backup se reanuda sin intervención.
  • Hardware: Asegúrate de que la NIC del QNAP y del host Proxmox soporten jumbo frames (MTU 9000) para reducir la sobrecarga de paquetes en largas transferencias.

Con estos ajustes, los backups masivos pueden tolerar interrupciones breves, aprovechar al máximo la deduplicación de PBS y mantenerse dentro de una ventana operativa aceptable, sin depender de soluciones de copia de archivos genéricas como rsync.