Proxmox « stockage de sauvegarde non disponible sur le nœud » : pourquoi « partagé » n’est pas partagé

Ce que « partagé » signifie réellement dans Proxmox (et ce que ce n’est pas)

Dans Proxmox VE, un « storage » est un objet de configuration défini dans /etc/pve/storage.cfg. Cette config peut être en cluster (répliquée entre les nœuds via pmxcfs) ou locale à un nœud. Le drapeau « shared » est la façon dont Proxmox indique : « J’attends que ce stockage soit accessible depuis plusieurs nœuds, et je le traiterai en conséquence lors du placement des disques VM, des migrations et des sauvegardes. »

Cela ne signifie pas que Proxmox va :

• Monter NFS/CIFS pour vous sur chaque nœud.
• Créer des chemins identiques sur tous les nœuds.
• Corriger les permissions, le mappage UID/GID ou le root squashing.
• Garantir qu’une route réseau existe depuis chaque nœud.
• Synchroniser vos unités systemd de montage hors-bande.

La case de l’interface Proxmox est un contrat. Vous l’avez signé. Maintenant, vous devez l’honorer.

Il existe deux interprétations courantes de « partagé » dans la pratique :

1. Partage au niveau stockage : NFS/CIFS, iSCSI+LVM, FC SAN, Ceph, Gluster, PBS (dans une certaine mesure). Plusieurs nœuds peuvent accéder au même backend.
2. Partage au niveau configuration : la définition du stockage existe à l’échelle du cluster, donc n’importe quel nœud peut tenter de l’utiliser.

L’erreur que vous voyez survient quand la seconde est vraie (ou au moins configurée), mais que la première est fausse au moment de l’exécution.

Règle d’opinion : si c’est « partagé », chaque nœud doit pouvoir exécuter touch à l’intérieur sans deviner. Cela signifie : le montage est présent, le chemin existe, les permissions autorisent l’écriture, et le backend est joignable. Tout manquement est une future panne.

Une petite vérité sèche : les systèmes de stockage se moquent de la case de votre GUI. Ils se préoccupent de ce que votre kernel peut monter et de ce que votre process peut écrire.

Mode d’intervention rapide

Quand vous avez besoin de réponses vite, ne divaguez pas. Exécutez ceci comme une checklist. L’objectif est de trouver où « partagé » casse : configuration, montage, réseau, permissions ou identité.

Premier : confirmer quel nœud échoue et quel stockage Proxmox croit utiliser

1. Consultez l’historique du job de sauvegarde : quel nœud l’a exécuté ? Si vous êtes en cluster, les jobs peuvent s’exécuter sur plusieurs nœuds selon l’endroit où se trouve la VM.
2. Identifiez l’ID du stockage (par ex. backup-nfs, pbs01).
3. Vérifiez que Proxmox le voit comme « active » sur ce nœud.

Deuxième : prouver que le montage/chemin existe sur le nœud en échec

1. pvesm status et pvesm path pour ce stockage.
2. findmnt pour le point de montage.
3. Créez un fichier de test en root dans le répertoire cible.

Troisième : isoler réseau vs permissions vs mappage d’identités

1. Réseau : ping, nc (pour PBS), showmount (pour NFS), probe SMB pour CIFS.
2. Permissions : essayez touch, vérifiez propriété et mode, inspectez les options d’export NFS (root_squash et compagnons).
3. Identité : vérifiez si le processus de sauvegarde s’exécute en root ; confirmez que le côté distant attend root ou mappe root.

Quatrième : vérifier la cohérence de la config du cluster et les symptômes de split-brain

1. pvecm status pour le quorum.
2. Vérifiez que le contenu de /etc/pve/storage.cfg est identique sur tous les nœuds (généralement oui, sauf si pmxcfs est malade ou si quelqu’un a modifié des fichiers locaux incorrectement).
3. Vérifiez la synchronisation temporelle ; SMB basé sur Kerberos et certaines configurations TLS deviennent capricieuses quand les horloges dérapent.

Arrêtez tôt quand vous trouvez la première couche cassée. Corriger des permissions n’aidera pas si le montage n’a jamais existé. Rebooter n’aidera pas si vous pointez vers un mauvais nom DNS depuis un nœud.

Faits et contexte historique qui expliquent le piège

• Fait 1 : Le système de fichiers de configuration du cluster de Proxmox (pmxcfs) est un magasin de configuration répliqué en espace utilisateur. Il distribue la configuration, pas les mounts ou l’état du kernel.
• Fait 2 : L’attribut « shared » précède les attentes actuelles de beaucoup sur les « sémantiques cloud ». Il vient d’une époque où les admins savaient qu’un montage NFS était leur responsabilité, pas celle de l’hyperviseur.
• Fait 3 : Sous Linux, un montage est de l’état du kernel par nœud. Aucun fichier de configuration de cluster ne peut « partager » un montage à moins que vous ne le déployiez sur chaque nœud.
• Fait 4 : Le comportement root_squash de NFS est une sécurité par défaut qui entre souvent en collision avec des logiciels de sauvegarde s’exécutant en root. Ce n’est pas un bug Proxmox ; c’est votre politique de sécurité qui rencontre vos hypothèses.
• Fait 5 : Les « permissions » CIFS/SMB sont un millefeuille : ACL serveur, permissions du partage, options de montage client et parfois le mappage d’identités. C’est impressionnant quand ça marche.
• Fait 6 : Proxmox Backup Server (PBS) n’est pas un montage de système de fichiers ; c’est une datastore pilotée par API avec chunking et déduplication. Les erreurs de disponibilité là-bas sont souvent réseau/TLS/auth, pas « montage manquant ».
• Fait 7 : Les plugins de stockage de Proxmox effectuent souvent des vérifications en tentant d’accéder à des chemins ou d’exécuter des opérations ; « non disponible » peut signifier « impossible de stat le répertoire », « mauvais type de contenu » ou « backend injoignable ».
• Fait 8 : Systemd a changé la donne pour les montages : x-systemd.automount peut rendre les montages « paresseux », ce qui est excellent pour la vitesse de démarrage et terrible pour des jobs de sauvegarde contraints dans le temps si mal configuré.

Une citation qui mérite sa place dans chaque handbook d’on-call :

« L’espoir n’est pas une stratégie. » — idée paraphrasée attribuée à de nombreux responsables opérations

Le stockage partagé est un de ces endroits où l’espoir arrive portant un t-shirt « ça marche sur mon nœud ».

Blague #1 : Le stockage « partagé » ressemble à la « responsabilité partagée » dans un postmortem : tout le monde convient qu’il existe, et personne n’est sûr de qui en est responsable.

Pourquoi le stockage est « non disponible » : les vrais modes de panne

1) La définition du stockage est globale au cluster, mais le backend n’est pas monté sur chaque nœud

Classique. Le stockage est défini comme dir ou NFS/CIFS, mais seul un nœud a le montage réel ou le répertoire. Un autre nœud tente d’exécuter un job de sauvegarde et trouve un répertoire vide, un point de montage manquant ou un chemin local qui n’est pas ce que vous croyez.

2) Le montage existe, mais il est monté différemment (options, versions, chemins)

NFSv3 sur un nœud et NFSv4 sur un autre. rsize/wsize différents. vers= différent. Cache d’identifiants SMB différent. Ou pire : un nœud a monté un export différent avec le même point de montage. L’interface ne crie pas ; elle échoue plus tard.

3) Permissions : root squashed, ACL en désaccord, ou mauvais propriétaire

VZDump et de nombreuses opérations Proxmox s’exécutent en root. Si votre serveur NFS mappe root vers nobody et que votre répertoire n’est pas inscriptible pour cet utilisateur, Proxmox obtient une erreur I/O ou permission et signale « non disponible » ou échec de sauvegarde. Vous pouvez voir le stockage « active », mais les écritures échouent.

4) Asymétrie DNS/routage entre les nœuds

Le nœud A peut résoudre nas01 vers la bonne IP. Le nœud B le résout vers une IP ancienne, un VLAN différent ou une interface morte. Ou un nœud route via un firewall qui bloque les ports NFS. Le stockage « marche » jusqu’à ce qu’un job tombe sur le mauvais nœud.

5) Problèmes d’état du cluster : perte de quorum ou pmxcfs capricieux

Si un nœud perd le quorum, certaines opérations de cluster sont restreintes. La config de stockage peut être lisible mais les changements peuvent ne pas se propager comme attendu. De plus, un nœud avec un système de fichiers de configuration malade peut présenter une config obsolète. C’est plus rare, mais réel.

6) La cible de sauvegarde n’est pas un « storage » au sens système de fichiers (PBS)

Les échecs PBS ressemblent à des pannes de stockage dans l’interface car Proxmox le traite comme un backend. Mais les causes racines sont différentes : empreintes expirées, problèmes TLS, tokens d’auth révoqués, datastore supprimé, ou port réseau bloqué.

7) Ordre de démarrage et montages « nofail » créent une bombe à retardement

nofail dans /etc/fstab permet au nœud de démarrer même si le NAS est down. Super. Mais maintenant le nœud est « up » et peut programmer des sauvegardes, tandis que le répertoire de sauvegarde n’est en réalité qu’un dossier local vide. Ce n’est pas une sauvegarde ; c’est de l’art performance.

Blague #2 : Une sauvegarde qui écrit dans un répertoire non monté est le désastre de Schrödinger : elle a réussi et échoué jusqu’au moment où vous devez restaurer.

Tâches pratiques (commandes, sorties, décisions)

Voici les tâches que j’exécute pour diagnostiquer « stockage de sauvegarde non disponible sur le nœud ». Chacune inclut une commande réaliste, un extrait de sortie plausible et la décision qui en découle. Exécutez-les d’abord sur le nœud en échec, puis comparez avec un nœud connu bon.

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

Que cela signifie : Proxmox pense que backup-nfs est inactive sur ce nœud. Ce n’est pas un problème de sauvegarde au niveau VM ; c’est un problème de montage/accessibilité.

Décision : Ne perdez pas de temps à dépanner au niveau VM. Réparez d’abord le backend de stockage.

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

Que cela signifie : Le stockage est configuré au niveau cluster comme NFS, type de contenu « backup », et « shared 1 ».

Décision : Prouvez maintenant que le path est réellement monté et inscriptible.

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

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

Que cela signifie : C’est le point de montage que Proxmox utilisera.

Décision : Validez l’état du montage du kernel à ce chemin.

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

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

Que cela signifie : Aucune sortie veut généralement dire « pas monté ». S’il retourne une ligne NFS, vous êtes monté.

Décision : Si non monté, vérifiez /etc/fstab et les unités systemd ; si monté, passez aux permissions et à la connectivité.

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

Que cela signifie : Voici à quoi ressemble un état « bon » : serveur correct, export correct, point de montage correct.

Décision : Faites correspondre le nœud en échec à ce comportement, octet par octet si possible.

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

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

Que cela signifie : Problème de reachabilité réseau vers nas01 (routage, firewall, DNS ou NAS down).

Décision : Arrêtez-vous et dépannez le réseau avant de toucher aux permissions ou aux réglages Proxmox.

Task 7: Test DNS and routing symmetry

cr0x@pve2:~$ getent hosts nas01
10.20.30.50   nas01

Que cela signifie : Le nœud résout nas01 en une IP. Cela ne prouve pas que c’est la bonne IP.

Décision : Comparez la sortie entre nœuds. Si différente, corrigez DNS/hosts. Si identique, testez la connectivité vers cette 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

Que cela signifie : L’hôte est joignable, mais NFS peut encore être bloqué.

Décision : Testez NFS spécifiquement (portmapper pour v3, 2049 pour 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!

Que cela signifie : Le port TCP NFSv4 est atteignable. Si ça échoue, c’est firewall/routage ou service NAS down.

Décision : Si atteignable, vérifiez exports et permissions ; sinon, réparez réseau/sécurité d’abord.

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

Que cela signifie : Le NAS annonce l’export vers votre subnet.

Décision : Si votre nœud n’est pas dans ce subnet (VLAN différent), vous avez trouvé la discordance.

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

Que cela signifie : Root peut créer des fichiers. C’est le minimum requis pour le stockage de sauvegarde.

Décision : Si cela échoue avec « Permission denied », inspectez les options d’export NFS et les permissions de répertoire.

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

Que cela signifie : Le serveur peut mapper root vers nobody, et le mode du répertoire n’est pas inscriptible.

Décision : Ajustez l’export (avec prudence) ou créez un utilisateur de service dédié et alignez UID/GID sur tous les nœuds et le 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

Que cela signifie : Le listing du répertoire répond rapidement. S’il bloque jusqu’au timeout, vous avez probablement un montage obsolète ou des fluctuations réseau.

Décision : Examinez la stabilité réseau, la charge du serveur NFS, et envisagez des montages « hard » avec des timeouts raisonnables ; évitez le « soft » pour l’intégrité des sauvegardes.

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

Que cela signifie : Le montage SMB existe et mappe la propriété à root. C’est courant pour les cibles de sauvegarde Proxmox.

Décision : Si un nœud manque ce montage ou utilise des identifiants différents, standardisez via /etc/fstab ou une unité systemd de montage déployée uniformément.

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!

Que cela signifie : Le chemin réseau vers l’API PBS est ouvert. C’est la première étape.

Décision : Si bloqué, corrigez firewall/VLAN. Si ouvert, vérifiez la config de stockage Proxmox et les certificats/empreintes.

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

Que cela signifie : L’erreur provient de l’outil de sauvegarde qui invoque des vérifications de stockage. Ce n’est pas un échec de snapshot VM ; c’est une indisponibilité de stockage.

Décision : Concentrez-vous sur pourquoi pvesm status montre inactive ou pourquoi la vérification du chemin échoue.

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

Que cela signifie : Le cluster a le quorum. Vous ne déboguez pas le stockage sous partition de cluster (bien).

Décision : Si Quorate: No, stabilisez d’abord le cluster ; la config de stockage et la planification des jobs peuvent devenir imprévisibles.

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

Que cela signifie : L’horloge est synchronisée. Cela réduit les chances d’échecs TLS lors handshakes PBS ou d’auth SMB.

Décision : Si hors synchro, corrigez l’heure d’abord. C’est ennuyeux et ça marche.

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

Que cela signifie : Il y a une entrée fstab. Bien. Les options comptent.

Décision : Si elle manque sur un nœud, c’est pourquoi « partagé » n’est pas partagé. Standardisez les montages sur tous les nœuds.

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

Que cela signifie : Si NFS est down au boot, le montage peut ne pas se produire, mais le répertoire existe toujours, et les jobs peuvent écrire localement.

Décision : Remplacez par un automount systemd ou imposez un ordonnancement explicite pour que les services ne démarre pas sans stockage (détails dans la section checklist).

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox à trois nœuds et un unique stockage « backup » pointant vers un partage NFS. L’admin qui l’a configuré a fait la bonne chose dans l’interface : ajouté le stockage NFS, coché « Shared », sélectionné le contenu « VZDump backup file ». Tout le monde a acquiescé.

Les sauvegardes ont réussi pendant des semaines. C’est la partie dangereuse. Elles ont réussi parce que la plupart des VMs « importantes » résidaient sur le nœud 1 pour des raisons historiques, et les jobs de sauvegarde tournaient quand le nœud 1 était sain.

Puis une fenêtre de maintenance a déplacé un lot de VMs sur le nœud 2. Les sauvegardes nocturnes suivantes se sont exécutées depuis le nœud 2. Le stockage a indiqué « non disponible sur le nœud ». Quelqu’un a relancé manuellement les jobs sur le nœud 1 et a appelé cela « temporaire ». Deux jours plus tard, le nœud 1 a subi un reboot non planifié et l’entreprise a découvert que « temporaire » est un autre mot pour « permanent ».

La cause racine n’était pas exotique : seul le nœud 1 avait une entrée /etc/fstab pour le partage NFS. Les nœuds 2 et 3 avaient le répertoire /mnt/pve/backup-nfs (créé par Proxmox), mais il n’était pas monté. L’équipe avait supposé que la config du cluster rendait cela « partagé ». Ce n’était pas le cas.

La correction n’était pas exotique non plus : déployer une configuration de montage identique via l’automatisation, plus un test canari dans le monitoring : « est-ce que ce chemin est monté et inscriptible ? » Les incidents demandent rarement de l’ingéniosité. Ils demandent de la discipline.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre société voulait des temps de boot plus rapides et moins d’incidents « nœud bloqué au boot en attente du NAS ». Ils ont changé les montages NFS pour inclure nofail et ajouté quelques tweaks systemd pour que l’hyperviseur démarre même si le stockage était indisponible.

Les temps de boot ont amélioré. Sur le papier. En réalité, ils ont échangé un mode de panne contre un plus sournois : les nœuds démarraient, l’interface Proxmox semblait saine, et les jobs de sauvegarde tournaient. Mais les matins où le NAS répondait lentement, les montages n’avaient pas lieu à temps. Le chemin de sauvegarde existait comme un répertoire normal, donc le job écrivait sur le disque local.

Le disque local s’est rempli. Les VMs ont commencé à stresser. Les logs ont explosé. L’équipe stockage a été alertée pour « performance NAS » alors que le NAS allait bien — Proxmox avait discrètement détourné la charge vers le stockage local parce que le montage n’était pas présent.

Ils ont corrigé en utilisant x-systemd.automount (l’accès déclenche le montage), en supprimant le risque d’« écriture locale » en faisant en sorte que le point de montage soit possédé par root mais non inscriptible lorsqu’il n’est pas monté, et en ajoutant un hook pré-sauvegarde pour valider l’état du montage. Morale : optimiser le démarrage sans réfléchir aux sémantiques d’échec crée des systèmes hantés.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers utilisait Proxmox avec PBS comme cible principale et NFS comme export secondaire. Ils n’étaient pas des gens excitants. Ils ont tout documenté, et ils testaient les restaurations trimestriellement. C’est pourquoi ils dormaient tranquilles.

Un week-end, une mise à jour de firmware d’un switch central a introduit un changement d’ACL qui a bloqué TCP/8007 depuis une armoire. Deux des quatre nœuds Proxmox pouvaient atteindre PBS ; deux ne le pouvaient pas. Les sauvegardes ont commencé à échouer uniquement pour les VMs en cours d’exécution sur ces nœuds isolés.

Ils l’ont détecté en moins d’une heure parce que leur monitoring ne se contentait pas d’observer le « succès des jobs ». Il surveillait l’accessibilité du stockage depuis chaque nœud. L’alerte disait essentiellement « pve3 ne peut pas atteindre pbs01:8007 ». Pas de devinettes, pas d’archéologie.

Ils ont basculé en pinant temporairement les jobs sur des nœuds sains, puis ont rollbacké le changement d’ACL. Après ça, ils ont ajouté un item à leur checklist de gestion de changement : « valider la connectivité PBS depuis chaque hyperviseur ». Ennuyant. Correct. A sauvé la journée.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “storage is not available on node” only on one node

Cause racine : Le montage existe seulement sur certains nœuds, ou le DNS résout différemment par nœud.

Correction : Standardisez les montages via /etc/fstab ou des unités systemd de montage sur tous les nœuds ; vérifiez avec findmnt et getent hosts sur chaque nœud.

2) Symptom: storage shows “active”, but backups fail with permission errors or “cannot create file”

Cause racine : root_squash NFS, mismatch d’ACL SMB, ou mauvais propriétaire/mode sur le répertoire cible.

Correction : Choisissez votre modèle de sécurité : soit autoriser les écritures root sur l’export (avec prudence), soit mapper vers un utilisateur de service dédié avec UID/GID cohérents ; testez ensuite avec touch en root.

3) Symptom: backups “succeed” but space usage is on local disk, not NAS

Cause racine : Montage absent ; les écritures sont allées dans le répertoire point de montage local (souvent dû à nofail au boot).

Correction : Supprimez le piège. Utilisez systemd automount ou assurez la disponibilité du montage avant que le scheduler ne tourne ; rendez le point de montage non inscriptible quand il n’est pas monté ; surveillez « est monté » plutôt que « le répertoire existe ».

4) Symptom: NFS mount works manually but not during boot

Cause racine : Réseau pas prêt au moment du montage ; absence de _netdev ou problèmes d’ordonnancement systemd.

Correction : Ajoutez _netdev, envisagez x-systemd.automount, et assurez la cible network-online si nécessaire. Validez par test de reboot.

5) Symptom: only PBS-backed storage fails, filesystem storages fine

Cause racine : Port bloqué, mismatch TLS/empreinte, token d’auth révoqué, ou datastore renommé/supprimé sur PBS.

Correction : Vérifiez la connectivité TCP/8007, la config de stockage dans pvesm, réapprouvez l’empreinte si elle a changé volontairement, et confirmez que le datastore existe.

6) Symptom: storage intermittently “inactive” with NFS under load

Cause racine : Fluctuations réseau, saturation serveur NFS, handles obsolètes, ou timeouts trop agressifs.

Correction : Stabilisez le réseau, tunez le serveur NFS, utilisez des montages « hard » avec timeouts sensés, et envisagez de séparer le trafic de sauvegarde sur un VLAN/interface dédié.

7) Symptom: after adding a new node, backups fail on that node only

Cause racine : Le nouveau nœud n’a pas la configuration OS-level de montage, règles firewall, domaines de recherche DNS, ou entrées de magasin de CA.

Correction : Traitez le provisioning des nœuds comme du code. Appliquez la même configuration de montage et la même politique réseau que les nœuds existants avant de le mettre en production.

8) Symptom: storage config looks right, but node behaves like it’s not in the cluster

Cause racine : Perte de quorum, problèmes corosync, ou pb avec pmxcfs.

Correction : Restaurez d’abord la santé du cluster. Validez pvecm status, le réseau entre nœuds, et la stabilité de l’anneau corosync.

Listes de contrôle / plan pas à pas

Pas à pas : rendre « partagé » réellement partagé (style répertoire NFS/CIFS)

1. Choisissez un ID de stockage et un point de montage canoniques. Exemple : backup-nfs monté sur /mnt/pve/backup-nfs.

   Ne créez pas de variations par nœud comme /mnt/pve/backup-nfs2 « juste pour l’instant ». « Juste pour l’instant » est la voie royale vers le travail d’archéologie.

2. Standardisez la résolution de noms. Utilisez getent hosts nas01 sur tous les nœuds et assurez-vous qu’il résout de manière identique. Si vous devez fixer une IP, utilisez /etc/hosts de façon cohérente.

3. Déployez une configuration de montage identique sur chaque nœud. Utilisez /etc/fstab ou des unités systemd de montage. La clé est un comportement identique au reboot.

   Exemple NFSv4 minimal :

   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'
   

   Décision : Si vous exigez que le nœud boot même si le NAS est down, n’ajoutez pas aveuglément nofail. Utilisez automount avec garde-fous.

4. Si vous utilisez systemd automount, faites-le délibérément. Cela évite les blocages au boot et réduit les courses où le montage n’est pas prêt.

   Exemple d’options de montage dans 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
   

   Décision : Si vos fenêtres de sauvegarde sont serrées, validez la latence d’automount sous charge.

5. Appliquez la règle « non monté = non inscriptible ». Une tactique pratique : faites posséder le point de montage par root avec le mode 000 lorsqu’il est démonté, puis laissez le montage fournir les permissions. Cela réduit les surprises d’« écritures locales ». Testez avec soin pour que Proxmox puisse toujours monter.

6. Validez sur chaque nœud : le montage existe, l’écriture fonctionne, la latence est acceptable.

   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
   

   Décision : Si le débit varie énormément par nœud, vous avez probablement des différences de routage, des problèmes de NIC, ou un souci de chemin de commutation.

7. Confirmez que Proxmox le voit actif partout.

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

   Décision : Ce n’est qu’après cela que vous touchez à la planification des jobs de sauvegarde.

8. Ajoutez du monitoring qui vérifie montage et inscriptibilité depuis chaque nœud. La vérification doit être volontairement simple : « est monté », « peut créer un fichier » et « est-ce le type de FS attendu ».

Pas à pas : PBS-backed « storage not available »

1. Confirmez la reachabilité TCP vers PBS sur le port 8007 depuis chaque nœud. Utilisez nc -vz.
2. Confirmez que le storage est actif dans pvesm status. Si inactive, c’est généralement connectivité ou auth.
3. Validez la synchronisation temporelle. TLS déteste les voyages temporels.
4. Confirmez que le datastore PBS existe et n’a pas été renommé. La config de stockage peut survivre à l’objet qu’elle référence.
5. Soyez strict sur certificats et empreintes. Si une empreinte change sans raison, considérez cela comme un incident de sécurité jusqu’à preuve du contraire.

Pas à pas : rendre les sauvegardes résilientes sans se mentir

1. Préférez PBS pour la déduplication et l’intégrité. Utilisez les partages filesystem comme export secondaire/réplication, pas comme unique plan de salut.
2. Gardez un fallback local seulement si vous l’alertez. Un répertoire de secours local peut vous sauver lors d’une panne NAS, mais seulement si vous surveillez la pression disque locale et que vous faites une rotation agressive.
3. Testez les restaurations. Pas une fois. Régulièrement. Une sauvegarde que vous n’avez pas restaurée n’est qu’une rumeur.

FAQ

1) Que signifie « stockage de sauvegarde non disponible sur le nœud » dans Proxmox ?

Cela signifie que le nœud exécutant l’opération (souvent vzdump) ne peut pas accéder à ce backend de stockage à ce moment. Typiquement : non monté, injoignable, mauvais identifiants, ou permission refusée.

2) Si le stockage est marqué « Shared », pourquoi Proxmox ne le monte-t-il pas partout ?

Parce que Proxmox gère des définitions de stockage, pas les montages du kernel. Le montage est un état OS-level. Vous devez configurer les montages sur chaque nœud (ou utiliser un backend intrinsèquement partagé, comme Ceph).

3) Puis-je corriger cela en décochant « Shared » ?

Vous pouvez atténuer certains comportements de planification et de migration, mais vous ne résoudrez pas le problème sous-jacent. Si plusieurs nœuds doivent sauvegarder dessus, il doit être accessible depuis plusieurs nœuds. Faites correspondre la réalité à la case, pas l’inverse.

4) Pourquoi cela échoue-t-il seulement parfois ?

Parce que seules certaines sauvegardes s’exécutent sur le nœud incapable d’accéder au stockage, ou parce que les montages sont instables (latences automount, fléchissements réseau, charge NAS). Les défaillances intermittentes restent des défaillances ; elles attendent juste votre pire jour.

5) Quelle est la différence entre stockage NFS pour sauvegarde et stockage PBS dans Proxmox ?

NFS est un chemin de système de fichiers monté. PBS est une datastore pilotée par API avec déduplication, compression, vérification et règles de prune. Le dépannage de la disponibilité PBS s’apparente davantage au débogage d’une dépendance applicative qu’à un montage.

6) Mon partage NFS monte, mais les sauvegardes échouent avec « Permission denied ». Que faire ?

Vérifiez la présence de root_squash et les permissions du répertoire. Les jobs de sauvegarde Proxmox ont typiquement besoin d’écrire en root. Autorisez les écritures root sur l’export (avec un compromis de sécurité), ou mappez vers une identité de service dédiée avec UID/GID cohérents et permissions appropriées.

7) Comment empêcher les sauvegardes d’écrire sur le disque local quand le montage NFS est manquant ?

Ne vous fiez pas à l’existence du répertoire. Imposer des vérifications de montage : utilisez systemd automount et/ou rendez le point de montage non inscriptible lorsqu’il est démonté, et surveillez « est monté » plus un « test d’écriture ». Évitez le nofail sans garde-fous.

8) Le quorum du cluster affecte-t-il la disponibilité du stockage ?

Pas directement pour les montages, mais une perte de quorum peut modifier le comportement des services de cluster et la distribution de configuration. Si un nœud n’a pas le quorum, restaurez la santé du cluster d’abord pour ne pas déboguer deux problèmes à la fois.

9) Est-il acceptable d’avoir des options de montage différentes sur différents nœuds si ça « marche » ?

Cela marche jusqu’à ce que ça ne marche plus. Différentes versions NFS et options de montage peuvent changer le comportement de verrouillage, les performances et les sémantiques d’échec. Standardisez. Votre futur vous remerciera.

10) Dois-je utiliser CIFS/SMB pour les sauvegardes Proxmox ?

Vous pouvez, mais c’est généralement plus fragile que NFS dans des environnements hyperviseur Linux à cause de la complexité auth et ACL. Si vous devez l’utiliser, standardisez les options de montage et les identifiants sur tous les nœuds et testez le comportement en cas d’échec.

Conclusion : étapes suivantes pour éviter les récidives

« Stockage de sauvegarde non disponible sur le nœud » est Proxmox qui vous dit la vérité. La partie désagréable est que la vérité vit sous la GUI : montages, réseaux, permissions, mappage d’identités et ordre de démarrage.

Étapes suivantes qui changent réellement les résultats :

1. Choisissez le nœud en échec et exécutez le mode d’intervention rapide. Confirmez si le storage est inactive, non monté, injoignable ou non inscriptible.
2. Standardisez les montages sur tous les nœuds. Même nom de serveur, même export/partage, même point de montage, mêmes options.
3. Supprimez le piège « écritures locales ». Si vous utilisez nofail, compensez-le par automount et monitoring.
4. Ajoutez du monitoring par nœud. Vérifiez montage + inscriptibilité + type de filesystem attendu, pas seulement « job de sauvegarde réussi ».
5. Testez une restauration. Pas pour le plaisir. Parce que c’est moins cher que d’apprendre pendant une panne.

Si vous voulez un seul modèle mental à garder : la case « Shared » est une promesse que vous faites à Proxmox. Tenez-la, et les sauvegardes deviennent ennuyeuses. Brisez-la, et les sauvegardes deviennent une surprise hebdomadaire.