Debian 13: /etc/pve parece vacío tras reinicio — por qué fallan los montajes y cómo recuperar

Qué es realmente /etc/pve (y por qué “desaparece”)

En Proxmox VE, /etc/pve no es “un directorio con algunos archivos”. Es un punto de montaje para el sistema de archivos de clúster de Proxmox, pmxcfs.
Es un sistema de archivos en espacio de usuario (FUSE) que presenta la configuración del clúster como un árbol coherente, respaldado por una base de datos interna y sincronizado mediante mensajería de clúster.

Cuando pmxcfs no está montado, tu sistema todavía tiene un directorio literal en /etc/pve, porque Linux necesita algún lugar para montar cosas.
Ese directorio suele estar vacío o contener solo lo que quedó al inicio del arranque. Así que no estás viendo “configuraciones perdidas”. Estás viendo “no montado”.

La cuestión es que los fallos de montaje y las “configuraciones vacías” a menudo aparecen junto con problemas de almacenamiento:
pools ZFS no importados, volúmenes LVM no activados, sesiones iSCSI sin login, NFS no montado, Ceph no listo, o systemd iniciando servicios en orden incorrecto.
Un choque en el arranque y tu pila de administración funciona con la mitad del piso faltando.

Una cita que la gente de operaciones aprende por las malas: “La esperanza no es una estrategia.” — Gene Kranz.
No es específico de almacenamiento, pero aplica dolorosamente cuando alguien dice, “Quizá funcione tras otro reinicio.”

Broma #1: Si tu plan de recuperación es “reinicia hasta que funcione”, felicitaciones — has inventado una máquina tragamonedas con peores probabilidades.

Guía rápida de diagnóstico

Este es el camino más corto de “/etc/pve está vacío” a “sé exactamente qué está roto”. Hazlo en orden. No improvises.

1) Confirma si /etc/pve está montado (no “vacío”)

• Si no es un montaje FUSE, estás viendo el directorio subyacente.
• Si está montado, tu problema probablemente sea quórum, corosync o permisos/contención de bloqueo — no un montaje.

2) Revisa el estado y los logs de pmxcfs

• Si pmxcfs está caído, arregla eso primero. Todo lo demás es ruido.
• Si pmxcfs está arriba, comprueba si se queja de corrupción de DB, archivos de bloqueo o estado de clúster.

3) Revisa corosync y el quórum (en clústeres)

• La falta de quórum suele dejar la interfaz extraña, la configuración parcial y operaciones de clúster bloqueadas.
• Las configuraciones de nodo único pueden sufrir si alguna vez estuvieron en clúster o están mal configuradas.

4) Revisa la disponibilidad del almacenamiento y el orden en systemd

• Si ZFS no importó o LVM no activó, montajes/servicios que dependen de ellos fallarán.
• Arregla la disponibilidad del almacenamiento y luego reinicia los servicios dependientes con calma.

5) Decide: recuperar in situ vs. restaurar desde copias

• Si la BD de pmxcfs está dañada, puede que tengas que reconstruir el estado del nodo desde otros nodos o copias de seguridad.
• Si solo “no está montado”, arregla el servicio y sigue adelante.

Modos de fallo reales (y cómo se muestran)

Modo de fallo A: pmxcfs nunca se montó

Este es el caso clásico de “/etc/pve está vacío”. El directorio existe pero el montaje FUSE no ocurrió.
Las causas incluyen servicio pmxcfs que no arranca, falla de inicio inmediato, o estar bloqueado a la espera de algo más.

Lo que verás:

• mount no muestra pmxcfs.
• systemctl status pve-cluster muestra fallo.
• journalctl muestra errores de inicio (a menudo problemas de bloqueo/DB).

Modo de fallo B: corosync está caído o se perdió el quórum

En un clúster, pmxcfs depende de la comunicación del clúster. Si corosync no puede formar membresía o se pierde quórum,
pmxcfs puede montarse en modo solo lectura, funcionar parcialmente o bloquear ciertas operaciones. A veces /etc/pve sigue montado,
pero las escrituras fallan y las herramientas de gestión se comportan como si caminaran por cemento mojado.

Modo de fallo C: el almacenamiento no volvió y los servicios arrancaron de todos modos

Debian 13 trae comportamientos systemd más recientes y cambios de temporización, además de lo que el hardware/firmware decida esta semana.
Un simple problema de orden de arranque puede hacer que el almacenamiento llegue “tarde”:

• Pools ZFS no autoimportados porque cambió la denominación de dispositivos o un pool se importó por última vez en otro lado.
• VG de LVM no activada porque dispositivos multipath aparecen después del intento de activación.
• Montajes NFS bloqueados por network-online que en realidad no significa “red usable”.
• Inicios de sesión iSCSI que no ocurren lo suficientemente temprano.

El resultado es caos secundario: almacenamientos faltantes en la UI, VMs que no arrancan, backups fallidos y administradores que maldiagnostican “Proxmox se comió mi config”.
La configuración sigue allí; lo que falta son las cosas a las que hace referencia.

Modo de fallo D: corrupción de la base de datos o estado de pmxcfs

Menos común, pero real. Pérdida de energía súbita, disco lleno, memoria defectuosa o ajustes agresivos del sistema de archivos pueden dañar archivos de estado.
Verás errores explícitos sobre la base de datos de pmxcfs, incapacidad para cargar el estado o caídas repetidas.

Modo de fallo E: estás en el nodo equivocado o en la raíz equivocada

He visto gente “arreglar” /etc/pve vacío estando chrooted en un entorno de rescate, o arrancados en el volumen root equivocado.
El sistema de archivos está bien; el operador simplemente no está en el sistema que cree.

Broma #2: Nada humilla tanto a un sysadmin como darse cuenta de que ha estado arreglando el servidor equivocado durante 20 minutos.

Tareas prácticas: comandos, significado y decisiones

Estas son tareas reales que puedes hacer en un servidor de producción a las 3 a.m. Cada una incluye:
el comando, qué significa la salida y la decisión que tomas.
Ejecútalas como root o con sudo donde corresponda.

Tarea 1: Verificar que /etc/pve es un montaje (y de qué tipo)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /etc/pve
/etc/pve pmxcfs fuse rw,nosuid,nodev,relatime,user_id=0,group_id=0

Significado: Si ves pmxcfs fuse, está montado y vivo. Si no ves nada o reporta ext4/xfs,
estás sobre el directorio subyacente y pmxcfs no está montado.

Decisión: Si no está montado, deja de buscar “archivos perdidos” y comienza a arreglar pve-cluster/pmxcfs.

Tarea 2: Comprobar si pmxcfs está en ejecución y si se cayó

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Sun 2025-12-28 02:41:18 UTC; 2min 9s ago
    Process: 813 ExecStart=/usr/bin/pmxcfs (code=exited, status=255/EXCEPTION)

Significado: No está en ejecución; salió con un error.

Decisión: Saca los logs a continuación. No reinicies al azar — entiende la falla (DB, bloqueo, permisos, quórum).

Tarea 3: Leer los logs de pve-cluster por una razón directa

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 28 02:41:18 server pmxcfs[813]: [main] notice: starting pmxcfs
Dec 28 02:41:18 server pmxcfs[813]: [main] error: unable to open database '/var/lib/pve-cluster/config.db': Input/output error
Dec 28 02:41:18 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 28 02:41:18 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Significado: Esto no es un problema de montaje; es un problema de estado/E/S. Ese “Input/output error” puede ser disco, sistema de archivos o almacenamiento subyacente.

Decisión: Inmediatamente revisa la salud del disco y errores del sistema de archivos; evita reinicios repetidos que puedan empeorar la corrupción.

Tarea 4: Confirma que estás sobre el sistema root esperado (no rescue, no LV equivocado)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /
/ /dev/mapper/pve-root ext4

Significado: Estás sobre pve-root. Si ves algo como /dev/sda1 inesperadamente, o una sobrecapa live/rescue,
no estás donde crees.

Decisión: Si la raíz es incorrecta, detente y arranca el volumen correcto; no “repares” configuraciones en el entorno equivocado.

Tarea 5: Revisar el estado y la membresía de corosync (nodos en clúster)

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Sun 2025-12-28 02:39:02 UTC; 4min 25s ago

Significado: Corosync está ejecutándose. Eso no garantiza quórum, pero es un comienzo.

Decisión: Si corosync está muerto, arregla la red/interfaces/firewall y la configuración de corosync antes de culpar a pmxcfs.

Tarea 6: Comprobar quórum explícitamente

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   14
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 02:43:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Significado: No hay quórum. En este estado, muchas operaciones de clúster están bloqueadas para prevenir split-brain.

Decisión: Restaura quórum trayendo suficientes nodos o arreglando la conectividad. Evita “forzar” quórum a menos que aceptes el riesgo.

Tarea 7: Ver si pmxcfs está montado en solo lectura (un truco sutil)

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /etc/pve
/etc/pve fuse rw,nosuid,nodev,relatime

Significado: Esto muestra rw, así que al menos las banderas de montaje no fuerzan solo lectura.
Si ves ro o las escrituras fallan, probablemente tengas problemas de quórum o E/S subyacente.

Decisión: Si es solo lectura por quórum, arregla quórum. Si es por errores de E/S, arregla almacenamiento/sistema de archivos.

Tarea 8: Confirmar que los servicios de almacenamiento no fallaron durante el arranque (triage systemd)

cr0x@server:~$ systemctl --failed --no-pager
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● zfs-import-cache.service     loaded failed failed  Import ZFS pools by cache file
● pve-storage.service          loaded failed failed  Proxmox VE storage daemon

Significado: Tienes fallos concretos: importación ZFS y pve-storage.

Decisión: Arregla la importación ZFS primero; luego reinicia pve-storage y vuelve a comprobar los almacenamientos.

Tarea 9: Revisar si los pools ZFS se importaron

cr0x@server:~$ zpool status
no pools available

Significado: No hay pools importados. Eso romperá cualquier almacenamiento definido sobre esos pools.

Decisión: Intenta una importación segura. Si faltan discos, detente e investiga rutas de hardware/dispositivos.

Tarea 10: Intentar importar el pool ZFS de forma segura (solo lectura primero si sospechas)

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool  ONLINE
          sda3 ONLINE

Significado: El pool es importable.

Decisión: Si este es el pool de arranque, importa normalmente; si sospechas daño, importa en solo lectura para inspeccionar.

cr0x@server:~$ zpool import -f rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME  STATE     READ WRITE CKSUM
        rpool ONLINE       0     0     0
          sda3 ONLINE       0     0     0

Significado: El pool volvió. Ahora los servicios dependientes deberían tener una oportunidad.

Decisión: Reinicia los servicios que fallaron por falta de ZFS (típicamente pve-storage, a veces pvedaemon/pveproxy si dependen de configuraciones/almacenamientos).

Tarea 11: Casos LVM — comprobar si el VG está activo

cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   3   0 wz--n- 930.00g 120.00g

Significado: El VG existe. Si los atributos muestran inactivo o falta, la activación en arranque falló.

Decisión: Si falta, revisa el descubrimiento de dispositivos (multipath/raid). Si está pero inactivo, actívalo.

Tarea 12: Activar volúmenes LVM (solo si sabes que es seguro)

cr0x@server:~$ vgchange -ay pve
  1 logical volume(s) in volume group "pve" now active

Significado: Los LVs están activos; montajes y servicios que dependen de ellos pueden continuar.

Decisión: Si la activación falla, no fuerces. Investiga PVs faltantes, multipath y dmesg.

Tarea 13: Casos de almacenamiento en red — confirmar que network-online es real

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
     Active: active (exited) since Sun 2025-12-28 02:38:40 UTC; 6min ago

Significado: Dice “online”, pero eso solo significa que las interfaces están configuradas, no que tu gateway/DNS/VLAN de almacenamiento sea alcanzable.

Decisión: Prueba la accesibilidad explícita del endpoint de almacenamiento.

Tarea 14: Verificar montajes NFS y fallos de montaje

cr0x@server:~$ findmnt -t nfs,nfs4
TARGET          SOURCE                 FSTYPE OPTIONS
/mnt/pve/backup nas01:/export/backup   nfs4   rw,relatime,vers=4.2,proto=tcp

Significado: Si el montaje está ausente, tu almacenamiento no está disponible. Si está presente, busca en otro lado.

Decisión: Si falta, revisa journalctl -b para errores de montaje; arregla DNS, enrutamiento, firewall o autenticación.

Tarea 15: Casos iSCSI — confirmar que existen sesiones

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2003-01.org.linux-iscsi.nas01:storage.lun1 (non-flash)

Significado: La sesión existe. Si esto está vacío, los LUNs no aparecerán y LVM/ZFS sobre iSCSI fallará.

Decisión: Si falta, vuelve a iniciar sesión y asegura que el orden de servicios sea correcto (iscsid antes de la activación de LVM).

Tarea 16: Revisar errores obvios de disco o sistema de archivos detrás de problemas de DB de pmxcfs

cr0x@server:~$ dmesg -T | tail -n 20
[Sun Dec 28 02:41:10 2025] blk_update_request: I/O error, dev sda, sector 194567890 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Sun Dec 28 02:41:10 2025] EXT4-fs error (device dm-0): ext4_find_entry:1535: inode #262401: comm pmxcfs: reading directory lblock 0

Significado: Eso no es “Proxmox raro”. Es el kernel diciendo que el almacenamiento está fallando.

Decisión: Trata esto como un incidente: detén escrituras riesgosas, valida la capa de disco/RAID/ZFS y planifica la reparación.

Tarea 17: Confirmar el contenido de /etc/pve desde la capa de gestión

cr0x@server:~$ pvesh get /cluster/resources --type vm | head
vmid  status  name       node    type
100   running web-01     node1    qemu
101   stopped db-01      node1    qemu

Significado: Si pvesh puede leer recursos del clúster, pmxcfs probablemente está funcional.

Decisión: Si esto falla, céntrate en pmxcfs/corosync. Si funciona pero faltan almacenamientos, céntrate en la pila de almacenamiento.

Tarea 18: Forzar un intento de remontaje limpio (solo después de entender por qué falló)

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /etc/pve
/etc/pve pmxcfs fuse

Significado: pmxcfs está montado de nuevo.

Decisión: Revisa quórum y almacenamiento. Luego verifica que las configuraciones esperadas estén presentes antes de reiniciar VMs.

Tarea 19: Validar que las configuraciones de nodo existen (no solo el montaje)

cr0x@server:~$ ls -la /etc/pve/nodes
total 0
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 .
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 ..
drwxr-xr-x 1 root www-data  0 Dec 28 02:47 node1

Significado: El sistema de archivos de clúster está presentando nodos. Si está vacío o falta tu nodo, eso es un problema de membresía/estado del clúster.

Decisión: Si falta el nodo, revisa la membresía de corosync y la consistencia del hostname; no empieces a cambiar configuraciones a ciegas.

Tarea 20: Identificar problemas de orden de arranque para montajes/servicios

cr0x@server:~$ systemd-analyze critical-chain pve-storage.service
pve-storage.service +3.201s
└─network-online.target +2.998s
  └─systemd-networkd-wait-online.service +2.950s
    └─systemd-networkd.service +1.102s
      └─systemd-udevd.service +0.421s

Significado: pve-storage esperó por “network-online”, que puede o no incluir la disponibilidad de tu ruta de almacenamiento.

Decisión: Si dependes de iSCSI/NFS, asegúrate de que esas unidades tengan dependencias explícitas y timeouts adecuados a la realidad.

Tres microhistorias del mundo corporativo (porque esto sigue pasando)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana migró dos nodos hiperconvergentes a hardware nuevo y reutilizó las IPs de gestión antiguas. La ventana de cambio fue ajustada.
Alguien reinició un nodo para “verificar ajustes del BIOS” y volvió para encontrar /etc/pve vacío. El pánico se propagó rápido porque la UI mostraba configuraciones de VM faltantes.

La suposición equivocada fue simple: “Si /etc/pve está vacío, la configuración se perdió del disco.”
Empezaron a restaurar copias aleatorias en /etc y editaron /etc/fstab para “arreglar montajes”, nada de lo cual tenía que ver con pmxcfs.
En un host Proxmox, eso es como arreglar una tostadora pintando la cocina.

El problema real fue corosync. Durante la migración de hardware, el equipo había cambiado nombres de interfaz (naming predecible),
pero dejaron corosync.conf referenciando la NIC antigua. Corosync nunca formó membresía, se perdió el quórum y pmxcfs no arrancó correctamente.
El directorio “vacío” era solo un punto de montaje sin montar.

La recuperación fue limpia cuando dejaron de adivinar: arreglaron el naming de interfaces, reiniciaron corosync, confirmaron quórum y reiniciaron pve-cluster.
Todo “reapareció” al instante. El único daño duradero fueron un conjunto de ediciones manuales que hubo que revertir.

La lección: trata /etc/pve como un endpoint de servicio. Si está vacío, es una falla de servicio hasta que se demuestre lo contrario.

Microhistoria 2: La optimización que salió mal

Otra organización tenía la costumbre de quitar segundos del tiempo de arranque donde fuese posible. Empezó inocentemente —desactivar servicios no usados,
acortar timeouts, eliminar “esperas innecesarias”. Mejoraron sus métricas. Su confianza se expandió para llenar el espacio disponible.

Tras un corte de energía no planificado, varios nodos se reiniciaron simultáneamente. Algunos arrancaron limpios; otros mostraron almacenamientos faltantes,
y un par tuvieron la famosa apariencia de /etc/pve vacío durante el diagnóstico temprano. La causa subyacente no era mística.

Las sesiones iSCSI no se habían establecido cuando LVM ejecutó activación. LVM no vio PVs, así que no activó el VG.
Los servicios que dependían de esos volúmenes arrancaron igualmente y almacenaron en caché un estado “ausente”. Más tarde, cuando iSCSI finalmente hizo login,
nadie reactivó correctamente. El sistema estaba “arriba”, pero en un universo medio real.

Arreglarlo requirió revertir la “optimización”: imponer orden entre el login de iscsid y la activación de volúmenes, y dejar de suponer
que network-ready significa storage-ready. También añadieron reintentos dirigidos para almacenamiento, en lugar de reinicios aleatorios de toda la pila.

La lección: la paralelización en el arranque es excelente hasta que choca con almacenamiento distribuido que no se preocupa por tus gráficas.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un entorno regulado (piensa: papeleo con dientes) ejecutaba un clúster Proxmox con control de cambios estricto.
Hicieron dos cosas poco glamorosas de forma consistente: (1) copias de seguridad nocturnas de /etc/pve y configuraciones críticas del host,
y (2) simulacros trimestrales de recuperación donde alguien distinto al operador habitual restauraba un nodo.

Un nodo reinició tras una actualización de kernel y falló en montar pmxcfs debido a un error de disco subyacente que corruptó el archivo de la BD de pmxcfs.
Esto no era una situación de “reiniciar el servicio”. El estado local del nodo no era fiable.

Su respuesta fue aburrida y rápida. Pusieron el nodo en mantenimiento, confirmaron que el clúster permanecía quorate sin él,
reemplazaron el disco fallido, reinstalaron el sistema del nodo, lo volvieron a unir al clúster y restauraron solo la configuración local mínima necesaria.
Las definiciones de VM seguían seguras en el clúster; las definiciones de almacenamiento se revalidaron en lugar de reimportarse a ciegas.

El resultado final: una caída de nodo, sin pérdida de datos de VM y sin arqueología de configuraciones a las 3 a.m.
La parte más “emocionante” fue ver a alguien seguir un runbook línea por línea y terminar antes de tiempo.

La lección: copias de seguridad rutinarias + restauraciones practicadas superan la “memoria tribal” cada vez.

Errores comunes: síntoma → causa raíz → arreglo

1) Síntoma: /etc/pve está vacío tras reinicio

Causa raíz: pmxcfs no está montado (pve-cluster falló) o estás en el directorio subyacente.

Arreglo: findmnt /etc/pve y systemctl status pve-cluster. Arregla la causa en los logs, luego reinicia pve-cluster.

2) Síntoma: /etc/pve está presente pero las escrituras fallan (permiso denegado / solo lectura)

Causa raíz: Clúster sin quórum; pmxcfs puede rechazar escrituras para prevenir split-brain.

Arreglo: Restaura quórum (trae nodos de vuelta, arregla la red de corosync). No “forces quorum” a menos que entiendas el alcance del daño.

3) Síntoma: La UI muestra almacenamientos faltantes, las VMs no arrancan, pero /etc/pve está bien

Causa raíz: Almacenamiento no listo: ZFS no importado, LVM no activo, NFS/iSCSI no montado/logueado.

Arreglo: Diagnostica en la capa de almacenamiento primero (zpool status, vgs, findmnt, iscsiadm).
Luego reinicia pve-storage y valida las definiciones de almacenamiento.

4) Síntoma: pve-cluster falla con errores de BD

Causa raíz: Errores de E/S de disco, corrupción del sistema de archivos o corrupción de la base de datos de pmxcfs.

Arreglo: Deja de thrashiar el servicio. Revisa dmesg por errores de E/S y repara el sistema de archivos/hardware subyacente.
Recupera el estado de pmxcfs desde un nodo sano o copias según sea necesario.

5) Síntoma: Todo funciona hasta que reinicias; luego vuelve a romperse

Causa raíz: Condiciones de carrera/orden de arranque en systemd; dependencias faltantes para almacenamiento en red o dispositivos lentos.

Arreglo: Usa systemd-analyze critical-chain. Añade dependencias unitarias y timeouts adecuados.
Evita hacks de “sleep 30” a menos que te guste vivir en el pasado.

6) Síntoma: /etc/pve vacío al arrancar desde un ISO de rescate

Causa raíz: No has arrancado en el sistema instalado. pmxcfs no está ejecutándose. Por supuesto que está vacío.

Arreglo: Monta el sistema root real y chroot solo si es necesario; de lo contrario arranca normalmente y diagnostica allí.

7) Síntoma: El nombre del nodo cambió; el clúster parece “nuevo”

Causa raíz: Desajuste de hostname con la config del clúster; las rutas de pmxcfs se basan en el nombre del nodo.

Arreglo: Restaura el hostname correcto y la resolución en hosts; asegura que corosync y Proxmox vean el nombre de nodo esperado.

Listas de comprobación / plan paso a paso

Checklist A: Pasos de recuperación para “/etc/pve está vacío” (seguros y rápidos)

1. Confirmar montaje: findmnt /etc/pve.
   Si no es pmxcfs, trátalo como una falla de servicio.
2. Revisar pve-cluster: systemctl status pve-cluster y journalctl -u pve-cluster -b.
   Los logs normalmente te dicen qué está mal. Créeles.
3. Verificar clúster: systemctl status corosync y pvecm status.
   Si no hay quórum, arregla quórum antes de intentar escribir configuraciones.
4. Comprobar almacenamiento: systemctl --failed, luego valida ZFS/LVM/NFS/iSCSI según corresponda.
   Arregla disponibilidad de almacenamiento (importaciones, activaciones, montajes).
5. Reiniciar en el orden correcto:
   servicios de almacenamiento primero (zfs-import, iscsid, remote-fs), luego pve-storage, luego pve-cluster si hace falta.
6. Validar: ls /etc/pve, pvesh get /cluster/resources, y confirmar que los almacenamientos aparecen.
7. Solo entonces: inicia VMs o re-habilita recursos HA.

Checklist B: Cuándo parar y declarar incidente de hardware/almacenamiento

1. dmesg muestra errores de I/O, resets o errores de sistema de archivos.
2. SMART/RAID reportan arrays degradados o errores medios (aplica tooling del proveedor).
3. Errores de BD de pmxcfs coinciden con errores de disco del kernel.
4. El problema vuelve tras “arreglar” servicios sin cambios de configuración.

Si cualquiera de estos es verdadero, tu prioridad es la integridad de datos y estabilidad, no “conseguir luces verdes en la UI”.

Checklist C: Prevenir la sorpresa del reinicio (controles aburridos que funcionan)

1. Añade dependencias systemd explícitas para tu pila de almacenamiento (iSCSI antes de LVM, reachability de red antes de NFS).
2. Evita rutas de dispositivo frágiles; prefiere identificadores estables (WWN, by-id). Si usas multipath, hazlo determinista.
3. Asegura que el clúster tenga un número impar de votantes o un dispositivo de quórum apropiado.
4. Mantén backups de /etc/pve y prueba restauraciones según un calendario, no durante un incidente.
5. Simulacros de reinicio: reinicia un nodo durante horario laboral ocasionalmente. Si eso te asusta, ese es el punto.

Datos interesantes y contexto histórico

• pmxcfs es un sistema de archivos FUSE. Por eso /etc/pve puede “desaparecer” sin borrar nada — es un punto de montaje para un proceso en espacio de usuario.
• La prevención de split-brain guía el diseño. Las pilas de clúster suelen bloquear escrituras sin quórum porque la alternativa es corromper el estado entre nodos en silencio.
• Corosync ha sido un pilar de HA en Linux por años. Se usa como capa de mensajería de clúster en múltiples ecosistemas HA, no solo en Proxmox.
• systemd cambió la forma de pensar el orden de arranque. El paso de scripts secuenciales a activación paralela de unidades hizo que las condiciones de carrera sean más comunes — y más sutiles.
• network-online no es lo mismo que network-reachable. systemd puede declarar victoria mientras tu VLAN de almacenamiento sigue negociando, falta enrutamiento o DNS está mal.
• Las importaciones de ZFS son conservadoras por diseño. ZFS puede rehusar auto-importar pools en ciertas circunstancias para evitar importar el mismo pool en múltiples sistemas a la vez.
• Los puntos de montaje son solo directorios hasta que se montan. Linux te muestra felizmente un punto de montaje vacío; no te avisará que “esto normalmente es otro sistema de archivos”.
• La ubicación de la config del clúster es un compromiso. Centralizar la config mejora consistencia pero eleva la exigencia sobre el quórum y la salud del clúster; por eso los comportamientos de respaldo locales pueden ser limitados.
• La disponibilidad del almacenamiento en el arranque es un problema multinivel. Firmware, inicialización HBA, multipath, udev, red, autenticación e importación de sistema de archivos deben alinearse.

Preguntas frecuentes

1) ¿Mi configuración de Proxmox está realmente borrada si /etc/pve está vacío?

Normalmente no. La situación más común es que pmxcfs no se montó, así que estás viendo el directorio subyacente vacío.
Confirma con findmnt /etc/pve.

2) ¿Por qué esto aparece después de un reinicio y no durante el tiempo de ejecución normal?

Los reinicios remezclan la temporización: descubrimiento de dispositivos, disponibilidad de red, membresía del clúster y orden de servicios.
Las carreras en el arranque son educadas durante el uptime y descorteses durante el arranque.

3) ¿Puedo simplemente recrear /etc/pve y copiar archivos de vuelta?

No lo hagas. /etc/pve es un punto de montaje para pmxcfs. Copiar archivos en el directorio subyacente no arreglará el problema real,
y puede confundir futuras investigaciones.

4) ¿Qué pasa si pmxcfs está montado pero la GUI sigue pareciendo mal?

Entonces céntrate en quórum y salud de corosync, o en la disponibilidad del almacenamiento. Un pmxcfs montado significa que el endpoint existe;
no garantiza que las operaciones de clúster estén permitidas o que los almacenamientos estén disponibles.

5) ¿Es seguro reiniciar pve-cluster y corosync en un nodo de producción?

Puede serlo, pero solo después de entender el estado actual del clúster. Reiniciar corosync en el nodo equivocado en el momento equivocado puede empeorar una caída.
Si el clúster es quorate sin este nodo, aíslalo y arréglalo sin desestabilizar el resto.

6) Mi clúster no tiene quórum. ¿Puedo forzarlo?

Puedes, y puede que te arrepientas. Forzar quórum puede permitir escrituras que lleven a split-brain cuando la otra partición vuelva.
Hazlo solo si has confirmado que el otro lado está realmente perdido y aceptas el trabajo de reconciliación posterior.

7) ¿Por qué las fallas de almacenamiento hacen que /etc/pve parezca vacío?

No lo hacen directamente — pmxcfs es separado. Pero las fallas de almacenamiento a menudo coexisten con cambios de temporización en el arranque y fallos de servicio,
y producen síntomas similares: discos de VM faltantes, almacenamientos ausentes, servicios fallidos y una sensación general de que la realidad es opcional.

8) ¿Cuál es el comando único más útil para empezar?

findmnt /etc/pve. Te dice si estás lidiando con un problema de montaje/servicio o persiguiendo fantasmas en un directorio vacío.

9) ¿Cómo prevengo que esto vuelva a ocurrir en Debian 13?

Haz explícito el orden de arranque para dependencias de almacenamiento, asegura nombres de dispositivo estables, valida las interfaces de corosync tras las actualizaciones,
y prueba reinicios como si realmente importara.

10) Si la BD de pmxcfs está corrupta, ¿necesito reinstalar?

No siempre, pero a veces reinstalar y volver a unir el nodo al clúster es la vía más limpia — especialmente si también hay errores de disco.
Trata la corrupción junto con errores de E/S como un problema de hardware/almacenamiento primero.

Conclusión: pasos siguientes que realmente previenen repeticiones

Cuando /etc/pve parece vacío tras un reinicio en Debian 13, asume primero un problema de montaje/servicio, no pérdida de datos.
Confirma si pmxcfs está montado. Lee los logs. Revisa el quórum. Luego comprueba la disponibilidad del almacenamiento y el orden en systemd.
Esa secuencia ahorra horas porque reduce rápidamente el dominio de fallo.

Pasos prácticos siguientes:

1. Ejecuta la guía rápida de diagnóstico y anota qué falló (pmxcfs, corosync/quorum, ZFS/LVM, montajes remotos).
2. Si el problema es orden de arranque, arréglalo con dependencias systemd apropiadas — no con hacks de sleep.
3. Si ves errores de E/S, trátalo como un incidente de almacenamiento y deja de “reiniciar hasta que funcione”.
4. Programa un simulacro de reinicio y un simulacro de restauración de configuración. El día que practicas estarás tranquilo.