Cómo solucionar un pool LVM-Thin lleno en Proxmox

En el mundo del autoalojamiento, todo parece ir bien hasta que deja de hacerlo. Muchos usuarios de Proxmox lo descubren por las malas cuando sus pools de almacenamiento LVM-Thin simplemente se llenan. No hay grandes señales de aviso ni alertas rojas, solo un fallo progresivo: los backups dejan de funcionar, las máquinas virtuales se congelan y todo se detiene en seco.

LVM-Thin resulta muy práctico para optimizar el almacenamiento, ya que permite crear volúmenes ligeros que solo ocupan espacio cuando escribes datos de verdad. Sin embargo, su mayor ventaja es también su talón de Aquiles. Por diseño, te permite comprometer más almacenamiento del que realmente tienes y, si no mantienes una vigilancia constante, los problemas aparecen muy rápido.

El desbarajuste suele empezar así. Alguien compra una unidad NVMe de 1TB, instala Proxmox y la configura como local-lvm, el pool LVM-Thin básico. Con el paso del tiempo añade más VM y contenedores, trastea con Docker y el disco alcanza el 88% de ocupación y sigue subiendo. Si a eso se suman unos cuantos backups fallidos, cunde el pánico.

¿Qué medidas concretas toma la gente para resolver este quebradero de cabeza? A continuación recopilamos los trucos que utiliza la comunidad de Proxmox para combatir la saturación de LVM-Thin.

La realidad de LVM-Thin: cuando lleno significa bloqueado

Un usuario de Proxmox describió el escenario con total claridad. Su VM con OPNsense arrancaba y se congelaba poco después sin motivo aparente. Tras dos horas investigando, dio con el fallo: LVM-Thin había llegado al 100%. Y lo llamativo es que no hubo ninguna alerta ni aviso previo, solo un bloqueo total e inadvertido.

No es un caso aislado ni extraño. Los sistemas de archivos convencionales avisan cuando queda poco espacio, pero LVM-Thin te deja seguir escribiendo hasta que no da más de sí. Esa falta de avisos es lo que lo vuelve tan traicionero. «Creé un cronjob para que me envíe un correo cuando el uso del disco alcance el 85%», explicaba un usuario. «Cuesta creer que Proxmox no haga eso por defecto».

Solución 1: Ampliar el pool de almacenamiento sin romper nada

Cuando un disco se llena, lo primero que se te pasa por la cabeza suele ser sustituir esa unidad NVMe por otra mayor. Eso no siempre resulta viable, en especial si no quieres formatear todo y volver a empezar desde cero.

En vez de eso, muchos administradores añaden nuevos SSD y extienden el volume group. Esto mantiene en funcionamiento las VM y los contenedores mientras ganas margen de maniobra. Los pasos son más directos de lo que parecen:

1. Instalar un SSD nuevo
2. Configurarlo como volumen físico (pvcreate)
3. Añadirlo a tu volume group actual (vgextend)
4. Listo: tu thin pool ahora utiliza varios discos

Es verdad que existe cierto riesgo. «Si un disco falla, todo el volume group puede romperse», advertía alguien. No obstante, con SSD fiables y buenas copias de seguridad, es un compromiso asumible para la mayoría.

Solución 2: Sacar las copias de seguridad de ese SSD

Muchas instalaciones se complican la vida ejecutando backups en el mismo disco que aloja las VM, lo que equivale a tentar a la suerte. Los usuarios recomiendan purgar copias antiguas y, sobre todo, trasladarlas a otro soporte por completo.

¿Tienes un NAS? Úsalo. ¿No tienes ninguno? Monta otro disco y apunta tus copias hacia allí. Un usuario veterano de Proxmox compartía esta recomendación: «Usa Proxmox Backup Server (PBS). Elimina duplicados. Estoy guardando 350GB de datos que normalmente consumirían 5TB».

PBS es además una herramienta de ahorro excelente: combina deduplicación, compresión y el envío de datos fuera de tu disco principal en una sola solución. Hay quien lo ejecuta en una máquina independiente y quien lo despliega en una VM dentro del propio Proxmox. De cualquier modo, ayuda muchísimo a mantener a raya el tamaño de tu thin pool.

Solución 3: Limpiar los datos sobrantes

Cuando el espacio escasea, cada gigabyte cuenta. Los usuarios de Docker señalan siempre la misma receta: purgar todo. Contenedores viejos, volúmenes huérfanos, imágenes sin usar: bórralo todo.

«Recuperé más de 100GB solo con podar Docker», contaba orgulloso un aficionado al homelab. Es un buen recordatorio de que el disco se llena con algo más que datos de VM: también acumula residuos de herramientas, compilaciones y experimentos de los que probablemente ya ni te acuerdes.

Programa una limpieza periódica de Docker si utilizas contenedores, y acuérdate de eliminar archivos ISO antiguos o registros acumulados en rincones del sistema.

Solución 4: Activar TRIM y discard

Otro ajuste que suele pasarse por alto es habilitar TRIM en los volúmenes LVM-Thin. Cuando se borran archivos dentro de una VM o de un contenedor, ese espacio no vuelve de forma automática al host: hace falta liberarlo mediante discard.

«Activa la opción Discard en los discos de la VM y comprueba que fstrim.timer esté activo dentro del sistema operativo invitado», sugería un usuario. Esto frena el almacenamiento fantasma, donde el invitado cree haber borrado datos pero el thin pool sigue contabilizándolos contra tu cuota. No es magia, pero en sistemas con muchas escrituras y borrados continuos marca la diferencia.

Solución 5: ¿Abandonar LVM-Thin por completo?

Algunos administradores han optado por una vía más radical: dejar atrás LVM-Thin para adoptar sistemas de archivos como BTRFS o ZFS. Estos ofrecen snapshots nativas, compresión y mucha más claridad sobre qué consume tu espacio.

«Me pasé a BTRFS para gestionar mejor el espacio», contaba un participante. «Hice backup de mis VM a PBS, formateé el disco y restauré». Es un paso drástico, pero para ciertos usuarios el control y la visibilidad compensan el esfuerzo.

Dicho esto, cambiar de sistema de archivos supone una tarea importante. Si ya tienes un despliegue consolidado sobre LVM-Thin, suele ser más sensato optimizar lo existente antes que rehacer todo desde cero.

No esperes a que ocurra el desastre

Lo llamativo es lo fácil que resulta evitar este escenario si te anticipas. Configura alertas de almacenamiento, reubica tus copias de seguridad, realiza limpiezas profundas y vigila el consumo de cerca.

Un pool LVM-Thin saturado es una amenaza directa para la estabilidad del entorno, mucho más grave que un simple contratiempo de capacidad. Al llegar al 100%, las VM se bloquean, los backups fallan y la recuperación se vuelve caótica. Con unas cuantas decisiones acertadas y las pautas de la comunidad, puedes esquivar el problema por completo.

La conclusión es que confiarse resulta arriesgado en el autoalojamiento. Tu servidor no emitirá alarmas llamativas cuando empiece a quedarse sin espacio, pero si prestas atención y sigues los pasos correctos, mantendrás tu homelab funcionando con total tranquilidad.

Soluciones rápidas de usuarios reales

Solución	Qué hace
Añadir un SSD nuevo y ampliar el volume group	Más espacio sin reconstruir
Mover copias a otro disco o a PBS	Detiene el crecimiento de backups en el disco principal
Limpiar Docker y archivos residuales	Libera almacenamiento olvidado
Activar TRIM y discard	Recupera espacio de archivos eliminados
Configurar alertas de disco a tiempo	Avisa antes de que ocurra un desastre
Valorar el cambio de sistema de archivos	Nuevo comienzo con herramientas más adecuadas

Los problemas de almacenamiento rara vez se anuncian a los cuatro vientos. Llegan sin hacer ruido, pero no tienes por qué dejar que te ganen la partida.