Problema

En entornos de virtualización con Proxmox, es frecuente programar backups nocturnos para minimizar el impacto en usuarios activos. Sin embargo, cuando el proceso de backup involucra máquinas virtuales (VM) de gran tamaño y el almacenamiento está basado en ZFS, algunos administradores observan que el host no vuelve a arrancar después de la ventana de backup. El sistema parece quedarse “colgado” en el arranque, o se apaga sin completar el shutdown. El síntoma típico es la ausencia de mensajes de login en la consola y la falta de servicios críticos al inspeccionar journalctl tras un reinicio forzado.

Este patrón no es exclusivo de una única configuración; cualquier host Proxmox con:

  • ZFS como pool de datos (mirrored vdevs)
  • Backups que consumen gran parte del espacio libre del PBS (Proxmox Backup Server)
  • SSD de arranque separado del pool de datos

puede experimentar el mismo bloqueo. El objetivo es ofrecer un método genérico para detectar la causa raíz y aplicar correcciones que eviten la pérdida de disponibilidad.

Causa

Los fallos de arranque después de un backup suelen derivarse de tres grupos de factores:

  1. Agotamiento de espacio en el pool ZFS
    ZFS necesita espacio libre para operaciones de escritura, snapshots y compresión. Cuando un backup de 200 GB+ se escribe en un pool que ya tiene menos del 10 % de libre, ZFS entra en modo “read‑only” o comienza a hacer “sync‑writes” extremadamente lentas. El kernel puede quedarse esperando I/O, lo que impide que systemd complete la secuencia de shutdown y, por ende, que el arranque posterior finalice.

  2. Snapshot y clone conflictivo
    Proxmox crea snapshots automáticos antes de iniciar un backup. Si el pool está casi lleno, la creación del snapshot falla parcialmente, dejando metadatos corruptos. Al reiniciar, zfs-import intenta montar un dataset con referencias rotas y el proceso se detiene en zfs-mount.service.

  3. Problemas de hardware o firmware en el SSD de arranque
    Cuando el backup genera una carga de I/O prolongada, el consumo de energía del controlador SATA/NVMe puede provocar un “power‑state transition” inesperado. En sistemas con firmware antiguo, el SSD puede no responder al comando de shutdown, forzando al kernel a abortar el proceso y dejando el bootloader sin la tabla de particiones actualizada.

En la práctica, la causa más recurrente es la combinación de espacio insuficiente en ZFS y snapshots fallidos, que desencadena una cascada de errores en systemd y zfs-import.

Solución

1. Prevenir el agotamiento de espacio

  • Reserva un margen mínimo del 20 % en el pool que aloja los backups. En ZFS se puede monitorizar con zfs list -o name,avail,used,capacity.
  • Configura el PBS para rechazar nuevos backups cuando el espacio libre sea inferior al umbral definido. En la UI de Proxmox Backup Server, habilita “Space quota” y establece una política de retención que elimine automáticamente snapshots antiguos.

2. Ajustar la política de snapshots

  • Desactiva la creación automática de snapshots antes de backup si el pool está bajo presión. En /etc/pve/datacenter.cfg añade: 
    backup: snapshot = 0
  • Si los snapshots son imprescindibles, limita el número máximo por VM con prune-backup o mediante pvebackup --prune. Por ejemplo, mantén solo 3 snapshots recientes.

3. Optimizar ZFS para workloads intensivos

  • Habilita logbias=throughput en los datasets que reciben los backups: 
    zfs set logbias=throughput rpool/backups
  • Activa compression=lz4 para reducir la cantidad de datos escritos: 
    zfs set compression=lz4 rpool/backups

4. Verificar integridad del SSD de arranque

  • Actualiza el firmware del SSD al último disponible.
  • Añade la opción nvme_core.default_ps_max_latency_us=0 al kernel (en /etc/default/grub) para evitar que el controlador ponga el disco en modo de bajo consumo durante backups prolongados. 
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=0"
update-grub

5. Implementar un proceso de shutdown controlado

  • Crea un script de pre‑shutdown que detenga los backups activos y desmonte temporalmente el dataset de backup: 
    #!/bin/bash
systemctl stop pve-cluster
zfs unmount -a rpool/backups
    Colócalo en /usr/lib/systemd/system-shutdown/ con permisos de ejecución. De esta forma, systemd no quedará esperando I/O pendient​e al apagar.

Cuándo aplicar esta solución

  • Síntomas: host que no llega a login: tras reinicio, journalctl -b -1 muestra procesos bloqueados en zfs-mount.service o systemd-shutdown, o mensajes de “ZFS: out of space” durante backup.
  • Escenarios válidos: cualquier nodo Proxmox con ZFS y backups programados que superen el 30 % del espacio libre del pool.
  • No aplicar: entornos donde los backups se almacenan en NFS o en discos externos no gestionados por ZFS; en esos casos, la causa suele ser distinta (p.ej., problemas de red).

Código

# 1. Ver espacio libre y capacidad del pool
zfs list -o name,avail,used,capacity | grep rpool

# 2. Establecer margen de reserva del 20%
zfs set reservation=20% rpool/backups

# 3. Configurar compresión y logbias
zfs set compression=lz4 rpool/backups
zfs set logbias=throughput rpool/backups

# 4. Añadir flag de NVMe al GRUB
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/&nvme_core.default_ps_max_latency_us=0 /' /etc/default/grub
update-grub

# 5. Script de pre‑shutdown (guardar como /usr/lib/systemd/system-shutdown/stop-backup.sh)
cat <<'EOF' > /usr/lib/systemd/system-shutdown/stop-backup.sh
#!/bin/bash
systemctl stop pve-cluster
zfs unmount -a rpool/backups
EOF
chmod +x /usr/lib/systemd/system-shutdown/stop-backup.sh

Verificación

  1. Simular un backup que ocupe ~30 % del pool y observar zfs list. El campo avail debe permanecer por encima del 20 % después de la escritura.
  2. Reiniciar el nodo y comprobar que systemd llega a graphical.target sin errores en journalctl -b.
  3. Forzar un shutdown mientras el backup está activo y validar que el script de pre‑shutdown desmonta el dataset y finaliza el proceso de backup sin dejar I/O pendiente.
  4. Revisar el log del SSD (dmesg | grep -i nvme) para confirmar que no aparecen mensajes de “link down” o “reset”.

Notas adicionales

  • En clusters con varios nodos, distribuye los backups entre diferentes pools para evitar que un único nodo se quede sin espacio.
  • Si el pool está configurado con dedup=on, el consumo de RAM puede dispararse durante backups grandes; considera desactivar deduplication o asignar más memoria al ARC (zfs_arc_max).
  • Mantén siempre una copia de seguridad de los snapshots críticos en otro medio (por ejemplo, una réplica ZFS a un disco externo) para poder restaurar el dataset si la corrupción ocurre durante el arranque.

Con estos ajustes, la mayoría de los hosts Proxmox dejan de bloquearse después de un backup intensivo y recuperan la capacidad de iniciar de forma fiable.