Mantenimiento programado en Proxmox VE 2026: scripts preventivos + correctivos

Después de instalar Proxmox VE y dejarlo andando, el primer susto me lo llevé 8 meses después. Un LXC con ZFS que había dejado de loguear porque el dir de logs estaba lleno al 100%, un servicio que quedó zombie después de un reboot, un disco de backup que dejó de rotarse sin avisar. Nada catastrófico, pero cada uno me costó horas de diagnóstico que un chequeo semanal habría prevenido.

Esta guía cubre el mantenimiento programado que casi nadie documenta — chequeos semanales con cron, mensuales con scripts, trimestrales con revisión manual: estado de ZFS pools, certificados ACME del web UI, actualizaciones pendientes, espacio en logs, salud de los backups, y los pasos de troubleshooting para los fallos más comunes (nodo que no responde, contenedor en estado D, Ceph roto, red ZFS replicada que no sincroniza).

---

Después de instalar Proxmox, configurar ZFS, definir backups y elegir entre LXC y VM, queda la parte que casi nadie documenta: qué hacer cada semana, qué mirar cada mes, y cómo reaccionar cuando un nodo deja de responder. Esta guía cubre el mantenimiento programado con cron, los chequeos de salud reales y los pasos de troubleshooting para los fallos más comunes del día a día en un homelab.

1. Por qué el mantenimiento importa aunque “todo funcione”

Un servidor Proxmox en estado “lo instalé y anda” puede pasar meses sin tocar nada. Hasta que un día el panel web no carga, un contenedor no arranca, o un disco empieza a fallar sin que nadie se entere. El mantenimiento programado no es para servidores rotos: es para enterarte antes de que se rompan.

Tres razones concretas para tener un calendario mínimo:

• ZFS detecta corrupción silenciosa solo si corre zpool scrub con regularidad. Sin scrub, los bit flips se acumulan y la pérdida de datos pasa de “improbable” a “una cuestión de tiempo”.
• Los discos modernos avisan semanas antes de morir a través de SMART. Si no hay daemon que recoja esos avisos, el primer síntoma es el kernel panic.
• Los logs de Proxmox crecen hasta llenar /var/log y rompen journald. logrotate viene por defecto, pero conviene validar que la configuración tenga sentido para tu nodo.

Esto no reemplaza un plan de backup — eso ya se cubrió en la guía de backups y snapshots en Proxmox. El mantenimiento hace que el backup no termine fallando porque el disco se llenó o el daemon murió.

2. Checklist preventivo semanal

La idea es ejecutar cada domingo a las 3 AM un script que recorra los puntos críticos. Después reviso el log los lunes a la mañana. Cada bloque va en /usr/local/bin/proxmox-weekly.sh y se llama desde /etc/cron.d/proxmox-maintenance.

2.1. ZFS scrub

Recorre todos los bloques del pool, calcula checksums y repara silenciosamente lo que encuentra usando la redundancia. La frecuencia semanal es conservadora; Proxmox ya trae un cron por defecto en /etc/cron.d/zfsutils-linux que lanza scrub los domingos a las 00:00 en muchos sistemas PVE 8.x. verifica qué hay configurado antes de añadir el tuyo para no correr dos scrubs en paralelo.

# Listar pools y su estado
zpool status
# Lanzar scrub manual
zpool scrub rpool
# Ver progreso (no bloqueante)
zpool status -v rpool
# Historial de scrubs (cuándo se corrió el último, cuánto tardó)
zpool history rpool | grep -i scrub

QUÉ: fuerza un scrub completo del pool. POR QUÉ: detecta bit rot y repara con raidz/mirror antes de que se acumule. Sin scrub, ZFS no tiene cómo saber que un bloque tiene checksum incorrecto. Troubleshooting: si zpool status muestra DEGRADED o FAULTED, no arranques otro scrub. zpool status -v te dice qué dispositivo concreto es; reemplazá ese disco antes de reintentar. Correr scrub sobre un pool faulted puede empeorar la situación.

2.2. SMART check

El paquete smartmontools ya viene instalado en Proxmox. Lo que suele faltar es el daemon smartd ejecutándose y un /etc/smartd.conf con un dispositivo real.

# Ver si smartd está activo
systemctl status smartd
# Lanzar un test corto manual en un disco
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
# Lanzar test largo (mejor en finde, suele tardar horas)
smartctl -t long /dev/sda

QUÉ: ejecuta self-tests SMART directamente. POR QUÉ: validar que el disco sigue sano antes de que smartd mande un email tarde. El test corto dura uno o dos minutos y atrapa la mayoría de problemas. Troubleshooting: si smartctl devuelve UNKNOWN o READ FAILURE, ese disco está muriendo. Respaldo inmediato y reemplazo. No lo pongas en producción ni para mover datos.

La configuración persistente va en /etc/smartd.conf. Un ejemplo mínimo:

/dev/sda -a -d sat -o on -S on -n standby,q -m [email protected] -M exec /usr/local/bin/smartd-alert.sh
/dev/sdb -a -d sat -o on -S on -n standby,q -m [email protected] -M exec /usr/local/bin/smartd-alert.sh

El flag -M exec permite ejecutar un script en vez de mandar email. Útil si quieres que la alerta vaya a ntfy, Telegram o tu propio watchdog.

2.3. logrotate y journald

Proxmox instala /etc/logrotate.d/pve-* y /etc/logrotate.d/rsyslog. Si tienes containers que loguean mucho o un cluster con mucha actividad, los logs rotados pueden comerse /var/log.

# Ver espacio en /var
df -h /var
# Tamaño actual de los logs
journalctl --disk-usage
du -sh /var/log/*
# Forzar rotación manual
logrotate -f /etc/logrotate.conf
# Ver los boots registrados (útil cuando se pierden logs entre reinicios)
journalctl --list-boots

QUÉ: limpia logs sin perder eventos críticos. POR QUÉ: /var lleno hace fallar journald, lo que rompe a su vez otros servicios que dependen de él. La rotación por defecto protege los logs de sistema, pero los logs de containers y los dumps de kern no siempre se toman como propios. Troubleshooting: si un servicio crítico no escribe logs, revisa que journald no esté en modo auto con un tamaño máximo demasiado bajo. journalctl --verify revisa integridad. Si los logs desaparecen entre reboots, journalctl --list-boots te dice si hay boots “perdidos” — suele pasar cuando la partición /var/log no es persistente o se borró por error.

2.4. Espacio en disco y thin pools

Un LXC o VM con disco thin-provisioned puede crecer hasta llenar el pool si nadie lo mira. pvesm status y zfs list dan el panorama.

# Estado de storages configurados
pvesm status
# Espacio en todos los datasets ZFS
zfs list -o name,used,avail,refer,ratio
# Uso de cada CT/VM
pct list
qm list

QUÉ: detecta datasets cerca del 100 % antes de que LXC empiece a fallar. POR QUÉ: un ZFS al 95 % de uso degrada fuertemente el rendimiento y puede dejar de aceptar escrituras. En raidz, la fragmentación por snapshots empeora el problema. Troubleshooting: si zfs list muestra USEDSNAP alto, tienes snapshots colgadas. zfs list -t snapshot y limpiá las viejas con zfs destroy tank/data@vieja. Si el espacio viene del dataset raíz, revisa /var/lib/vz (ISO y templates) y los backups locales que ya no necesitas.

2.5. Snapshots colgadas

vzdump crea snapshots para hacer backup y los limpia al terminar. Si un backup falla a mitad de camino, el snapshot se queda. Lo mismo con snapshots manuales viejos.

# Listar todas las snapshots del nodo
zfs list -t snapshot | grep -v "no snapshots"
# Borrar una específica (ejemplo: backup de VM 100)
zfs destroy rpool/data/vm-100-disk-0@vzdump
# Borrar todas las snapshots con prefijo vzdump más viejas de 14 días
zfs list -H -t snapshot -o name,creation | grep vzdump | while read -r snap created; do
  age_days=$(( ( $(date +%s) - $(date -d "$created" +%s) ) / 86400 ))
  [ "$age_days" -gt 14 ] && zfs destroy "$snap"
done

QUÉ: elimina snapshots huérfanas que ocupan espacio. POR QUÉ: cada snapshot guarda bloques modificados, y el espacio se devuelve recién cuando se borra. Un backup interrumpido puede dejar varios GB colgados. Troubleshooting: nunca borres una snapshot con la VM/LXC corriendo si tu backend no lo soporta. Para ZFS sobre ZFS puedes hacerlo en caliente, pero en otros backends LVM-thick no.

3. Script weekly con cron

El script /usr/local/bin/proxmox-weekly.sh consolida los chequeos. Lo dejo ejecutable solo por root y lo llamo desde /etc/cron.d/proxmox-maintenance los domingos a las 3 AM.

#!/bin/bash
# /usr/local/bin/proxmox-weekly.sh
# Mantenimiento semanal Proxmox — corre como root vía cron
set -u
LOG="/var/log/proxmox-weekly.log"
DATE="$(date -Iseconds)"
log() { echo "[$DATE] $*" | tee -a "$LOG"; }
log "==== Inicio mantenimiento semanal ===="
# 1. ZFS scrub
log "Scrub ZFS rpool"
zpool scrub rpool >> "$LOG" 2>&1
# 2. SMART short test en cada disco
for d in /dev/sd? /dev/nvme?n?; do
  [ -b "$d" ] || continue
  log "SMART short test $d"
  smartctl -t short "$d" >> "$LOG" 2>&1
done
# 3. Logrotate forzado
log "logrotate -f"
logrotate -f /etc/logrotate.conf >> "$LOG" 2>&1
# 4. journald vacuum si supera 500 MB
# FIX: maneja tanto M como G, y usa awk para comparación numérica correcta
USED=$(journalctl --disk-usage | awk '/Archived and journals/ {for (i=1; i<=NF; i++) if ($i ~ /^[0-9.]+[KMG]$/) {print $i; exit}}')
USED_MB=$(echo "$USED" | awk '{
  val = $1
  if (val ~ /G$/) val = substr(val, 1, length(val)-1) * 1024
  else if (val ~ /M$/) val = substr(val, 1, length(val)-1)
  else if (val ~ /K$/) val = substr(val, 1, length(val)-1) / 1024
  print val
}')
if [ -n "$USED_MB" ] && awk "BEGIN {exit !($USED_MB > 500)}"; then
  log "journald vacuum (>500 MB)"
  journalctl --vacuum-size=300M >> "$LOG" 2>&1
fi
# 5. Estado de storages
log "pvesm status"
pvesm status >> "$LOG" 2>&1
# 6. Snapshots ZFS colgadas (>14 días)
log "Snapshots ZFS antiguas"
zfs list -H -t snapshot -o name,creation | while read -r snap created; do
  age_days=$(( ( $(date +%s) - $(date -d "$created" +%s) ) / 86400 ))
  if [ "$age_days" -gt 14 ]; then
    log "  SNAP VIEJA ($age_days días): $snap"
  fi
done
# 7. Resumen final
log "==== Mantenimiento semanal completo ===="
exit 0

El cron de sistema:

# /etc/cron.d/proxmox-maintenance
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=root
0 3 * * 0 root /usr/local/bin/proxmox-weekly.sh

QUÉ: automatiza los chequeos sin intervención. POR QUÉ: el domingo a las 3 AM el nodo suele estar ocioso y un scrub no compite con cargas de día. El tee -a al log garantiza que el log exista incluso si el script falla antes del primer comando. Troubleshooting: si el script nunca corre, validá que el archivo termine con newline (cron lo requiere) y que tenga permisos 0644 con owner root. journalctl -u cron muestra si el daemon lo recogió. Si el log está vacío, revisa que set -u no esté reventando en una variable vacía — sustituí por set -euo pipefail solo cuando ya sabes que el script está estable.

4. Alertas que importan (y cuáles ignorar)

No todas las alertas valen tu tiempo. Estas sí:

Señal	Qué hacer
smartd manda email de reallocated sectors	Respaldo inmediato, comprar disco de reemplazo
zfs-zed reporta IO failure o checksum errors	Revisar zpool status -v y no hacer scrub hasta identificar el disco
pvestatd reinicia en bucle	Verificar que pmxcfs (la DB del cluster) responda: pvecm status
/var al 90 % o más	journald vacuum y limpieza de snapshots
Load average > cantidad de cores por más de 10 min	Revisar ps -eo pid,state,wchan,cmd | grep pvedaemon

Las que puedes ignorar o archivar:

• Avisos de apt-daily con códigos viejos (Proxmox cambia paquetes sin notificar).
• Notificaciones de “task failed” cuando tú mismo las cancelaste desde la UI.
• Cualquier aviso de “subscription” — Proxmox lo muestra sin que tengas soporte pago, no afecta funcionamiento.

El truco está en centralizar. Una opción simple es zfs-zed configurado con /etc/zfs/zed.d/zed.rc para que las alertas vayan a tu email, y un smartd con -M exec para que dispare un script. No hace falta montar un Prometheus solo para un homelab; con email + log centralizado alcanza.

5. Troubleshooting: los fallos reales

5.1. La web UI no carga pero SSH sí responde

El patrón clásico de Proxmox: pvedaemon y pveproxy se quedan en estado D (uninterruptible sleep) pegados en FUSE/PMXCFS. Reiniciar todo en cascada rompe PAM y deja el nodo totalmente inaccesible.

Diagnóstico primero, restart después:

# Ver estado de los workers
ps -eo pid,state,wchan,cmd | grep -E "pvedaemon|pveproxy|pvestatd"
# Ver si pmxcfs responde
pvecm status
cat /etc/pve/.members 2>/dev/null && echo OK || echo "pmxcfs colgado"
# Buscar kernel taints
dmesg | grep -E "error|taint|hung"

QUÉ: identifica el worker pegado sin reiniciar nada. POR QUÉ: si matás pvedaemon cuando un worker está en D state, systemd intentará levantarlo y quedará en el mismo estado. necesitas matar el worker D primero. Troubleshooting: si el worker está en D y no responde a kill -9, la única salida es reboot físico. Antes de llegar ahí, intentá systemctl restart pvestatd (a veces eso destraba la DB del cluster). Si el reboot es inevitable, agendá un downtime. En este punto vale chequear dos cosas más: journalctl --list-boots para ver cuándo se perdió la continuidad de logs, y cat /proc/$(pidof pvedaemon)/wchan para confirmar el wchan exacto que muestra el ps anterior.

5.2. LXC no arranca después de un cambio

Síntomas: pct start 100 devuelve “command failed” o se queda pegado. Tres causas habituales:

# Ver el error real
pct start 100 --debug
# Estado de la config
pct config 100
# Logs del container
pct enter 100  # falla si no arrancó; alternativa:
cat /var/log/lxc/100.log

QUÉ: lee el log real del container, no la salida genérica. POR QUÉ: el error de la CLI suele ser “exit code 1” sin contexto. El log en /var/log/lxc/.log muestra el init que falló. Troubleshooting: si el error menciona “apparmor”, el perfil de AppArmor quedó inconsistente tras un upgrade de PVE. pct start 100 con --debug 1 y luego dmesg | tail -50 da el detalle. La fix habitual es regenerar el perfil: aa-complain /usr/bin/lxc-start para permitir arrancar y después investigar por qué AppArmor lo bloqueó.

5.3. ZFS reporta errores después de un corte de luz

Tras un power loss, ZFS puede reportar pool degraded. La secuencia correcta es:

# Estado del pool
zpool status -v rpool
# Si solo un disco del mirror falló, identificarlo por serial
zpool status -L rpool
# Reemplazarlo
zpool replace rpool /dev/disk/by-id/old-id /dev/disk/by-id/new-id
# Ver resilvering
zpool status rpool

QUÉ: resilverea el mirror con un disco nuevo. POR QUÉ: ZFS marca el pool como DEGRADED pero sigue funcionando con el disco sano. No te apures: el resilver corre en background y baja rendimiento temporalmente. Troubleshooting: si zpool status muestra errores de checksum en un disco que YA fue reemplazado, no es problema actual — son los errores históricos. Limpiá con zpool clear rpool y volvé a mirar. Si los checksum errors siguen apareciendo en un disco nuevo, revisa el cable SATA o la controladora: el problema puede ser eléctrico, no del disco.

5.4. smartd no manda email

Tres causas frecuentes, en orden de probabilidad:

1. Postfix no está configurado. dpkg-reconfigure postfix y configura un smarthost, o usa -M exec con un script propio.
2. smartd.conf apunta a un disco inexistente. smartctl --scan da la lista correcta.
3. El test que falla no es de los que avisa smartd. El atributo Reallocated_Sector_Ct se chequea siempre; pero cambios en temperatura no disparan alerta por defecto. Agregá -W diff para monitorear diferencias.

# Verificar config
smartd -T show
smartd -q show

QUÉ: muestra qué reglas están activas. POR QUÉ: distingue entre “smartd no corre” y “smartd corre pero no ve el problema”. Troubleshooting: journalctl -u smartd -f mientras hacés smartctl -t short /dev/sda te muestra si el daemon recogió el test. Si ves el self-test OK pero no llegó email, el problema es Postfix o el -M exec script.

5.5. Disco lleno y nada se puede borrar

Si /var está al 100 % y apt no funciona para limpiar, no puedes ni siquiera apt autoremove. Salida:

# Ver qué ocupa espacio
du -sh /var/log/* 2>/dev/null | sort -h | tail
# Forzar rotación sin el comando
find /var/log -name "*.gz" -delete
find /var/log -name "*.1" -delete
# Vacuum de journald
journalctl --vacuum-size=100M
# Liberar paquetes .deb en cache
rm -rf /var/cache/apt/archives/*.deb

QUÉ: libera espacio a mano cuando las herramientas están rotas. POR QUÉ: /var lleno hace fallar la escritura de logs, lo que rompe journald, lo que rompe el logging de muchos servicios. El ciclo se retroalimenta: si no puedes loguear, no sabes por qué se llenó. Troubleshooting: una vez liberado, buscá la causa raíz. Casi siempre es un container con log rotado mal, o un backup que dejó snapshots en ZFS. Si vuelves a llenarte en pocas semanas, sumá la vigilancia al script semanal.

6. Conclusiones

El mantenimiento de Proxmox se resume en cinco hábitos semanales: scrub, SMART, logrotate, espacio y snapshots. Todo lo demás se puede improvisar cuando algo se rompe, pero esos cinco previenen el 90 % de los fallos del día a día. La clave no es tener la configuración perfecta: es tener un script que corra, un log que revisás los lunes, y saber distinguir las alertas que importan de las que puedes descartar.

En un homelab, el peor escenario no es que algo se rompa — es que se rompa y no te enteres hasta semanas después. Con un cron semanal y smartd activo, eso no pasa.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux