Proxmox “backup storage not available on node”: por qué “shared” no es compartido

Qué significa realmente “shared” en Proxmox (y qué no)

En Proxmox VE, un “storage” es un objeto de configuración definido en /etc/pve/storage.cfg. Esa configuración puede estar en el clúster (replicada entre nodos vía pmxcfs) o ser local a un nodo. La bandera “shared” es la forma en que Proxmox indica: “Espero que este almacenamiento sea accesible desde varios nodos, y lo trataré en consecuencia al ubicar discos de VM, hacer migraciones y ejecutar backups.”

No significa que Proxmox hará lo siguiente:

• Montar NFS/CIFS por ti en cada nodo.
• Crear rutas idénticas en todos los nodos.
• Arreglar permisos, mapeo UID/GID o root squashing.
• Asegurar que exista la ruta de red desde cada nodo.
• Mantener sincronizadas tus unidades de montaje systemd fuera de banda.

La casilla de la GUI de Proxmox es un contrato. Lo firmaste. Ahora tienes que cumplirlo.

Hay dos interpretaciones comunes de “shared” en la práctica:

1. Compartido a nivel de almacenamiento: NFS/CIFS, iSCSI+LVM, FC SAN, Ceph, Gluster, PBS (en cierto sentido). Varios nodos pueden acceder al mismo backend.
2. Compartido a nivel de configuración: la definición del almacenamiento existe a nivel de clúster para que cualquier nodo pueda intentar usarla.

El error que ves ocurre cuando lo segundo es verdadero (o al menos está configurado), pero lo primero es falso en tiempo de ejecución.

Regla opinada: si es “shared”, cada nodo debe poder ejecutar touch dentro de él sin adivinar. Eso significa: el montaje está presente, la ruta existe, los permisos permiten escritura y el backend es alcanzable. Cualquier cosa por debajo de eso es un incidente en potencia.

Una verdad seca: los sistemas de almacenamiento no se preocupan por lo que diga la casilla de la GUI. Les importa lo que tu kernel pueda montar y lo que tu proceso pueda escribir.

Guion rápido de diagnóstico

Cuando necesitas respuestas rápidas, no divagues. Ejecuta esto como una lista de comprobación. El objetivo es encontrar dónde se rompe “shared”: configuración, punto de montaje, red, permisos o identidad.

Primero: confirma qué nodo falla y qué almacenamiento cree Proxmox que está usando

1. Mira el historial del trabajo de backup: ¿qué nodo lo ejecutó? Si tienes un clúster, los trabajos pueden ejecutarse en varios nodos según dónde esté la VM.
2. Identifica el ID del almacenamiento (p. ej., backup-nfs, pbs01).
3. Comprueba que Proxmox lo vea como “active” en ese nodo.

Segundo: demuestra que el punto de montaje/ruta existe en el nodo que falla

1. pvesm status y pvesm path para ese almacenamiento.
2. findmnt para el punto de montaje.
3. Crea un archivo de prueba como root en el directorio objetivo.

Tercero: aísla red vs permisos vs mapeo de identidad

1. Red: ping, nc (para PBS), showmount (para NFS), sondeo SMB para CIFS.
2. Permisos: prueba touch, comprueba propiedad y modo, inspecciona opciones de exportación NFS (root_squash y similares).
3. Identidad: comprueba si el proceso de backup corre como root; confirma si el lado remoto espera root o mapea root.

Cuarto: comprueba la consistencia de la configuración del clúster y síntomas de split-brain

1. pvecm status para quorum.
2. Verifica que el contenido de /etc/pve/storage.cfg sea idéntico en todos los nodos (normalmente lo es, salvo que pmxcfs esté disgustado o alguien editó archivos locales incorrectamente).
3. Comprueba la sincronización horaria; SMB basado en Kerberos y algunas configuraciones TLS se vuelven problemáticas cuando los relojes se desincronizan.

Detente pronto cuando encuentres la primera capa rota. Arreglar permisos no ayudará si el montaje nunca existió. Reiniciar no ayudará si apuntas a un nombre DNS equivocado desde un nodo.

Hechos e historia que explican la trampa

• Hecho 1: El sistema de archivos del clúster de Proxmox (pmxcfs) es un almacén de configuración replicado en espacio de usuario. Distribuye configuración, no montajes ni el estado del kernel.
• Hecho 2: El atributo “shared” es anterior a la expectativa actual de “semántica cloud” de muchas personas. Proviene de una era en la que los administradores sabían que montar NFS era su trabajo, no del hipervisor.
• Hecho 3: En Linux, un montaje es estado del kernel por nodo. Ningún archivo de configuración de clúster puede “compartir” un montaje a menos que lo despliegues en cada nodo.
• Hecho 4: El comportamiento root_squash de NFS es un valor de seguridad por defecto que con frecuencia choca con software de backup que corre como root. No es un bug de Proxmox; es tu política de seguridad encontrándose con tus suposiciones.
• Hecho 5: Las “permisiones” de CIFS/SMB son una tarta de muchas capas: ACLs del servidor, permisos del recurso compartido, opciones de montaje del cliente y a veces mapeo de IDs. Es impresionante cuando funciona.
• Hecho 6: Proxmox Backup Server (PBS) no es un montaje de sistema de archivos; es un datastore respaldado por API con chunking y deduplicación. Los errores de disponibilidad allí suelen ser de red/TLS/autenticación, no “montaje ausente”.
• Hecho 7: Los plugins de almacenamiento de Proxmox suelen realizar comprobaciones intentando acceder a rutas o ejecutar operaciones; “not available” puede significar “no se puede stat del directorio”, “tipo de contenido erróneo” o “backend inalcanzable”.
• Hecho 8: Systemd cambió las reglas para los montajes: x-systemd.automount puede hacer montajes “perezosos”, lo cual es excelente para velocidad de arranque y terrible para trabajos de backup con ventanas de tiempo ajustadas si está mal configurado.

Una cita que debería estar en cada manual de on-call:

“La esperanza no es una estrategia.” — idea parafraseada atribuida a muchos líderes de operaciones

El almacenamiento compartido es uno de esos lugares donde la esperanza aparece con una camiseta que dice “funciona en mi nodo”.

Broma #1: El almacenamiento “shared” es como la responsabilidad “compartida” en un postmortem: todos acuerdan que existe y nadie está seguro de quién lo posee.

Por qué el almacenamiento aparece “no disponible”: modos reales de fallo

1) La definición de almacenamiento está en el clúster, pero el backend no está montado en cada nodo

Este es el clásico. El almacenamiento está definido como dir o NFS/CIFS, pero solo un nodo tiene el montaje o directorio real. Otro nodo intenta ejecutar un job de backup y encuentra un directorio vacío, un punto de montaje faltante o una ruta local que no es lo que creías.

2) El montaje existe, pero está montado de forma diferente (opciones, versiones, rutas)

NFSv3 en un nodo y NFSv4 en otro. Diferente rsize/wsize. Diferente vers=. Caché de credenciales distinta para SMB. O peor: un nodo montó un export distinto con el mismo punto de montaje. La GUI no grita; simplemente falla después.

3) Permisos: root squashed, mismatch de ACL o propietario equivocado

VZDump y muchas operaciones de Proxmox corren como root. Si tu servidor NFS mapea root a nobody y tu directorio no es escribible para ese usuario, Proxmox recibe un error de E/S o permiso y reporta “not available” o fallo de backup. Podrías ver el almacenamiento como “active”, pero las escrituras fallan.

4) Asimetría de DNS/ruteo entre nodos

El nodo A puede resolver nas01 a la IP correcta. El nodo B la resuelve a una IP antigua, a otra VLAN o a una interfaz muerta. O un nodo enruta a través de un firewall que bloquea puertos NFS. El almacenamiento “funciona” hasta que un job cae en el nodo equivocado.

5) Problemas de estado del clúster: pérdida de quorum o rarezas de pmxcfs

Si un nodo pierde quorum, algunas operaciones de clúster están restringidas. La configuración de almacenamiento podría ser legible pero los cambios no propagarse como esperas. Además, un nodo con el filesystem del clúster enfermo puede presentar configuración obsoleta. Es menos frecuente, pero real.

6) El destino de backup no es “almacenamiento” en sentido de sistema de archivos (PBS)

Los fallos de PBS aparecen como fallos de almacenamiento en la GUI porque Proxmox lo trata como un backend. Pero las causas raíz son distintas: huellas digitales expiradas, problemas TLS, tokens de autenticación, datastore eliminado o puerto de red bloqueado.

7) Orden de arranque y montajes con “nofail” crean una bomba de tiempo

nofail en /etc/fstab permite que el nodo arranque incluso si el NAS está caído. Genial. Pero ahora el nodo está “arriba” y puede programar backups, mientras que el directorio de backup es en realidad solo una carpeta local vacía. Eso no es una copia de seguridad; es arte conceptual.

Broma #2: Una copia de seguridad que escribe en un directorio no montado es el desastre de Schrödinger: a la vez tuvo éxito y falló hasta que necesitas restaurar.

Tareas prácticas (comandos, salidas, decisiones)

Estas son las tareas que ejecuto al diagnosticar “backup storage not available on node”. Cada una incluye un comando realista, un fragmento plausible de salida y qué decisión tomar a partir de ello. Ejecútalas primero en el nodo que falla, luego compáralas con un nodo conocido bueno.

Task 1: Identify storage status from Proxmox’s point of view

cr0x@pve2:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active       98.00GiB        21.13GiB        71.87GiB   21.56%
backup-nfs        nfs     inactive            0B             0B              0B    0.00%
pbs01             pbs     active             n/a            n/a             n/a      n/a

Qué significa: Proxmox cree que backup-nfs está inactivo en este nodo. Eso no es un problema a nivel de VM; es un problema de montaje/alcanzabilidad.

Decisión: Omite el troubleshooting a nivel de VM. Arregla primero el backend de almacenamiento.

Task 2: Confirm the storage configuration exists and is marked shared

cr0x@pve2:~$ grep -A6 -n "backup-nfs" /etc/pve/storage.cfg
18:nfs: backup-nfs
19:        export /exports/pve-backups
20:        path /mnt/pve/backup-nfs
21:        server nas01
22:        content backup
23:        prune-backups keep-last=7
24:        shared 1

Qué significa: El almacenamiento está configurado a nivel de clúster como NFS, tipo de contenido “backup” y “shared 1”.

Decisión: Ahora demuestra que el path está realmente montado y escribible.

Task 3: Ask Proxmox where it expects the path to be

cr0x@pve2:~$ pvesm path backup-nfs
/mnt/pve/backup-nfs

Qué significa: Ese es el punto de montaje que Proxmox usará.

Decisión: Valida el estado de montaje del kernel en esa ruta.

Task 4: Verify the mount is real (not just an empty directory)

cr0x@pve2:~$ findmnt /mnt/pve/backup-nfs

Qué significa: No obtener salida normalmente significa “no montado”. Si devuelve una línea NFS, estás montado.

Decisión: Si no está montado, revisa /etc/fstab y unidades systemd; si está montado, pasa a permisos y conectividad.

Task 5: Compare with a known-good node to catch “same name, different mount”

cr0x@pve1:~$ findmnt /mnt/pve/backup-nfs
TARGET               SOURCE                FSTYPE OPTIONS
/mnt/pve/backup-nfs  nas01:/exports/pve-backups nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Qué significa: Esto es lo que se ve “bien”: servidor correcto, export correcto, punto de montaje correcto.

Decisión: Haz que el nodo que falla coincida con esto, byte por byte cuando sea posible.

Task 6: Attempt to mount (and capture the actual error)

cr0x@pve2:~$ mount -av
/                        : ignored
/mnt/pve/backup-nfs       : mount.nfs4: Connection timed out

Qué significa: Problema de alcanzabilidad de red a nas01 (ruteo, firewall, DNS o NAS caído).

Decisión: Para y arregla la red antes de tocar permisos o ajustes de Proxmox.

Task 7: Test DNS and routing symmetry

cr0x@pve2:~$ getent hosts nas01
10.20.30.50   nas01

Qué significa: El nodo resuelve nas01 a una IP. Eso no prueba que sea la IP correcta.

Decisión: Compara la salida entre nodos. Si difiere, arregla DNS/hosts. Si es igual, comprueba conectividad a esa IP.

Task 8: Prove network reachability (ICMP is not enough, but it’s a start)

cr0x@pve2:~$ ping -c 2 10.20.30.50
PING 10.20.30.50 (10.20.30.50) 56(84) bytes of data.
64 bytes from 10.20.30.50: icmp_seq=1 ttl=63 time=0.462 ms
64 bytes from 10.20.30.50: icmp_seq=2 ttl=63 time=0.497 ms

--- 10.20.30.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 0.462/0.479/0.497/0.017 ms

Qué significa: El host es alcanzable, pero NFS aún podría estar bloqueado.

Decisión: Prueba NFS específicamente (portmapper para v3, 2049 para v4).

Task 9: Test NFS service reachability

cr0x@pve2:~$ nc -vz 10.20.30.50 2049
Connection to 10.20.30.50 2049 port [tcp/nfs] succeeded!

Qué significa: Puerto TCP NFSv4 accesible. Si esto falla, es firewall/ruteo o servicio NAS caído.

Decisión: Si es accesible, revisa exports y permisos; si no, arregla red/seguridad primero.

Task 10: Verify the export exists (server-side view via showmount)

cr0x@pve2:~$ showmount -e nas01
Export list for nas01:
/exports/pve-backups 10.20.30.0/24

Qué significa: El NAS afirma exportar la ruta a tu subred.

Decisión: Si tu nodo no está en esa subred (otra VLAN), has encontrado la discrepancia.

Task 11: If mounted, validate you can write as root (the backup reality)

cr0x@pve2:~$ sudo sh -c 'touch /mnt/pve/backup-nfs/.pve-write-test && ls -l /mnt/pve/backup-nfs/.pve-write-test'
-rw-r--r-- 1 root root 0 Dec 26 03:12 /mnt/pve/backup-nfs/.pve-write-test

Qué significa: Root puede crear archivos. Eso es lo mínimo para almacenamiento de backup.

Decisión: Si esto falla con “Permission denied”, inspecciona opciones de exportación NFS y permisos del directorio.

Task 12: Detect root squashing (common on NFS) from the client side

cr0x@pve2:~$ stat -c "%U %G %a %n" /mnt/pve/backup-nfs
nobody nogroup 755 /mnt/pve/backup-nfs

Qué significa: El servidor puede estar mapeando root a nobody, y el modo del directorio no es escribible.

Decisión: O ajustas opciones de exportación (con cuidado) o creas un usuario de servicio dedicado y alinear UID/GID entre nodos y NAS.

Task 13: Check for the “mounted but stale” condition (NFS hiccups)

cr0x@pve2:~$ timeout 5 ls -la /mnt/pve/backup-nfs | head
total 16
drwxr-xr-x  2 root root 4096 Dec 26 02:10 .
drwxr-xr-x 10 root root 4096 Dec 26 01:55 ..
-rw-r--r--  1 root root    0 Dec 26 03:12 .pve-write-test

Qué significa: La lista de directorio responde rápidamente. Si cuelga hasta el timeout, probablemente tengas un montaje stale o fluctuaciones de red.

Decisión: Investiga estabilidad de red, carga del servidor NFS, y considera montajes hard con timeouts sensatos; evita “soft” para integridad de backups.

Task 14: For CIFS/SMB-based backup storage, verify mount options and credential use

cr0x@pve3:~$ findmnt /mnt/pve/backup-smb
TARGET               SOURCE                       FSTYPE OPTIONS
/mnt/pve/backup-smb  //files01/backups            cifs   rw,relatime,vers=3.1.1,cache=strict,username=svc_pve,uid=0,gid=0,file_mode=0640,dir_mode=0750

Qué significa: Existe el montaje SMB y mapea la propiedad a root. Eso es común para destinos de backup de Proxmox.

Decisión: Si a un nodo le falta este montaje o usa credenciales distintas, estandariza vía /etc/fstab o una unidad systemd desplegada uniformemente.

Task 15: For Proxmox Backup Server storage, validate API reachability and auth

cr0x@pve2:~$ nc -vz pbs01 8007
Connection to pbs01 8007 port [tcp/*] succeeded!

Qué significa: La ruta de red al API de PBS está abierta. Eso es el primer paso.

Decisión: Si está bloqueado, arregla firewall/VLAN. Si está abierto, comprueba configuración de almacenamiento en Proxmox y certificados/huella.

Task 16: Inspect backup job logs for the exact storage-related failure

cr0x@pve2:~$ journalctl -u pvedaemon -u pvescheduler --since "today" | grep -i backup | tail -n 12
Dec 26 02:01:01 pve2 pvescheduler[1890]: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot
Dec 26 02:01:02 pve2 vzdump[2033]: ERROR: storage 'backup-nfs' is not available on node 'pve2'
Dec 26 02:01:02 pve2 vzdump[2033]: INFO: Failed at 2025-12-26 02:01:02

Qué significa: El error proviene de la herramienta de backup que invoca comprobaciones de almacenamiento. No es un fallo de snapshot de VM; es disponibilidad de almacenamiento.

Decisión: Centra el esfuerzo en por qué pvesm status muestra inactivo o por qué la comprobación de ruta falla.

Task 17: Confirm the node is healthy in the cluster (quorum and membership)

cr0x@pve2:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 03:18:10 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000002
Ring ID:          1.10
Quorate:          Yes

Qué significa: El clúster tiene quórum. No estás depurando almacenamiento bajo una partición de clúster (bien).

Decisión: Si Quorate: No, estabiliza el clúster primero; la configuración de almacenamiento y el scheduling de jobs pueden volverse impredecibles.

Task 18: Validate time sync (quiet cause of TLS and SMB weirdness)

cr0x@pve2:~$ timedatectl
               Local time: Fri 2025-12-26 03:19:44 UTC
           Universal time: Fri 2025-12-26 03:19:44 UTC
                 RTC time: Fri 2025-12-26 03:19:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: El reloj está sincronizado. Esto reduce la probabilidad de fallos de handshake TLS con PBS o casos límite de autenticación SMB.

Decisión: Si está desincronizado, arregla el tiempo primero. Es aburrido y funciona.

Task 19: Check that the storage mount survives reboot the way you think it does

cr0x@pve2:~$ grep -n "backup-nfs" /etc/fstab
12:nas01:/exports/pve-backups /mnt/pve/backup-nfs nfs4 rw,hard,timeo=600,retrans=2,_netdev 0 0

Qué significa: Existe una entrada en fstab. Bien. Las opciones importan.

Decisión: Si falta en un nodo, por eso “shared” no es compartido. Estandariza montajes entre nodos.

Task 20: Spot the dangerous “nofail” + local directory trap

cr0x@pve2:~$ grep -n "backup-nfs" /etc/fstab
12:nas01:/exports/pve-backups /mnt/pve/backup-nfs nfs4 rw,nofail,_netdev 0 0

Qué significa: Si NFS está caído al arranque, el montaje podría no ocurrir, pero el directorio seguirá existiendo y los jobs podrían escribir localmente.

Decisión: Sustituye por automount de systemd o por un orden explícito de dependencias para que los servicios no continúen sin almacenamiento (detalles en la sección de checklist).

Tres minucuentos corporativos desde el campo

Mini-cuento 1: El incidente causado por una suposición equivocada

Tenían un clúster Proxmox de tres nodos y un almacenamiento “backup” apuntando a un share NFS. El administrador que lo configuró hizo lo correcto en la GUI: añadió almacenamiento NFS, marcó “Shared” y puso el contenido en “VZDump backup file”. Todos asintieron.

Las copias de seguridad funcionaron durante semanas. Eso es lo peligroso. La única razón por la que funcionaban es que la mayoría de las VM “importantes” vivían en el nodo 1 por razones históricas, y el horario de backups corría cuando el nodo 1 estaba sano.

Entonces, una ventana de mantenimiento movió un lote de VMs al nodo 2. Las siguientes copias nocturnas se ejecutaron desde el nodo 2. El almacenamiento reportó “not available on node.” Alguien reejecutó trabajos manualmente en el nodo 1 y lo llamó “temporal”. Dos días después, el nodo 1 tuvo un reinicio no planeado y la empresa descubrió que “temporal” es otra palabra para “permanente”.

La causa raíz no fue exótica: solo el nodo 1 tenía una entrada en /etc/fstab para el share NFS. El nodo 2 y 3 tenían creado el directorio /mnt/pve/backup-nfs (creado por Proxmox), pero no estaba montado. El equipo asumió que la configuración del clúster lo hacía “shared”. No lo hacía.

La solución tampoco fue exótica: configuración de montaje idéntica desplegada vía automatización, más una comprobación canario en monitorización: “¿está esta ruta montada y escribible?”. Los incidentes rara vez necesitan ingenio. Necesitan disciplina.

Mini-cuento 2: La optimización que se volvió en contra

Otra compañía quiso arranques más rápidos y menos incidentes de “nodo atascado en arranque esperando NAS”. Cambiaron montajes NFS para incluir nofail y añadieron ajustes systemd para que el hipervisor subiera aunque el almacenamiento estuviera caído.

Los tiempos de arranque mejoraron. En papel. En la práctica, cambiaron un modo de fallo por uno más furtivo: los nodos subían, la GUI de Proxmox parecía saludable y los jobs de backup se ejecutaban. Pero en las mañanas en que el NAS respondía lento, los montajes no sucedían a tiempo. La ruta de backup existía como directorio normal, así que el job escribió en disco local.

El disco local se llenó. Las VMs empezaron a pausarse. Los logs explotaron. El equipo de almacenamiento fue alertado por “rendimiento NAS” aunque el NAS estaba bien: Proxmox había desviado silenciosamente la carga al almacenamiento local porque el montaje no estaba presente.

Lo arreglaron usando x-systemd.automount (acceso dispara el montaje), eliminando el riesgo de “escritura local” haciendo que el punto de montaje sea propiedad de root y no escribible mientras no está montado, y añadiendo un hook pre-backup para validar el estado del montaje. La moraleja: optimizar arranque sin pensar en las semánticas de fallo es cómo creas sistemas embrujados.

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

Una empresa de servicios financieros ejecutaba Proxmox con PBS como objetivo principal de backup y NFS como una ubicación secundaria de exportación. No eran gente emocionante. Lo documentaron todo y probaron restauraciones trimestralmente. Por eso dormían tranquilos.

Un fin de semana, una actualización de firmware en un switch core introdujo un cambio de ACL que bloqueó TCP/8007 desde un rack. Dos de cuatro nodos Proxmox podían alcanzar PBS; dos no. Los backups empezaron a fallar solo para VMs corriendo en los nodos aislados.

Lo detectaron en una hora porque su monitorización no solo miraba “backup job success”. Miraba la alcanzabilidad de almacenamiento desde cada nodo. La alerta decía, esencialmente, “pve3 no puede alcanzar pbs01:8007”. Sin adivinar, sin arqueología.

Conmutaron fallos fijando jobs de backup a nodos saludables temporalmente y luego revirtieron el cambio de ACL. Después añadieron en la gestión de cambios un paso: “validar conectividad PBS desde cada hipervisor”. Aburrido. Correcto. Salvó el día.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “storage is not available on node” solo en un nodo

Causa raíz: El montaje existe solo en algunos nodos, o DNS resuelve distinto por nodo.

Solución: Estandariza montajes vía /etc/fstab o unidades systemd en todos los nodos; verifica con findmnt y getent hosts en cada nodo.

2) Síntoma: almacenamiento aparece “active”, pero los backups fallan con errores de permisos o “cannot create file”

Causa raíz: NFS root_squash, mismatch de ACL SMB, o propiedad/mode incorrectos en el directorio objetivo.

Solución: Decide tu modelo de seguridad: o permites escrituras de root en el export (con precaución) o mapeas a un usuario de servicio dedicado con UID/GID consistentes; luego prueba con touch como root.

3) Síntoma: backups “s succeeding” pero el uso de espacio está en disco local, no en NAS

Causa raíz: Montaje no presente; las escrituras fueron al directorio de punto de montaje en el sistema de archivos local (a menudo por nofail al arranque).

Solución: Elimina la trampa. Usa automount de systemd o exige disponibilidad de montaje antes de que el scheduler corra; haz que el punto de montaje no sea escribible cuando no esté montado; monitoriza “está montado” y no “directorio existe”.

4) Síntoma: el montaje NFS funciona manualmente pero no durante el arranque

Causa raíz: La red no está lista cuando se intenta montar; falta _netdev o hay problemas de orden con systemd.

Solución: Añade _netdev, considera x-systemd.automount y asegura el objetivo network-online si es necesario. Valida con una prueba de reinicio.

5) Síntoma: solo fallan los storages respaldados por PBS, los sistemas de archivos funcionan

Causa raíz: Puerto bloqueado, desajuste TLS/huella, token de autenticación revocado o datastore renombrado/eliminado en PBS.

Solución: Verifica conectividad TCP/8007, valida la configuración de almacenamiento de PBS, reaprueba la huella si cambió intencionalmente y confirma que el datastore existe.

6) Síntoma: almacenamiento intermitentemente “inactive” con NFS bajo carga

Causa raíz: Fluctuaciones de red, saturación del servidor NFS, handles stale o timeouts demasiado agresivos.

Solución: Estabiliza la red, ajusta el servidor NFS, usa montajes hard con timeouts sensatos y considera separar tráfico de backup en una VLAN/interface dedicada.

7) Síntoma: después de añadir un nodo nuevo, los backups fallan solo en ese nodo

Causa raíz: El nodo nuevo no recibió la configuración OS-level de montaje, reglas de firewall, dominios de búsqueda DNS o entradas de confianza CA.

Solución: Trata el aprovisionamiento del nodo como código. Aplica la misma política de montaje y red que los nodos existentes antes de ponerlo en rotación.

8) Síntoma: la configuración de almacenamiento parece correcta, pero el nodo se comporta como si no estuviera en el clúster

Causa raíz: Pérdida de quorum, problemas de corosync o pmxcfs.

Solución: Restaura la salud del clúster primero. Valida pvecm status, la red entre nodos y la estabilidad del anillo corosync.

Listas de verificación / plan paso a paso

Paso a paso: hacer que “shared” sea realmente compartido (estilo directorio NFS/CIFS)

1. Elige un ID de almacenamiento canónico y un punto de montaje. Ejemplo: backup-nfs montado en /mnt/pve/backup-nfs.

   No crees variaciones por nodo como /mnt/pve/backup-nfs2 “solo por ahora”. “Solo por ahora” es cómo terminas con trabajos de arqueología.

2. Estandariza la resolución de nombres. Usa getent hosts nas01 en todos los nodos y asegúrate de que resuelva idénticamente. Si debes fijar, usa /etc/hosts de forma consistente.

3. Despliega configuración de montaje idéntica en cada nodo. Usa /etc/fstab o unidades systemd. La clave es comportamiento idéntico en reinicios.

   Ejemplo mínimo NFSv4:

   cr0x@pve1:~$ sudo sh -c 'printf "%s\n" "nas01:/exports/pve-backups /mnt/pve/backup-nfs nfs4 rw,hard,timeo=600,retrans=2,_netdev 0 0" >> /etc/fstab'
   

   Decisión: Si necesitas que el nodo arranque aunque el NAS esté caído, no añadas nofail a la ligera. Usa automount con protecciones.

4. Si usas automount de systemd, hazlo deliberadamente. Evita colisiones en el arranque y reduce carreras de “montaje no listo”.

   Ejemplo de opciones de montaje en fstab:

   cr0x@pve1:~$ sudo sed -i 's#nfs4 rw,hard,timeo=600,retrans=2,_netdev#nfs4 rw,hard,timeo=600,retrans=2,_netdev,x-systemd.automount,x-systemd.idle-timeout=600#' /etc/fstab
   

   Decisión: Si tu carga incluye ventanas de backup ajustadas, valida la latencia del automount bajo carga.

5. Aplica “no montado significa no escribible”. Una táctica práctica: haz que el punto de montaje sea propiedad de root y modo 000 cuando no esté montado; deja que el montaje sobreescriba los permisos. Esto reduce sorpresas de “escrituras locales”. Prueba con cuidado para que Proxmox aún pueda montar.

6. Valida en cada nodo: montaje existe, escritura funciona, latencia aceptable.

   cr0x@pve2:~$ sudo mount -a && findmnt /mnt/pve/backup-nfs && sudo sh -c 'dd if=/dev/zero of=/mnt/pve/backup-nfs/.speedtest bs=1M count=64 conv=fdatasync' 
   64+0 records in
   64+0 records out
   67108864 bytes (67 MB, 64 MiB) copied, 0.88 s, 76.6 MB/s
   

   Decisión: Si el rendimiento es muy distinto por nodo, probablemente tengas diferencias de ruteo, problemas de NIC o un problema en el camino del switch.

7. Confirma que Proxmox lo vea activo en todas partes.

   cr0x@pve3:~$ pvesm status | grep backup-nfs
   backup-nfs        nfs     active        9.09TiB         3.21TiB         5.88TiB   35.31%
   

   Decisión: Solo después de esto considera ajustes en la planificación de jobs de backup.

8. Añade monitorización que compruebe montaje y escribibilidad desde cada nodo. La comprobación debe ser deliberadamente simple: “está montado” y “puedo crear un archivo” y “el tipo de FS es el esperado”.

Paso a paso: PBS-backed “storage not available”

1. Confirma alcanzabilidad TCP a PBS en el puerto 8007 desde cada nodo. Usa nc -vz.
2. Confirma que el almacenamiento está activo en pvesm status. Si está inactivo, suele ser conectividad o autenticación.
3. Valida sincronización horaria. TLS odia los viajes en el tiempo.
4. Confirma que el datastore PBS existe y no fue renombrado. La configuración puede sobrevivir al recurso al que apunta.
5. Sé estricto con certificados y huellas. Si una huella cambió inesperadamente, trátalo como un evento de seguridad hasta que se pruebe lo contrario.

Paso a paso: hacer backups resilientes sin engañarte

1. Prefiere PBS para deduplicación e integridad. Usa shares de filesystem como exportación secundaria/replicación, no como única línea de vida.
2. Mantén un fallback local solo si lo monitorizas. Un directorio local de backup puede salvarte durante una caída del NAS, pero solo si monitorizas la presión de disco local y rotas agresivamente.
3. Prueba restauraciones. No una vez. Regularmente. Un backup que no has restaurado es un rumor.

FAQ

1) ¿Qué significa “storage is not available on node” en Proxmox?

Significa que el nodo que ejecuta la operación (a menudo vzdump) no puede acceder a ese backend de almacenamiento en ese momento. Típicamente: no montado, inalcanzable, credenciales incorrectas o permiso denegado.

2) Si el almacenamiento está marcado “Shared”, ¿por qué Proxmox no lo monta en todas partes?

Porque Proxmox gestiona definiciones de almacenamiento, no montajes del kernel. Montar es estado a nivel OS. Debes configurar montajes en cada nodo (o usar un backend que sea inherentemente compartido, como Ceph).

3) ¿Puedo arreglar esto desmarcando “Shared”?

Puedes silenciar algunas expectativas de scheduling y migración, pero no arreglarás el problema subyacente. Si varios nodos necesitan hacer backups allí, debe ser accesible desde varios nodos. Haz que la realidad coincida con la casilla, no al revés.

4) ¿Por qué falla solo a veces?

Porque solo algunos backups se ejecutan en el nodo que no puede acceder al almacenamiento, o porque los montajes son inestables (demoras de automount, picos de red, carga del NAS). Las fallas intermitentes siguen siendo fallas; solo esperan tu peor día.

5) ¿Cuál es la diferencia entre almacenamiento NFS para backups y almacenamiento PBS en Proxmox?

NFS es una ruta de sistema de archivos montada. PBS es un datastore basado en API con deduplicación, compresión, verificación y políticas de pruning. Depurar disponibilidad de PBS es más parecido a depurar una dependencia de aplicación que a un montaje.

6) Mi share NFS se monta, pero los backups fallan con “Permission denied”. ¿Qué hago?

Revisa root_squash y permisos del directorio. Los jobs de backup de Proxmox suelen necesitar que root escriba. O permites escribidas de root en ese export (compensando riesgos) o mapeas a una identidad de servicio dedicada con UID/GID consistentes y permisos adecuados.

7) ¿Cómo evito que los backups escriban en disco local cuando falta el montaje NFS?

No confíes en la existencia del directorio. Haz comprobaciones de montaje: usa automount de systemd y/o haz el punto de montaje no escribible cuando no esté montado, y monitoriza “está montado” además de “prueba de escritura”. Evita nofail casual sin protecciones.

8) ¿El quórum del clúster afecta la disponibilidad del almacenamiento?

No directamente para montajes, pero la pérdida de quórum puede hacer que servicios de clúster y distribución de configuración se comporten distinto. Si un nodo no tiene quórum, restaura la salud del clúster primero para no depurar dos problemas a la vez.

9) ¿Está bien tener distintas opciones de montaje en distintos nodos si “todavía funciona”?

Funciona hasta que no. Diferentes versiones de NFS u opciones de montaje pueden cambiar comportamiento de locking, rendimiento y semánticas de fallo. Estandariza. Tu yo del futuro te lo agradecerá.

10) ¿Debería usar CIFS/SMB para backups de Proxmox?

Puedes, pero suele ser más frágil que NFS en entornos de hipervisores Linux debido a la complejidad de autenticación y ACLs. Si debes usarlo, estandariza opciones de montaje y credenciales entre nodos y prueba el comportamiento ante fallos.

Conclusión: pasos siguientes para evitar repetición

“Backup storage not available on node” es Proxmox diciéndote la verdad. La parte desagradable es que la verdad vive debajo de la GUI: montajes, redes, permisos, mapeo de identidades y orden de arranque.

Próximos pasos que realmente cambian resultados:

1. Elige el nodo que falla y ejecuta el guion rápido de diagnóstico. Confirma si el almacenamiento está inactivo, no montado, inalcanzable o no escribible.
2. Estandariza montajes en todos los nodos. Mismo nombre de servidor, mismo export/share, mismo punto de montaje, mismas opciones.
3. Elimina la trampa de “escrituras locales”. Si usas nofail, compénsalo con automount y monitorización.
4. Añade monitorización por nodo. Comprueba montaje + escribibilidad + tipo de sistema de archivos esperado, no solo “job de backup exitoso”.
5. Prueba una restauración. No porque sea divertido. Porque es más barato que aprender durante un outage.

Si quieres un modelo mental para retener: la casilla “Shared” es una promesa que haces a Proxmox. Cúmplela y las copias de seguridad se vuelven aburridas. Rómpela y las copias de seguridad se convierten en una sorpresa semanal.