Proxmox PBS « datastore not found » : pourquoi PVE ne le voit pas et comment le réparer

Ce que signifie vraiment « datastore not found » (et ce que ça n’est pas)

Dans PVE, un datastore PBS est découvert et utilisé via l’API HTTP de PBS (port 8007 par défaut). Quand PVE affiche
« datastore not found », l’une des situations suivantes se produit :

• L’ID du datastore configuré n’existe pas (faute de frappe, différence de casse, mauvais nœud PBS).
• Le datastore existe, mais vos identifiants ne peuvent pas le lister ou y accéder (permissions, realm, token).
• PVE ne parvient pas à communiquer de façon fiable avec PBS (DNS, routage, pare-feu, port, proxy, empreinte TLS).
• Vous êtes confronté à un décalage de namespace (le datastore existe, mais l’accès est restreint par namespace).
• Vous parlez au mauvais serveur PBS (VIP, NAT, split DNS, IP obsolète, confusion de cluster).

Ce que ce n’est généralement pas : un problème de système de fichiers du stockage sur PBS. Si l’interface PBS affiche le datastore sain,
la plainte de PVE se situe presque toujours au niveau API/auth/config, pas à celui d’un ZFS ayant avalé vos sauvegardes.

Un indice opérationnel : le même texte d’erreur est souvent réutilisé pour plusieurs échecs d’API. « Datastore not found »
est parfois un mensonge poli qui signifie « vous n’êtes pas autorisé à le voir » ou « je ne peux pas m’authentifier ». Les ordinateurs font ça
parce qu’ils n’ont pas de scrupules.

Blague n°1 (courte, pertinente) : Un datastore « not found » est l’équivalent stockage de « je n’ai jamais reçu ton e‑mail. » Il existe ; quelqu’un refuse juste de le reconnaître.

Faits et contexte intéressants (pourquoi cette erreur revient)

Un peu de contexte aide, car « datastore not found » est un mode de défaillance moderne aux racines classiques :
identité, nommage et contrôle d’accès. Voici des faits concrets qui influencent la façon de dépanner :

1. Les datastores PBS sont adressés par ID, pas par chemin. L’ID est ce que l’API expose ; le répertoire sous-jacent est secondaire.
2. PVE s’intègre avec PBS via l’API PBS sur le port 8007. Si le port 8007 est bloqué ou intercepté, la découverte échoue même si l’interface PBS fonctionne localement.
3. Les realms d’authentification Proxmox importent. root@pam et root@pbs sont des identités différentes ; les tokens héritent des sémantiques de realm.
4. L’empreinte TLS de PBS est épinglée par PVE. Si le certificat TLS de PBS change (réinstallation, changement d’hôte), PVE peut refuser la connexion tant que l’empreinte n’est pas mise à jour.
5. Les permissions PBS sont structurées par chemin et objet. Avoir « Datastore.Audit » n’est pas la même chose que « Datastore.Backup ». L’absence de permission de listing peut masquer des datastores.
6. Les namespaces ajoutent une dimension d’accès supplémentaire. Un datastore peut exister et vous être bloqué pour le namespace que vous tentez d’utiliser.
7. PBS stocke sa configuration dans /etc/proxmox-backup. Les définitions de datastores sont locales au nœud PBS ; le clustering PBS ne réplique pas automatiquement les configs sauf si vous l’avez prévu.
8. PVE stocke les définitions de stockage PBS dans /etc/pve/storage.cfg. Sur un cluster PVE, ce fichier est répliqué. Une mauvaise modification devient le problème de tout le monde.
9. « Not found » est un vieux réflexe de sécurité. De nombreuses APIs renvoient 404 pour des ressources non autorisées afin d’éviter les fuites d’information, ce qui est excellent pour la sécurité et pénible pour le débogage.

Une citation pour cadrer l’état d’esprit. C’est une idée paraphrasée, parce que la précision compte :
idée paraphrasée : « L’espoir n’est pas une stratégie ; vous avez besoin de preuves. » — tiré de la culture fiabilité/opérations.

Playbook de diagnostic rapide (vérifiez 1, 2, 3)

Vous voulez le chemin le plus court vers la certitude. Ne commencez pas par réinstaller PBS ou reformater quoi que ce soit.
Commencez par prouver où la visibilité se casse : réseau, identité ou nommage.

1) Prouvez que PVE peut joindre l’API PBS (port 8007) et que TLS n’embrouille pas

• Si la connexion TCP échoue : c’est le réseau/pare‑feu/routage/DNS.
• Si la poignée de main TLS se plaint du certificat/empreinte : c’est la confiance épinglée.
• Si vous obtenez une réponse HTTP : le tuyau est OK ; passez à auth/permissions.

2) Prouvez que vos identifiants peuvent lister les datastores

• Si la liste des datastores est vide ou renvoie une erreur : permissions, realm, token ou mauvaise cible PBS.
• Si la liste montre le datastore mais que l’ajout échoue : décalage d’ID du datastore, mismatch de namespace, ou dérive de storage.cfg.

3) Prouvez que l’ID du datastore correspond exactement à ce que PBS expose

• Les IDs de datastore sont sensibles à la casse. Traitez-les comme des noms d’objets API, parce que c’en sont.
• Confirmez que vous n’utilisez pas un chemin de fichier ou un « nom convivial ».

Si vous n’avez que 10 minutes, faites ces trois vérifications. Elles couvrent la majorité des incidents réels.

Carte des défaillances : où le datastore peut « disparaître »

Pensez à une chaîne. Le datastore n’est visible que si chaque maillon tient.
Cassez un maillon et PVE déclarera « not found », parce que du point de vue de PVE, il n’existe vraiment pas.

Maillon A : PVE résout le nom PBS vers la bonne adresse

Split DNS, entrées obsolètes dans /etc/hosts et règles NAT « temporaires » sont des classiques. PVE peut se connecter à un PBS différent
de celui que vous pensez — surtout lors de migrations lab→prod ou de tests DR.

Maillon B : Le port 8007 est joignable, et rien ne le proxy de façon étrange

Un reverse proxy qui gère HTTP mais pas les WebSockets, un pare‑feu effectuant une inspection TLS, ou un load balancer L7
avec des checks mal assortis peuvent produire des comportements d’API étranges. PBS est plus heureux quand on y accède directement.

Maillon C : L’empreinte TLS épinglée dans PVE correspond au certificat actuel de PBS

PVE stocke et vérifie l’empreinte PBS. Si vous réinstallez PBS, régénérez son certificat ou changez son hostname, PVE peut commencer à refuser les connexions d’une manière qui remonte comme « datastore not found » lors de l’ajout/scan.

Maillon D : L’identité utilisée a la permission de lister et d’accéder au datastore

PVE peut s’authentifier comme un utilisateur (par exemple backup@pbs) ou via un token API. Mais le token doit exister,
ne pas être expiré/désactivé, et posséder les bons rôles. « Not found » peut être PBS qui veut dire « pas autorisé ».

Maillon E : L’ID du datastore est correct et cohérent

L’ID du datastore n’est pas le point de montage. Ce n’est pas le nom du dataset ZFS sauf si vous l’avez volontairement rendu identique.
Si vous changez l’ID du datastore dans PBS, PVE ne suivra pas magiquement.

Maillon F : Les attentes sur namespaces et pruning/verification correspondent

Les namespaces peuvent rendre un datastore vide ou inaccessible si vous n’avez pas les permissions sur le namespace.
Aussi, si vous attendez un namespace qui n’existe pas ou est restreint, le comportement de PVE peut ressembler à
« le datastore n’existe pas ».

Tâches pratiques avec commandes (12+ vérifications qui tranchent)

Ce sont des vérifications de terrain. Elles sont conçues pour être exécutables et produire des sorties qui orientent les décisions.
Lancez-les depuis un nœud PVE d’abord, puis depuis PBS, car vous déboguez une conversation.

Task 1: Confirm PVE resolves PBS to the expected IP

cr0x@server:~$ getent hosts pbs01
10.20.30.40    pbs01

Ce que ça signifie : C’est l’IP que PVE utilisera. Si elle est erronée, vous déboguez la mauvaise machine.
Décision : Si l’IP est inattendue, corrigez le DNS ou /etc/hosts (et supprimez les overrides « temporaires »).

Task 2: Check basic TCP reachability to PBS API port 8007

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

Ce que ça signifie : Le chemin réseau L3/L4 est ouvert.
Décision : Si ça échoue ou timeoute, arrêtez. Corrigez le routage/pare‑feu d’abord ; l’auth n’aura pas d’importance tant que ça ne passe pas.

Task 3: Verify TLS handshake and capture the presented certificate subject

cr0x@server:~$ echo | openssl s_client -connect pbs01:8007 -servername pbs01 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint -sha256
subject=CN = pbs01
issuer=CN = Proxmox Backup Server
sha256 Fingerprint=AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99

Ce que ça signifie : Vous voyez quel certificat PBS présente et sa fingerprint SHA256.
Décision : Si PVE a une empreinte différente enregistrée, mettez‑la à jour dans la définition de stockage PVE ou réajoutez proprement le stockage PBS.

Task 4: On PVE, inspect the PBS storage entry in storage.cfg

cr0x@server:~$ grep -nA6 -B2 "pbs:" /etc/pve/storage.cfg
12:pbs: pbs-backups
13:        datastore vmbackups
14:        server pbs01
15:        username backup@pbs
16:        fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99
17:        content backup

Ce que ça signifie : C’est la vérité terrain sur ce que PVE tentera d’utiliser.
Décision : Si datastore n’est pas exactement l’ID PBS, corrigez‑le. Si server est erroné, corrigez‑le. Si le realm de username est faux, corrigez‑le.

Task 5: From PVE, query PBS API version to validate auth-free connectivity

cr0x@server:~$ curl -k -s https://pbs01:8007/api2/json/version | jq .
{
  "data": {
    "release": "3.2-1",
    "repoid": "f433c2a1",
    "version": "3.2.3"
  }
}

Ce que ça signifie : Le chemin réseau et la pile HTTP fonctionnent au moins pour les endpoints non authentifiés.
Décision : Si cela échoue, ne touchez pas encore aux permissions. Corrigez DNS, interception TLS ou problèmes de pare‑feu.

Task 6: On PBS, list datastores and confirm the datastore ID

cr0x@server:~$ proxmox-backup-manager datastore list
┌───────────┬──────────────┬──────────┬─────────────┐
│ name      │ path         │ comment  │ gc-schedule │
╞═══════════╪══════════════╪══════════╪═════════════╡
│ vmbackups │ /mnt/pbs/vm  │          │ daily       │
└───────────┴──────────────┴──────────┴─────────────┘

Ce que ça signifie : L’ID du datastore est vmbackups. C’est ce que PVE doit utiliser.
Décision : Si PVE utilise autre chose (comme /mnt/pbs/vm), corrigez la config PVE.

Task 7: On PBS, confirm the datastore is actually available and not in a weird mount state

cr0x@server:~$ proxmox-backup-manager datastore status
┌───────────┬─────────┬───────────┬─────────────┬───────────┐
│ datastore │ status  │ total     │ used        │ avail     │
╞═══════════╪═════════╪═══════════╪═════════════╪═══════════╡
│ vmbackups │ online  │ 10.00 TiB │ 2.10 TiB    │ 7.90 TiB  │
└───────────┴─────────┴───────────┴─────────────┴───────────┘

Ce que ça signifie : PBS estime que le datastore est en ligne.
Décision : S’il est offline, réparez le stockage sous‑jacent (montage/ZFS/disque) avant d’accuser PVE.

Task 8: On PBS, verify the API service is running and listening on 8007

cr0x@server:~$ systemctl status proxmox-backup
● proxmox-backup.service - Proxmox Backup Server API and Web UI
     Loaded: loaded (/lib/systemd/system/proxmox-backup.service; enabled)
     Active: active (running) since Mon 2025-12-22 08:10:12 UTC; 3 days ago
     Main PID: 1234 (proxmox-backup)
      Tasks: 24 (limit: 38461)
     Memory: 220.0M
     CGroup: /system.slice/proxmox-backup.service
             └─1234 /usr/lib/x86_64-linux-gnu/proxmox-backup/proxmox-backup-api

Ce que ça signifie : Le service est up.
Décision : S’il est inactive/failed, redémarrez et inspectez les logs. PVE ne peut pas voir les datastores si l’API PBS est down.

Task 9: On PBS, check firewall status and allow 8007 if needed

cr0x@server:~$ pve-firewall status
Status: enabled/running
Service: proxmox-firewall
Rules: loaded

Ce que ça signifie : Le pare‑feu Proxmox est actif (PBS utilise le même outil de pare‑feu).
Décision : Si activé, confirmez qu’il existe une règle allow pour TCP/8007 depuis vos nœuds/subnets PVE.

Task 10: From PVE, attempt to list datastores through the configured storage (PVE view)

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
pbs-backups  pbs      active              0               0               0       0.00

Ce que ça signifie : Cette sortie est parfois peu informative pour la capacité PBS, mais elle indique si PVE considère le stockage « active ».
Décision : S’il n’est pas actif, consultez les logs PVE pour erreurs d’authentification et d’API.

Task 11: On PVE, read the task log for the failed add/scan operation

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy --since "1 hour ago" | tail -n 40
Dec 26 09:11:02 pve01 pvedaemon[2211]: storage 'pbs-backups' error: datastore 'vmbackup' not found
Dec 26 09:11:02 pve01 pvedaemon[2211]: pbs-api: GET /api2/json/admin/datastore: permission denied

Ce que ça signifie : La première ligne pointe l’ID du datastore ; la seconde ligne est la vraie raison : permission denied.
Décision : Corrigez les permissions PBS pour l’utilisateur/token. Ne renommez pas les datastores pour chasser un problème de permissions.

Task 12: On PBS, list users and confirm the account exists in the expected realm

cr0x@server:~$ proxmox-backup-manager user list
┌──────────────┬────────┬───────────────────────────┬──────────┐
│ userid       │ enable │ comment                   │ expire   │
╞══════════════╪════════╪═══════════════════════════╪══════════╡
│ root@pam     │ true   │                           │          │
│ backup@pbs   │ true   │ used by PVE for backups   │          │
└──────────────┴────────┴───────────────────────────┴──────────┘

Ce que ça signifie : L’utilisateur existe. Notez le realm : backup@pbs.
Décision : Si PVE utilise backup@pam alors que PBS n’a que backup@pbs, corrigez le nom d’utilisateur dans PVE.

Task 13: On PBS, check permissions for the user on the datastore path

cr0x@server:~$ proxmox-backup-manager acl list | sed -n '1,120p'
┌───────────────┬────────────┬──────────────┬───────────────────────────┐
│ path          │ ugid       │ type         │ role                      │
╞═══════════════╪════════════╪══════════════╪═══════════════════════════╡
│ /datastore    │ backup@pbs │ user         │ DatastoreAdmin            │
│ /datastore/vmbackups │ backup@pbs │ user  │ DatastoreBackup           │
└───────────────┴────────────┴──────────────┴───────────────────────────┘

Ce que ça signifie : Cet utilisateur a des rôles accordant des droits sur le datastore. Les rôles exacts dépendent de la politique.
Décision : Si vous ne voyez pas d’entrée ACL pour /datastore/vmbackups (ou les chemins namespace appropriés), ajoutez‑en une. Au minimum, accordez les permissions de listing/audit + backup pour le flux PVE.

Task 14: On PBS, test login with an API token strategy (recommended)

cr0x@server:~$ proxmox-backup-manager user token list backup@pbs
┌───────────┬────────┬────────────┬────────┐
│ tokenid   │ enable │ expire     │ comment│
╞═══════════╪════════╪════════════╪════════╡
│ pve-prod  │ true   │            │        │
└───────────┴────────┴────────────┴────────┘

Ce que ça signifie : Un token existe et est activé.
Décision : Préférez les tokens aux mots de passe pour l’intégration PVE→PBS. Si aucun token n’existe, créez‑en un et définissez des rôles minimaux.

Task 15: On PVE, verify the stored credentials reference the right token/user

cr0x@server:~$ grep -n "pbs-backups" -nA8 /etc/pve/storage.cfg
12:pbs: pbs-backups
13:        datastore vmbackups
14:        server pbs01
15:        username backup@pbs
16:        token pve-prod
17:        fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99
18:        content backup

Ce que ça signifie : PVE s’authentifiera en utilisant le token, pas un mot de passe interactif.
Décision : Si token manque et que vous aviez l’intention d’utiliser des tokens, ajoutez‑le. Si le nom du token est erroné, corrigez‑le et relancez le scan du stockage.

Task 16: Confirm you are not accidentally pointing to a PBS “sync target” or a different node

cr0x@server:~$ curl -k -s https://pbs01:8007/api2/json/nodes | jq -r '.data[].node'
pbs01

Ce que ça signifie : Vous parlez bien au nœud PBS que vous croyez.
Décision : Si vous voyez un nom de nœud différent de celui attendu, vous avez une confusion DNS/LB/NAT. Corrigez l’adressage avant toute autre action.

Trois mini-récits d’entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « C’est une faute de frappe, évidemment »

Une société SaaS de taille moyenne a déployé PBS pour remplacer un assemblage d’exports NFS et de scripts aux noms du type
backup_final_v7_really_final.sh. Ils ont créé un nouveau datastore dans PBS appelé vmbackups.
L’équipe stockage l’a validé via l’interface PBS. Tout était vert.

L’équipe virtualisation a ajouté PBS à PVE et a obtenu « datastore not found ». Ils ont fait ce que beaucoup font sous pression :
ils ont supposé que le nom du datastore était faux, l’ont changé dans PVE en vmbackup, puis en VMBackups, puis ont essayé le chemin de montage.
Même erreur. Le canal d’incident s’est rempli de suppositions confiantes, aucune utile.

La vraie cause était plus simple et plus agaçante : les nœuds PVE résolvaient pbs01 vers une ancienne IP via une entrée /etc/hosts résiduelle d’un test de staging.
Cette IP appartenait à une VM PBS décommissionnée et réaffectée à un autre test.
Le « mauvais PBS » ne possédait pas le datastore. Donc oui, « datastore not found » était techniquement correct — juste pas de la manière attendue.

La correction a été immédiate : supprimer l’entrée hosts obsolète, se reposer sur le DNS et réajouter le stockage pour rafraîchir empreinte et endpoint.
L’équipe a ensuite écrit une petite politique : pas d’entrées hosts statiques pour les points d’accès de production sauf plan DR documenté.

Le retour d’expérience n’était pas « faites attention aux fautes de frappe. » C’était « vérifiez que vous parlez bien au système que vous croyez. »
Une leçon SRE aussi vieille que la gestion des astreintes.

2) L’optimisation qui a rétrogradé : « Mettons un proxy devant »

Un autre service a centralisé un gateway TLS interne. Tout devait passer par lui : métriques, apps internes, panneaux admin.
Quelqu’un a décidé que PBS devait aussi être fronté par ce gateway pour la « gestion centralisée des certificats ».
Ils ont terminé TLS au gateway puis récrypté vers PBS avec un certificat différent.

PVE a commencé à échouer de manière intermittente lors de l’ajout de storages PBS avec « datastore not found ».
Pas tout le temps. Juste assez pour être exaspérant. Certains nœuds fonctionnaient ; d’autres non. Des reprises aboutissaient parfois.
C’est le type de panne qui fait accuser des rayons cosmiques.

La cause racine était l’épinglage d’empreinte et la sélection backend incohérente. Le gateway routait occasionnellement un nœud vers un backend différent
lors des fenêtres de maintenance, et le certificat/empreinte présenté ne correspondait pas à ce que PVE avait enregistré. Certains nœuds PVE étaient épinglés à l’ancienne empreinte, d’autres à la nouvelle.
L’erreur est remontée comme un échec de découverte du datastore car l’appel API ne se terminait jamais de manière fiable.

Ils ont réglé le problème en retirant le gateway du chemin PBS (accès direct de PVE à PBS), et en gérant les certificats PBS sur l’hôte PBS de façon contrôlée.
La « centralisation » ne valait pas de transformer les sauvegardes en un événement probabiliste.

C’est le type d’optimisation qui a l’air propre sur un diagramme réseau et moche en production. Les sauvegardes n’ont pas besoin d’élégance. Elles ont besoin d’ennui.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Moindre privilège, documenté »

Une entreprise régulée avait l’habitude, un peu old‑school : chaque intégration de service recevait un compte dédié, un token API,
un rôle strictement limité, et une fiche runbook d’une page avec une commande de vérification copier/coller. Pas de root partagé. Pas de configurations spéciales.

Lors d’un cycle de montée de version PBS, un datastore a été déplacé vers un nouveau stockage et recréé avec le même chemin sous‑jacent mais un ID de datastore différent.
Un admin occupé a supposé que PVE se référait au chemin et non à l’ID. PVE a alors commencé à lancer « datastore not found » après la maintenance.
Au départ, cela ressemblait à un problème de permissions, car le compte pouvait toujours s’authentifier.

Le runbook a fait gagner du temps. Il contenait une vérification simple : lister les datastores via proxmox-backup-manager, confirmer l’ID et le comparer à /etc/pve/storage.cfg.
Pas de débat. Pas de « peut‑être le pare‑feu ». C’était un mismatch d’ID.

Ils ont mis à jour l’ID du datastore dans storage.cfg à travers le cluster (un changement, répliqué), lancé un test de sauvegarde et clôturé l’incident.
Le token dédié et les ACL en moindre privilège ont évité d’accorder des droits admin temporaires pour dépanner.

Pratique ennuyeuse : validée. Pager : silencieux. Conformité : contente. La trifecta.

Erreurs courantes : symptôme → cause → correctif

1) Symptom: PBS UI shows datastore, PVE says “datastore not found”

• Cause racine : Mauvais ID de datastore dans PVE (faute de frappe, casse différente, chemin utilisé au lieu de l’ID).
• Correctif : Sur PBS exécutez proxmox-backup-manager datastore list. Copiez le name exact dans la configuration de stockage PVE.

2) Symptom: Works from one PVE node, fails from another

• Cause racine : ACL réseau, pare‑feu ou split DNS (les nœuds atteignent des endpoints PBS différents).
• Correctif : Comparez getent hosts pbs01 et nc -vz pbs01 8007 entre nœuds. Normalisez DNS et règles de pare‑feu.

3) Symptom: After PBS reinstall or hostname change, everything breaks

• Cause racine : Mismatch d’empreinte TLS épinglée dans PVE.
• Correctif : Récupérez la nouvelle empreinte avec openssl, puis mettez à jour l’empreinte dans la définition PBS de PVE ou réajoutez le stockage.

4) Symptom: Logs show “permission denied” but UI says “not found”

• Cause racine : PBS renvoie des 404/erreurs « not found » pour des accès non autorisés, ou PVE masque l’erreur de permission sous‑jacente.
• Correctif : Inspectez les logs PVE (journalctl -u pvedaemon -u pveproxy) et les ACL PBS (proxmox-backup-manager acl list). Accordez les rôles requis sur /datastore/<id>.

5) Symptom: PVE can curl /version, but datastore scan fails

• Cause racine : La connectivité est OK ; l’authentification/autorisation ne l’est pas (mauvais realm, token désactivé, utilisateur expiré, ACL manquante).
• Correctif : Vérifiez le realm utilisateur et l’existence du token sur PBS. Utilisez un token dédié et confirmez les entrées ACL pour l’accès au datastore.

6) Symptom: PVE storage add works, but backups fail with namespace-related errors

• Cause racine : Permissions de namespace manquantes ou attentes mal configurées sur l’emplacement des sauvegardes.
• Correctif : Alignez l’utilisation des namespaces et les ACL. Si vous utilisez des namespaces, documentez‑les et assignez les rôles au scope de chemin correct.

Blague n°2 (courte, pertinente) : « Datastore not found » est parfois juste PBS qui fait semblant de dire « tu n’es pas invité. »

Listes de contrôle / plan pas à pas (faites ceci, dans cet ordre)

Étapes : réparer la visibilité PVE ↔ PBS du datastore

1. Confirmez l’identité de l’endpoint.
   Depuis chaque nœud PVE : exécutez getent hosts pbs01. Assurez‑vous qu’il résout vers la bonne IP.
   Sinon, corrigez le DNS ou supprimez les entrées /etc/hosts obsolètes.
2. Confirmez la reachabilité réseau.
   Depuis chaque nœud PVE : nc -vz pbs01 8007.
   Si bloqué, corrigez les règles de pare‑feu (côté PBS et réseau) et le routage.
3. Confirmez le certificat/fingerprint TLS.
   Depuis PVE : capturez l’empreinte via openssl s_client.
   Comparez avec l’empreinte dans /etc/pve/storage.cfg. Si différente, mettez‑la à jour ou réajoutez le stockage.
4. Confirmez l’ID du datastore sur PBS.
   Sur PBS : proxmox-backup-manager datastore list.
   Copiez le name (ID), pas le chemin.
5. Confirmez la santé de PBS.
   Sur PBS : systemctl status proxmox-backup et proxmox-backup-manager datastore status.
   Si le service est down ou le datastore offline, réparez PBS d’abord.
6. Confirmez l’identité (realm) et l’usage des tokens.
   Sur PBS : proxmox-backup-manager user list et proxmox-backup-manager user token list backup@pbs.
   Privilégiez l’authentification par token depuis PVE.
7. Confirmez les permissions ACL.
   Sur PBS : proxmox-backup-manager acl list. Assurez‑vous que l’utilisateur/token a des rôles sur /datastore/<id>.
   Si vous utilisez des namespaces, scellez les permissions au bon scope.
8. Validez la configuration PVE.
   Sur PVE : inspectez /etc/pve/storage.cfg pour server, datastore, username, token, fingerprint.
9. Retry depuis PVE et lisez immédiatement les logs.
   Si ça échoue encore, allez directement dans journalctl -u pvedaemon -u pveproxy et recherchez « permission denied », soucis d’empreinte ou erreurs de connexion.

À éviter (parce que ça fait perdre des heures)

• Ne renommez pas les datastores pour « voir si ça aide. » Vous allez juste ajouter de la dérive et casser des références.
• Ne mettez pas PBS derrière un proxy sophistiqué à moins de garantir une identité backend stable et un comportement certifié constant.
• Ne donnez pas les droits admin complets pour « tester. » Créez un token dédié avec des rôles limités ; réduisez le blast radius.
• Ne déboguez pas depuis votre laptop en premier. Déboguez depuis un nœud PVE. C’est là que la panne se produit.

FAQ

1) Est‑ce que « datastore not found » signifie toujours que le nom du datastore est erroné ?

Non. Cela peut signifier un ID erroné, un endpoint PBS incorrect, une permission refusée masquée en « not found », un scoping namespace, ou des échecs d’empreinte/confiance.
Confirmez l’ID sur PBS et vérifiez les logs pour des erreurs de permission.

2) Qu’est‑ce exactement que l’« ID du datastore » dans PBS ?

C’est le name du datastore affiché par proxmox-backup-manager datastore list.
C’est un identifiant API, pas un chemin de système de fichiers.

3) Pourquoi ça marche dans l’UI PBS mais pas depuis PVE ?

L’UI PBS est généralement utilisée par un utilisateur privilégié local (souvent root@pam) et accédée localement ou via un chemin réseau différent.
PVE utilise ses propres identifiants et appelle l’API à distance ; identité différente, réseau différent, règles différentes.

4) Dois‑je utiliser des tokens API, ou puis‑je utiliser un mot de passe ?

Vous pouvez utiliser un mot de passe, mais les tokens sont le meilleur choix opérationnel : révocables, audités et plus faciles à restreindre.
En production, utilisez un utilisateur dédié et un token dédié pour PVE.

5) Quelles permissions PVE a‑t‑il besoin sur PBS pour les sauvegardes ?

Au minimum, les droits pour effectuer des sauvegardes vers le datastore cible (et souvent la capacité d’auditer/lister pour voir ce qui existe).
Les noms de rôle exacts varient selon votre politique ; le principe : n’accordez que ce dont PVE a besoin sur /datastore/<id>.

6) Un pare‑feu peut‑il causer « datastore not found » même si le ping passe ?

Oui. Le ping prouve presque rien. PBS requiert un TCP/8007 bout en bout. Utilisez nc -vz pbs01 8007 ou équivalent pour en être sûr.

7) J’ai changé le certificat PBS. Pourquoi PVE ne s’est‑il pas rétabli automatiquement ?

Parce que PVE épingle l’empreinte PBS pour sécurité. Cela empêche des attaques MITM silencieuses, mais signifie que vous devez mettre à jour l’empreinte
lorsque le certificat PBS change.

8) Comment les namespaces affectent‑ils la visibilité du datastore ?

Les namespaces peuvent restreindre ce qu’un utilisateur/token peut voir ou écrire. Un utilisateur peut accéder globalement au datastore mais être bloqué pour un namespace spécifique,
donnant l’impression que des éléments manquent. Alignez les ACL de namespace avec vos tâches de sauvegarde.

9) Est‑ce sûr d’éditer /etc/pve/storage.cfg à la main ?

Oui, si vous savez ce que vous faites et comprenez que cela se réplique sur le cluster PVE. Préférez l’interface pour les changements courants,
mais pour la réponse aux incidents, une édition manuelle soigneuse (avec contrôle de changement) est parfois la solution la plus rapide.

10) Pourquoi l’erreur n’apparaît‑elle que pendant « Ajouter un stockage » alors que les sauvegardes fonctionnaient avant ?

L’ajout de stockage déclenche des opérations de découverte/listing qui peuvent nécessiter des permissions supplémentaires par rapport à une configuration précédemment mise en cache.
De plus, les certificats et le DNS peuvent changer avec le temps ; l’empreinte stockée ou l’IP résolue peut maintenant différer.

Conclusion : prochaines étapes pratiques

« Datastore not found » est un problème de visibilité, pas une malédiction mystique du stockage. Traitez‑le comme toute autre intégration de production :
vérifiez l’endpoint, vérifiez le transport, vérifiez l’identité, vérifiez le nom de l’objet.

1. Depuis un nœud PVE : prouvez que pbs01:8007 est joignable et que le certificat est celui attendu.
2. Depuis PBS : confirmez l’ID du datastore via proxmox-backup-manager datastore list et qu’il est en ligne.
3. Depuis PBS : vérifiez que l’utilisateur/token existe et que les ACL incluent le datastore (et le namespace, si utilisé).
4. Depuis PVE : alignez /etc/pve/storage.cfg avec le bon server, datastore, username/token, et fingerprint.
5. Après la correction : lancez un test de sauvegarde et lisez immédiatement les logs si quelque chose semble anormal. Les systèmes silencieux se gagnent, ils ne s’assument pas.

Le meilleur résultat n’est pas « ça marche maintenant. » C’est « la prochaine fois que ça casse, l’astreint pourra prouver pourquoi en cinq minutes. »
Notez les IDs des datastores, les empreintes attendues, la règle de pare‑feu et le propriétaire du token. Rendez votre futur vous un peu moins en colère.