Cuando un datastore de Proxmox Backup Server (PBS) se queda sin espacio, puede parecer que la solución es borrar copias antiguas. Sin embargo, eliminar snapshots y recuperar los bloques que ya no se usan son operaciones distintas. Además, si el sistema de archivos está completamente lleno, las tareas de mantenimiento pueden fallar antes de empezar.
En este caso, el datastore ocupaba el filesystem raíz y el servicio de PBS no podía escribir los registros necesarios para iniciar las tareas. La recuperación se realizó liberando temporalmente parte de la reserva de ext4 y ejecutando la recolección de basura desde PBS.
Importante: no muevas ni borres manualmente archivos del almacén de chunks. PBS debe determinar qué bloques ya no están referenciados por ningún backup.
1. Diagnosticar por qué no se libera espacio
La primera comprobación es identificar el filesystem que contiene el datastore y revisar tanto su espacio como sus inodos:
df -hT
df -i /ruta/del/datastore
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
En la incidencia descrita, el datastore estaba en /backup, dentro de un filesystem ext4 que aparecía al 100 % de uso. Los inodos, en cambio, seguían disponibles. Esto descartó que el problema fuera la creación de demasiados archivos.
Los registros mostraban errores ENOSPC al intentar iniciar tareas de garbage collection, prune y verificación. El servicio proxmox-backup-proxy se ejecutaba como el usuario backup; los bloques libres restantes pertenecían a la reserva de ext4 para procesos privilegiados. Por ello, PBS no podía escribir ni siquiera el registro de la tarea.
Para revisar los mensajes del servicio y la configuración del datastore:
journalctl -u proxmox-backup-proxy --since "2026-10-13 00:00:00" --no-pager
proxmox-backup-manager datastore list
proxmox-backup-manager datastore show backup
La reserva de bloques de ext4 puede consultarse con:
tune2fs -l /dev/sda3
2. Entender la diferencia entre prune y garbage collection
Prune aplica la política de retención y elimina snapshots que ya no deben conservarse. No borra inmediatamente los chunks de datos: estos pueden seguir siendo compartidos por otros backups, y su eliminación corresponde al proceso de garbage collection (GC) [1].
El GC examina los índices del datastore para determinar qué chunks siguen referenciados. Los que ya no se necesitan pueden quedar pendientes durante el periodo de seguridad antes de ser retirados. Por eso, el resultado de una ejecución anterior no siempre equivale al espacio que se liberará en la siguiente [1].
En este caso, la política de prune era diaria con keep-last 2. El último GC completado antes de la intervención había encontrado 765.911 chunks pendientes, equivalentes a 1,42 TiB, pero había retirado 0 B en esa ejecución.
3. Recuperar espacio de forma controlada
Como PBS no tenía espacio disponible para iniciar sus tareas, se redujo temporalmente la reserva de ext4 del 5 % al 4 %. La opción -m de tune2fs ajusta el porcentaje de bloques reservados para procesos privilegiados [2].
tune2fs -m 4 /dev/sda3
df -hT /backup
El cambio dejó aproximadamente 24 GiB disponibles para que PBS pudiera crear los registros de tarea. A continuación, se inició el GC mediante la CLI de Proxmox Backup Server:
proxmox-backup-manager garbage-collection start backup
Se esperó a que la tarea finalizara y se revisaron sus resultados. El GC completó las fases de marcado y barrido y terminó con TASK OK.
La reducción de la reserva fue temporal y específica de esta recuperación. Antes de aplicarla, hay que confirmar el filesystem afectado y conservar el valor original para restaurarlo después.
4. Verificar el resultado y restaurar la reserva
Tras el GC se comprobó el espacio disponible y el estado de la recolección:
df -hT /backup
proxmox-backup-manager garbage-collection status backup
El proceso retiró 783.731 chunks, que el informe cuantificó en 1,447 TiB. El filesystem quedó al 34 % de uso, con aproximadamente 1,5 TiB disponibles. El estado indicó 0 chunks pendientes y still-bad: 0.
Con espacio suficiente, se restauró la reserva original del 5 % y se volvió a comprobar el filesystem:
tune2fs -m 5 /dev/sda3
df -hT /backup
No fue necesario ejecutar un prune manual durante la intervención. La política diaria configurada podría volver a ejecutarse en su siguiente horario.
Conclusiones
- Prune elimina snapshots según la política de retención; el GC es quien retira los chunks que han quedado sin referencias.
- Si el filesystem está lleno, PBS puede no tener espacio para iniciar una tarea ni crear su registro.
- La reserva de ext4 puede proporcionar espacio temporal en una situación como esta, pero conviene restaurarla al valor original una vez recuperada la capacidad.
- El GC debe ejecutarse desde PBS, que conoce las referencias entre índices y chunks. Manipular el almacén directamente puede comprometer la lectura de backups.
📚 Fuentes consultadas
- Maintenance Tasks — Proxmox Backup Server
- tune2fs(8) — Linux manual page
- Technical Overview — Proxmox Backup Server