Caida Proxmox 10-07-2026
RCA — Inconsistencia de metadata en LVM Thin Pool de Proxmox
Fecha del incidente: 10/07/2026
Hora aproximada de inicio: 11:00 hs
Servicio afectado: Proxmox VE — almacenamiento local-lvm
Componente afectado: LVM Thin Pool pve/data
Severidad: Alta
Estado: Resuelto
1. Resumen ejecutivo
El 10/07/2026 aproximadamente a las 11:00 hs se produjo una falla en el subsistema de almacenamiento de Proxmox VE que impidió la activación normal del thin pool pve/data.
El error reportado por LVM fue:
El incidente fue provocado por una inconsistencia en la metadata del LVM Thin Pool, que impedía que el volumen lógico pve/data pudiera ser activado correctamente.
La recuperación se realizó de forma controlada, preservando previamente una copia de seguridad de la metadata existente. Posteriormente se ejecutó el mecanismo de reparación de LVM Thin Pool mediante lvconvert --repair, se verificó la integridad de la metadata con thin_check y se procedió a la reactivación del almacenamiento.
Una vez recuperado el thin pool, se realizaron verificaciones sobre local-lvm y se inició progresivamente la carga de las máquinas virtuales.
Estado final
- 🟢 Storage operativo
- 🟢 Thin Pool
pve/dataoperativo - 🟢 Metadata del Thin Pool verificada
- 🟢
local-lvmoperativo - 🟢 Máquinas virtuales recuperadas y operativas
- 🟢 Sin pérdida de servicio persistente posterior a la recuperación
2. Impacto
Impacto técnico
La inconsistencia de metadata afectó la capacidad de Proxmox VE para activar y utilizar correctamente el thin pool pve/data.
Como consecuencia, las operaciones dependientes del almacenamiento local-lvm quedaron comprometidas, incluyendo la disponibilidad de las máquinas virtuales almacenadas sobre dicho pool.
Impacto sobre las VMs
Las máquinas virtuales fueron recuperadas mediante un arranque progresivo, evitando generar una carga simultánea innecesaria sobre el subsistema de almacenamiento inmediatamente después de la reparación.
No se identificó una pérdida permanente de las máquinas virtuales como resultado del incidente.
3. Error observado
El error inicial que permitió identificar el problema fue:
Este mensaje indica una condición anómala dentro de la estructura del thin pool: el volumen de metadata (pve/data_tmeta) permanecía activo en un estado incompatible con la activación del thin pool principal (pve/data).
La condición no correspondía a un simple problema de montaje o activación del volumen lógico, sino a una inconsistencia relacionada con la metadata utilizada por LVM Thin Provisioning.
4. Análisis técnico
El almacenamiento afectado utilizaba un LVM Thin Pool, compuesto conceptualmente por:
La metadata del thin pool mantiene información crítica sobre la relación entre los bloques lógicos y físicos utilizados por los volúmenes thin.
Una inconsistencia en esta metadata puede impedir que LVM active el thin pool, incluso cuando los dispositivos físicos subyacentes continúan siendo accesibles.
En este caso, la condición observada involucraba específicamente al volumen:
que permanecía activo e impedía la activación normal de:
Por lo tanto, el problema se clasificó como una inconsistencia/corrupción de metadata del LVM Thin Pool.
5. Acciones de recuperación
La recuperación se realizó siguiendo una estrategia orientada a preservar la información existente antes de modificar la metadata.
5.1 Backup de metadata
Antes de ejecutar acciones de reparación se realizó una copia de seguridad de la metadata del Volume Group.
Esta medida permitió conservar el estado previo a la reparación y mantener una posibilidad de recuperación adicional ante un resultado inesperado.
5.2 Reparación del Thin Pool
Se ejecutó el mecanismo de reparación provisto por LVM:
El objetivo fue reconstruir/reparar la metadata del thin pool a partir de la información disponible, permitiendo que pve/data volviera a un estado activable.
5.3 Conservación de la metadata anterior
Como parte del proceso de recuperación, la metadata anterior fue conservada como:
Esto permitió mantener una referencia del estado anterior del thin pool y evitar la pérdida inmediata de la metadata original como consecuencia del proceso de reparación.
5.4 Verificación mediante thin_check
Una vez realizada la reparación se efectuó una validación de la metadata mediante:
La finalidad de esta comprobación fue verificar que la metadata resultante presentara una estructura consistente desde la perspectiva de las herramientas de Device Mapper Thin Provisioning.
El resultado permitió continuar con la recuperación del almacenamiento.
5.5 Reactivación de pve/data
Con la metadata reparada y validada se procedió a reactivar el thin pool:
La activación se completó correctamente, eliminando la condición que impedía el funcionamiento normal de local-lvm.
5.6 Validación de local-lvm
Posteriormente se verificó el estado del storage de Proxmox asociado al thin pool:
Se confirmó que el almacenamiento volvía a estar disponible para las operaciones de Proxmox VE.
5.7 Recuperación progresiva de las VMs
Finalmente se procedió al arranque progresivo de las máquinas virtuales.
La estrategia de recuperación progresiva permitió:
- Validar el acceso al almacenamiento.
- Confirmar la disponibilidad de los discos virtuales.
- Evitar una carga simultánea elevada sobre el storage.
- Detectar rápidamente cualquier VM que presentara problemas particulares.
- Confirmar la recuperación integral de la plataforma.
6. Causa raíz
Causa raíz primaria
Inconsistencia/corrupción de la metadata del LVM Thin Pool pve/data.
La metadata del thin pool alcanzó un estado inconsistente que provocó que el volumen de metadata pve/data_tmeta permaneciera activo de forma incompatible con la activación del thin pool principal.
Esto generó el error:
La evidencia disponible permite establecer la corrupción/inconsistencia de metadata como causa raíz del incidente.
Nota: con la información actualmente disponible no se puede determinar con certeza el evento que originó la corrupción de metadata. Por lo tanto, no debe atribuirse el incidente a una causa específica de hardware, energía, kernel, LVM o Proxmox sin evidencia adicional.
7. Factores contribuyentes
No se identificó, con la evidencia disponible, un único factor externo que haya provocado la inconsistencia.
Entre los factores técnicamente relevantes para este tipo de incidente se encuentran:
- Dependencia crítica del thin pool para el almacenamiento de las VMs.
- Metadata del Thin Pool como componente crítico del sistema de almacenamiento.
- Posibilidad de que una inconsistencia de metadata impida la activación del storage aunque los dispositivos físicos continúen disponibles.
- Necesidad de procedimientos de recuperación específicos para LVM Thin Provisioning.
Estos puntos deben considerarse factores de riesgo, no causas confirmadas del incidente.
8. Resolución
La incidencia fue resuelta mediante:
Backup de metadata
↓
Reparación del Thin Pool
↓
Conservación de metadata anterior
↓
Validación con thin_check
↓
Reactivación de pve/data
↓
Validación de local-lvm
↓
Arranque progresivo de VMs
El procedimiento permitió recuperar el almacenamiento sin necesidad de reconstruir el pool desde cero.
9. Validación posterior
Finalizada la recuperación se verificaron los siguientes componentes:
| Componente | Estado |
|---|---|
Volume Group pve |
🟢 OK |
Thin Pool pve/data |
🟢 OK |
| Thin Pool metadata | 🟢 OK |
local-lvm |
🟢 OK |
| Volúmenes de las VMs | 🟢 OK |
| Máquinas virtuales | 🟢 OK |
El estado final de la plataforma fue considerado operativo.
10. Conclusión
El incidente fue provocado por una inconsistencia en la metadata del LVM Thin Pool pve/data, que impedía su activación debido a que pve/data_tmeta permanecía activo en un estado incompatible.
La recuperación fue exitosa gracias a la preservación previa de la metadata, la utilización de las herramientas nativas de reparación de LVM Thin Provisioning y la posterior validación de integridad.
No se requirió reconstruir el storage ni realizar una recuperación completa de las máquinas virtuales.
Estado final del incidente
Storage OK — Thin Pool OK — Metadata OK —
local-lvmOK — VMs OK
11. Acciones recomendadas
Como seguimiento del incidente, se recomienda:
- Documentar formalmente el procedimiento de recuperación de LVM Thin Pool.
- Mantener backups de metadata de los Volume Groups y Thin Pools críticos.
- Monitorear periódicamente el estado de los thin pools.
- Monitorear capacidad y utilización del thin pool, incluyendo metadata.
- Revisar logs de
kernel,LVM,device-mapperyProxmox VEante cualquier anomalía futura. - Mantener un procedimiento probado para recuperación de
local-lvm. - Documentar dependencias entre VMs y los storage utilizados.
- Evaluar mecanismos de backup independientes del storage local del nodo Proxmox.
- Registrar cualquier evento futuro de I/O, filesystem, kernel o hardware que pueda ayudar a determinar el origen de una eventual inconsistencia de metadata.
12. Estado del RCA
Incidente: Cerrado Recuperación: Exitosa Causa raíz: Inconsistencia/corrupción de metadata del LVM Thin Pool Pérdida de datos confirmada: No Storage: Operativo VMs: Operativas