Proxmox PBS : Sauvegardes réussissent mais restaurations échouent — la checklist qui les attrape

Échecs de restauration : un modèle mental qui aide vraiment

PBS est conçu pour des sauvegardes efficaces, dédupliquées et incrémentales. Cette conception est précisément la raison pour laquelle « la sauvegarde réussit » n’est pas une preuve solide que « la restauration réussira ». Une sauvegarde réussie peut consister principalement à écrire en flux des nouveaux chunks dans un datastore, tandis qu’une restauration doit être capable de localiser, déchiffrer, vérifier et réhydrater un graphe potentiellement énorme de chunks à travers le temps, à travers des snapshots, à travers des namespaces, parfois à travers des permissions et des chemins réseau différents de ceux de la sauvegarde.

Les sauvegardes sont surtout le « chemin d’écriture » ; les restaurations sont le « chemin de lecture sous contrainte »

Les sauvegardes ont tendance à être des écritures séquentielles avec quelques mises à jour de métadonnées. Les restaurations amplifient la lecture : beaucoup de lectures de chunks aléatoires, décompression, vérification optionnelle, et plus de sensibilité à la latence. Si votre backend de stockage a des bizarreries (cache d’attributs NFS, mismatch de recordsize ZFS, SAN thin-provisioned qui ment, contrôleur RAID avec politiques de cache surprenantes), les restaurations les trouveront.

Trois couches doivent s’accorder : identité, intégrité et emplacement

• Identité : Vous devez être autorisé (PBS ACLs), et votre client doit présenter les identifiants ou le token API attendus. Les outils de restauration s’exécutent souvent sous une identité différente des jobs de sauvegarde.
• Intégrité : Le magasin de chunks doit être cohérent. Chunks manquants, chunks corrompus ou GC incomplet peuvent rester cachés jusqu’à une restauration ou une vérification.
• Emplacement : La route réseau, le DNS, le pare-feu, le MTU, le proxy, la confiance TLS et l’heure doivent s’aligner. Les sauvegardes peuvent emprunter un chemin ; les restaurations un autre (surtout si vous restaurez sur un nœud différent).

Une heuristique décente : si les sauvegardes sont vertes mais que les restaurations échouent, supposez d’abord chemin de lecture + permissions + jobs de cycle de vie, et supposez « mon logiciel de sauvegarde a menti » en dernier recours.

Plan de diagnostic rapide (premier/deuxième/troisième)

Voici le flux « arrêter l’hémorragie ». Exécutez-le dans l’ordre. Ne faites pas de freestyle. L’objectif est de trouver rapidement le goulot, puis d’approfondir uniquement si nécessaire.

Premier : identifiez quel type d’échec de restauration vous avez

1. Échec immédiat fort : permission refusée, erreur d’authentification, fingerprint mismatch, repository introuvable, erreurs TLS.
2. Échec net en cours de flux : chunks manquants, erreurs de checksum, erreurs I/O, système de fichiers en lecture seule.
3. Échec doux (blocage/lenteur) : bloqué à 0%, « toujours en cours », ETA fantaisiste.

Deuxième : confirmez les bases qui rendent les restaurations différentes des sauvegardes

1. Qui effectue la restauration ? Même utilisateur/token PBS que le job de sauvegarde ? Même namespace ? Même chemin ACL ?
2. Où restaurez-vous ? Nœud Proxmox différent, réseau différent, cible de stockage différente ?
3. PBS est-il sous charge à cause de prune/GC/verify ? Ces jobs peuvent être « corrects » pendant les sauvegardes et brutaux pendant les restaurations.

Troisième : choisissez une piste d’investigation approfondie

• Piste Auth/ACL/TLS si l’erreur apparaît avant que les données ne bougent.
• Piste intégrité du datastore si vous voyez des chunks manquants, des erreurs de vérification, ou des lectures de restauration défaillantes.
• Piste performance stockage si les restaurations sont lentes/bloquées et que le datastore est sur NFS/Ceph/ZFS-on-RAID.
• Piste réseau si vous observez des timeouts, des resets, des bizarreries MTU, ou si les restaurations échouent depuis un seul nœud.

Faits et contexte intéressants (pourquoi PBS se comporte ainsi)

• PBS utilise un magasin de chunks avec déduplication : les restaurations peuvent dépendre de chunks créés il y a des semaines, pas seulement de la sauvegarde d’hier soir.
• Prune et garbage collection sont des concepts distincts : prune supprime des références de snapshot ; GC récupère l’espace des chunks non référencés plus tard. Un snapshot peut disparaître « logiquement » avant que l’espace ne soit récupéré « physiquement ».
• La vérification n’est pas juste un bouton cosmétique : c’est votre système d’alerte précoce pour la corruption de chunks ou les écritures incomplètes qui n’apparaissent pas pendant la sauvegarde.
• Les sauvegardes incrémentales réduisent la charge d’écriture mais augmentent la profondeur de dépendance de restauration : plus vous comptez sur l’historique, plus vous avez besoin d’intégrité des chunks à long terme.
• Le chiffrement côté client change la forme des erreurs : mauvaise clé ou fichier de clé manquant ressemble souvent à « les données existent mais ne peuvent pas être lues », parce que c’est littéralement le cas.
• Les restaurations sont sensibles à la latence : un datastore sur un stockage à haute latence (ou NFS mal configuré) peut sauvegarder correctement mais restaurer péniblement à cause de l’amplification de lecture.
• Namespaces et ACLs sont puissants et tranchants : il est facile d’accorder les droits de sauvegarde sans accorder les droits de restauration, surtout quand les tokens sont fortement limités.
• Le temps compte plus qu’on ne le pense : TLS, validation de tickets et corrélation des logs deviennent pénibles quand les nœuds dérivent. Vous pouvez « authentifier » tout en cassant des transferts longue durée.
• « Sauvegarde réussie » signifie souvent « le serveur a accepté le flux » : cela ne garantit pas que le backend de stockage l’a conservé correctement pour des lectures ultérieures (bonjour disques aléatoires et sémantiques NFS).

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

Ces tâches sont conçues pour être exécutables sur une configuration Proxmox VE + PBS typique. Adaptez les noms d’hôte, les noms de datastore et les IDs. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision suivante.

Task 1: Check PBS service health (server-side)

cr0x@pbs01:~$ systemctl status proxmox-backup
● proxmox-backup.service - Proxmox Backup Server API and daemon
     Loaded: loaded (/lib/systemd/system/proxmox-backup.service; enabled)
     Active: active (running) since Tue 2026-02-04 08:11:02 UTC; 3h 12min ago
       Docs: man:proxmox-backup-api(1)
             man:proxmox-backup-proxy(1)
   Main PID: 1123 (proxmox-backup)
      Tasks: 14 (limit: 154225)
     Memory: 312.4M
        CPU: 19min 22.341s
     CGroup: /system.slice/proxmox-backup.service
             ├─1123 proxmox-backup-api
             └─1131 proxmox-backup-proxy

Signification : S’il n’est pas actif/en cours d’exécution, les restaurations échoueront de façons créatives (timeouts, 500, connection refused).

Décision : Si non en cours, réparez PBS d’abord (service, disque plein, config corrompue). Ne poursuivez pas des fantômes côté client.

Task 2: Read the restore-time logs, not the backup logs

cr0x@pbs01:~$ journalctl -u proxmox-backup --since "30 min ago" --no-pager
Feb 04 11:52:18 pbs01 proxmox-backup-api[1123]: authentication failed for user 'backup@pbs'
Feb 04 11:52:18 pbs01 proxmox-backup-api[1123]: permission check failed: missing Datastore.Read on /datastore/vmstore
Feb 04 11:52:21 pbs01 proxmox-backup-api[1123]: client disconnected (TLS error: alert bad certificate)

Signification : PBS vous dit souvent exactement quelle permission ou condition TLS a échoué. « Datastore.Read » manquant est le classique écart de ACL uniquement pour la restauration.

Décision : Si vous voyez des erreurs auth/ACL/TLS ici, arrêtez et corrigez identité/confiance avant de toucher au stockage.

Task 3: Confirm the datastore is mounted and writable (PBS host)

cr0x@pbs01:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
vmstore      dir        active      70368744177664    4966055936000   65402688241664    7%

Signification : « active » est bon. S’il est manquant/inactif, PBS peut toujours accepter des métadonnées mais échouer à lire des chunks, ou échouer en milieu de restauration.

Décision : Si inactif, réparez le montage (NFS down, pool ZFS dégradé, permissions) avant de tenter à nouveau une restauration.

Task 4: Check filesystem-level errors (read-only flips are real)

cr0x@pbs01:~$ dmesg -T | tail -n 20
[Mon Feb  4 11:41:07 2026] EXT4-fs error (device sdb1): ext4_find_entry:1453: inode #262145: comm proxmox-backup: reading directory lblock 0
[Mon Feb  4 11:41:07 2026] Aborting journal on device sdb1-8.
[Mon Feb  4 11:41:07 2026] EXT4-fs (sdb1): Remounting filesystem read-only

Signification : Si le système de fichiers de backing a été remonté en lecture seule, les restaurations échoueront (parfois après un démarrage réussi). Les sauvegardes ont pu réussir plus tôt avant le cliff.

Décision : Traitez cela comme un incident de stockage. Arrêtez les écritures PBS, réparez le système de fichiers, validez ensuite l’intégrité du datastore.

Task 5: Verify time synchronization (TLS and long sessions hate drift)

cr0x@pbs01:~$ timedatectl
               Local time: Tue 2026-02-04 12:03:44 UTC
           Universal time: Tue 2026-02-04 12:03:44 UTC
                 RTC time: Tue 2026-02-04 12:03:45
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : Si « System clock synchronized: no » sur PBS ou les nœuds PVE, attendez-vous à des bizarreries de validation de certificat, confusion d’expiration de tokens et logs difficiles à corréler.

Décision : Réparez l’heure d’abord. C’est rapide et cela élimine une classe entière de pannes « impossibles ».

Task 6: Confirm API connectivity and fingerprint (client-side trust)

cr0x@pve01:~$ proxmox-backup-manager cert info
Subject Name: /CN=pbs01
Issuer Name: /CN=pbs01
Valid Since: 2025-09-14 09:20:48
Valid Until: 2035-09-12 09:20:48
Fingerprint (sha256): 7E:1A:3B:9F:4B:41:2C:2A:9B:AD:9C:3D:25:0C:11:1A:AF:3A:0F:DE:41:19:92:33:6E:9B:7A:45:4F:0C:8A:21

Signification : Un fingerprint différent entre ce que le client fait confiance et ce que PBS présente cause des pannes soudaines après réinstallation ou régénération de certificat.

Décision : Si PBS a été reconstruit ou si son certificat a changé, rétablissez la confiance du nouveau fingerprint sur les nœuds PVE (et documentez-le).

Task 7: Validate the repository config on the node doing the restore

cr0x@pve01:~$ cat /etc/pve/storage.cfg
pbs: pbs-vmstore
        datastore vmstore
        server pbs01
        content backup
        fingerprint 7E:1A:3B:9F:4B:41:2C:2A:9B:AD:9C:3D:25:0C:11:1A:AF:3A:0F:DE:41:19:92:33:6E:9B:7A:45:4F:0C:8A:21
        username backup@pbs
        token backup-token
        namespace prod

Signification : Les restaurations se font depuis la vue PVE du PBS. Mauvais namespace, mauvais username/token, ou fingerprint obsolète cassera la restauration même si des sauvegardes depuis un autre nœud fonctionnent toujours.

Décision : Alignez storage.cfg sur tous les nœuds susceptibles d’effectuer des restaurations. Ne supposez pas que le « nœud de sauvegarde » est le « nœud de restauration ».

Task 8: Check PBS ACLs for restore permissions (server-side)

cr0x@pbs01:~$ proxmox-backup-manager acl list
/path /datastore/vmstore, user backup@pbs, role DatastoreBackup
/path /datastore/vmstore, user restore-ops@pbs, role DatastoreReader
/path /, user root@pam, role Administrator

Signification : Un rôle comme « DatastoreBackup » peut suffire pour les sauvegardes mais pas pour le browsing/restauration, selon votre configuration et vos outils. Les permissions Reader (ou plus) peuvent être requises pour les workflows de restauration.

Décision : Assurez-vous que l’identité utilisée pour la restauration dispose des droits de lecture nécessaires sur le chemin du datastore et le namespace correct. Si vous utilisez des tokens API, assurez-vous que le token n’est pas plus restreint que l’utilisateur.

Task 9: List snapshots and ensure you’re restoring what you think you are

cr0x@pbs01:~$ proxmox-backup-client snapshot list --repository backup@pbs@pbs01:vmstore --ns prod | head
vm/101/2026-02-03T01:00:12Z
vm/101/2026-02-02T01:00:10Z
vm/101/2026-02-01T01:00:09Z
ct/203/2026-02-03T01:10:05Z
ct/203/2026-02-02T01:10:02Z

Signification : Si le snapshot que vous voulez n’apparaît pas sous le namespace que vous utilisez, les restaurations « échoueront » en ne trouvant rien.

Décision : Confirmez le namespace et le type de groupe de sauvegarde (vm vs ct vs host). Ne perdez pas une heure à restaurer la mauvaise chose parfaitement.

Task 10: Run a datastore verify and interpret the results (integrity track)

cr0x@pbs01:~$ proxmox-backup-manager datastore verify vmstore --ignore-verified 1
starting datastore verify: vmstore
found 8123 snapshot(s)
verified 131072 chunks (12.5 GiB)
ERROR: missing chunk 3a2f0f9d3c0a... referenced by vm/101/2026-02-03T01:00:12Z
ERROR: verification failed: 1 errors found

Signification : « missing chunk » n’est pas un problème cosmétique. Ce snapshot (et possiblement d’autres) ne peut pas être restauré complètement.

Décision : Cessez les suppositions. Maintenant vous faites du triage d’incident : identifiez le rayon d’impact (blast radius), vérifiez la santé du backend de stockage, et décidez si vous pouvez restaurer depuis un snapshot plus ancien ou depuis un autre datastore/réplica.

Task 11: Check prune/GC schedules and current running tasks (contention track)

cr0x@pbs01:~$ proxmox-backup-manager task list --running 1
UPID:pbs01:0000A1B3:0001C2D4:67A1F2C3:garbage_collection:vmstore:root@pam:
UPID:pbs01:0000A1C0:0001C2F1:67A1F2DA:verify:vmstore:root@pam:

Signification : GC + verify pendant que vous tentez une grosse restauration, c’est comme programmer des travaux routiers pendant une évacuation. Ça peut fonctionner, mais c’est un choix.

Décision : Pour des restaurations urgentes, mettez en pause ou replanifiez les tâches de maintenance lourdes. Relancez ensuite la restauration et observez si le mode d’échec passe de « timeout/lent » à « fonctionne ».

Task 12: Measure datastore I/O latency the simple way (is storage lying?)

cr0x@pbs01:~$ iostat -x 1 5
Linux 6.5.11 (pbs01)  02/04/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.12    0.00    2.98   22.45    0.00   70.45

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sdb              82.0   310.0  9120.0 50240.0  87.35   3.12  99.80

Signification : Un await élevé et une utilisation proche de 100% indiquent que le sous-système disque est saturé ou en difficulté. Les restaurations sont punies en premier car elles sont axées lecture et sensibles à la latence.

Décision : Si await est élevé, vous ne déboguez pas PBS ; vous déboguez la performance et la contention du stockage. Envisagez de déplacer le datastore, d’ajouter un cache, ou de réduire les jobs concurrents.

Task 13: Confirm network stability and MTU assumptions (timeout track)

cr0x@pve01:~$ ping -M do -s 8972 -c 3 pbs01
PING pbs01 (10.10.10.20) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- pbs01 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Signification : Quelqu’un a supposé des jumbo frames de bout en bout. Ils avaient tort. Les sauvegardes peuvent tolérer la fragmentation ou des schémas de flux différents ; les restaurations peuvent tomber sur un chemin qui ne les accepte pas.

Décision : Corrigez le MTU de façon cohérente sur le chemin ou abandonnez et utilisez 1500 partout. Un MTU mixte est un générateur d’incidents lent mais sûr.

Task 14: Confirm DNS and reverse DNS (the boring culprit)

cr0x@pve01:~$ getent hosts pbs01
10.10.10.20     pbs01 pbs01.internal

Signification : Si la résolution de noms diffère entre les nœuds, vous pouvez finir par faire confiance à un nom de certificat mais vous connecter via un autre, ou router différemment pour les restaurations.

Décision : Standardisez la façon dont les nœuds PVE réfèrent PBS (nom vs IP), et faites correspondre le CN/SAN du certificat à cette réalité.

Task 15: Attempt a file-level restore mount (tests read path without overwriting VMs)

cr0x@pve01:~$ proxmox-backup-client mount vm/101/2026-02-03T01:00:12Z drive-scsi0 --repository backup@pbs@pbs01:vmstore --ns prod /mnt/pbs-test
mounted file system at "/mnt/pbs-test"

Signification : Si le montage échoue avec des chunks manquants ou des erreurs de permission, vous avez reproduit la panne de restauration de façon à faible risque.

Décision : Utilisez ceci comme test prévol après toute correction. Si le montage fonctionne et que la navigation dans les fichiers est OK, une restauration complète a beaucoup plus de chances de réussir.

Task 16: Inspect backup group ownership and encryption mode (when keys are the problem)

cr0x@pve01:~$ proxmox-backup-client snapshot list --repository backup@pbs@pbs01:vmstore --ns prod --output-format json | head -n 5
[
  {"backup-id":"101","backup-time":1706922012,"backup-type":"vm","comment":null},
  {"backup-id":"101","backup-time":1706835610,"backup-type":"vm","comment":null},
  {"backup-id":"101","backup-time":1706749209,"backup-type":"vm","comment":null},
  {"backup-id":"203","backup-time":1706922605,"backup-type":"ct","comment":null},

Signification : Le listing de snapshots fonctionne, mais la restauration peut quand même échouer si les clés de chiffrement sont manquantes sur l’hôte de restauration. Lister les métadonnées est moins coûteux que déchiffrer le payload.

Décision : Si vous utilisez un chiffrement côté client, validez que les fichiers de clé sont présents et accessibles sur le nœud de restauration (et correctement protégés). Ne « désactivez » pas temporairement le chiffrement pour la commodité en oubliant ensuite.

Blague n°1 : Les sauvegardes sont comme des parachutes — en avoir un est agréable, mais vous ne savez s’il fonctionne qu’au moment où vous en avez vraiment besoin.

Erreurs courantes : symptôme → cause racine → correction

1) « Permission denied » pendant la restauration, mais les sauvegardes tournent la nuit

Symptôme : La restauration échoue immédiatement ; les logs montrent missing Datastore.Read ou permission namespace.

Cause racine : Le token/utilisateur de sauvegarde a les droits pour pousser des sauvegardes mais pas pour parcourir/restaurer les snapshots, ou la restauration est tentée depuis un nœud différent avec un token différent.

Correction : Accordez à l’identité de restauration les permissions de lecture sur le chemin du datastore et le namespace correct. Alignez /etc/pve/storage.cfg entre les nœuds. Préférez une identité « restore-ops » dédiée avec un scope contrôlé.

2) « Fingerprint mismatch » après maintenance PBS

Symptôme : Le client refuse de se connecter ; erreurs sur l’empreinte du certificat ou bad certificate.

Cause racine : Le certificat PBS a été régénéré (réinstallation, changement de hostname), mais les nœuds PVE font encore confiance à l’ancien fingerprint dans storage.cfg.

Correction : Mettez à jour le fingerprint partout. Standardisez l’identité PBS (hostname stable) et traitez la régénération de certificat comme une modification contrôlée.

3) Restauration échoue en cours avec « missing chunk » ou erreurs de vérification

Symptôme : La restauration démarre puis échoue avec références de chunk manquantes ; verify du datastore montre des erreurs.

Cause racine : Corruption du stockage sous-jacent, écritures incomplètes, erreurs de filesystem, disques défaillants, ou datastore déplacé/copied incorrectement (rsync sans xattrs/permissions, incohérence de snapshot).

Correction : Arrêtez la charge d’écriture, réparez la couche stockage (SMART, RAID, ZFS scrub, fsck si approprié), lancez verify, identifiez le dernier snapshot connu bon, et restaurez depuis celui-ci. Si vous avez un datastore répliqué, basculez vers lui.

4) Restauration « bloque » ou est extrêmement lente ; les sauvegardes vont bien

Symptôme : Le job de restauration tourne mais la progression est très lente ; iowait explose ; PBS semble léthargique.

Cause racine : L’amplification de lecture rencontre un stockage lent (latence NFS, disques SMR, RAID HDD surchargé, ZFS réglé pour le débit plutôt que la latence), ou prune/GC/verify s’exécutent en même temps.

Correction : Mettez en pause les tâches de maintenance lourdes pendant les restaurations, mesurez la latence disque (iostat), et déplacez le datastore vers un stockage adapté aux lectures aléatoires (SSD, cache approprié, niveau RAID adapté). Si vous êtes sur NFS, revoyez les options de montage et les performances du serveur.

5) « Snapshot existe mais ne peut pas être trouvé » dans l’UI ou via CLI

Symptôme : Les sauvegardes apparaissent dans une vue mais pas pour le workflow de restauration ; erreurs « group not found ».

Cause racine : Mismatch de namespace, définition de repository différente, ou tentative de restaurer une sauvegarde VM en tant que CT (ou inversement).

Correction : Confirmez --ns et le type de groupe. Listez les snapshots depuis le même nœud et la même identité utilisée pour la restauration.

6) Les restaurations échouent seulement depuis un nœud Proxmox

Symptôme : Restauration réussit depuis pve02 mais échoue depuis pve01 avec timeouts ou erreurs TLS.

Cause racine : Dérive par nœud de storage.cfg, règles de pare-feu, routage, différences DNS, ou mismatch MTU sur un chemin spécifique.

Correction : Comparez les configs. Exécutez les mêmes tests de connectivité depuis les deux nœuds. Standardisez et automatisez la distribution de configuration quand c’est possible.

7) Les restaurations échouent après « optimisation » de rétention/GC

Symptôme : Après modification des plans de prune ou de rétention, d’anciennes restaurations échouent, ou les restaurations deviennent lentes en heures ouvrées.

Cause racine : GC déplacé en heures de pointe, ou politique de prune qui a supprimé des snapshots que vous pensiez encore avoir. Parfois « keep-last » suffit jusqu’à ce que vous réalisiez qu’il vous fallait « keep-daily » pour la conformité.

Correction : Placez GC et verify en heures creuses. Modélisez les politiques de rétention en fonction des besoins réels de restauration (RPO/RTO et exigences d’audit), pas seulement de l’anxiété liée à l’espace disque.

Trois mini-histoires d’entreprise (comment ça casse en vrai)

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

L’entreprise disposait d’un cluster Proxmox propre et d’un seul appliance PBS sur un stockage suffisamment rapide. Les sauvegardes étaient vertes pendant des mois. Personne n’a fait attention. Puis un hôte a lâché et ils ont eu besoin de restaurer une VM de production sur un nœud différent. La restauration a échoué instantanément : permission refusée.

L’hypothèse erronée était subtile : « le token qui peut sauvegarder peut aussi restaurer. » Leur token de sauvegarde était très restreint (bonne intention), mais il n’avait que les droits alignés avec le workflow de sauvegarde. Les restaurations n’avaient jamais été testées depuis un nœud non primaire, et le token stocké dans /etc/pve/storage.cfg sur les autres nœuds était… différent. Un ingénieur avait copié un extrait de config des semaines plus tôt et utilisé un utilisateur placeholder qui n’avait pas les droits Datastore.Read.

Ils ont perdu du temps à déboguer le stockage et le réseau parce que les logs de sauvegarde semblaient parfaits. Pendant ce temps, les logs PBS étaient francs : missing Datastore.Read. Une fois la config du repository alignée sur les nœuds et un rôle de restauration dédié créé avec des ACL explicites, les restaurations ont fonctionné immédiatement.

La suite fut la vraie correction : ils ont ajouté un exercice mensuel « restaurer depuis un nœud aléatoire » et traité storage.cfg comme une configuration qui ne doit pas diverger. La coche verte de la sauvegarde est redevenue un signal utile, pas un mensonge réconfortant.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait poussé une optimisation de réduction de coûts. Ils ont déplacé le datastore PBS des disques locaux vers un NFS existant parce que « ce sont juste des backups ». Les sauvegardes restaient correctes — principalement des écritures séquentielles nocturnes, déduplication en marche, personne ne se plaignait. Puis une simulation de ransomware est devenue un test de restauration. Les restaurations étaient si lentes qu’elles étaient inutilisables.

Le backend NFS avait un bon débit mais une latence médiocre sous concurrence. Les restaurations l’ont martelé avec des lectures de chunks pendant que le filer servait aussi des home directories et des artefacts CI. Pendant la fenêtre de restauration, GC tournait aussi parce que quelqu’un avait replanifié la maintenance « en journée quand il y a du monde ». Cette décision a transformé une restauration lente en quelque chose d’impossible.

Ils ont tenté d’ajuster les options de montage NFS et d’ajouter de la bande passante réseau. Cela a aidé un peu, pas assez. Le problème sous-jacent était physique : les restaurations chunkées et dédupliquées ne sont pas un workload séquentiel, et elles puniront la latence et les performances metadata. Finalement, ils ont remis PBS sur un stockage SSD local et programmé GC/verify en heures creuses uniquement.

Ils ont aussi appris une leçon cruelle : optimiser pour la « réussite des sauvegardes » n’est pas optimiser pour la « récupération métier ». Ce sont des objectifs liés, pas identiques.

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

Un environnement régulé. Beaucoup de processus. Le genre d’endroit où vous ne pouvez pas simplement « SSHer et voir ce qui se passe ». L’équipe stockage insistait sur des tests de restauration trimestriels avec preuves : restauration sur un réseau isolé, validation du boot, et comparaison de checksum pour un jeu de données connu. Tout le monde râlait parce que c’était du travail prévisible et personne n’allait recevoir une promotion pour ça.

Un trimestre, le test de restauration a échoué. Pas catastrophiquement — juste une erreur de missing chunk sur un sous-ensemble de snapshots. Parce que le test était routinier, il est arrivé assez tôt pour que les données affectées soient encore disponibles depuis un snapshot plus ancien et depuis une copie hors ligne. Ils l’ont traité comme un incident d’intégrité stockage, pas comme un couac isolé.

La cause racine était des erreurs de disque intermittentes sur l’hôte PBS qui n’avaient pas encore déclenché d’alertes évidentes. Les compteurs SMART montaient, mais le système « fonctionnait » encore. La vérification l’a détecté. Les tests de restauration ont prouvé que ça comptait. Ils ont remplacé les disques, revérifié, et documenté l’incident avec un langage calme et des actions claires.

Quand une restauration de production réelle fut nécessaire des mois plus tard, elle a fonctionné. Personne n’a applaudi. C’est le but.

Checklists / plan étape par étape (rendre les restaurations ennuyeuses)

Checklist A: When a restore fails right now (triage)

1. Capturez l’erreur exacte depuis l’UI/CLI de restauration et le journal PBS autour du même timestamp.
2. Classez : auth/ACL/TLS vs missing chunks vs timeout/lent vs erreurs du stockage cible.
3. Confirmez l’identité : même user/token/namespace sur le nœud effectuant la restauration.
4. Confirmez l’état du datastore : monté, inscriptible, pas de remount read-only, pas de pool dégradé.
5. Vérifiez les tâches en cours : mettez en pause GC/verify si vous avez besoin d’une restauration rapide.
6. Faites un test à faible risque : montage fichier du snapshot (prouve le chemin de lecture) avant restauration complète de VM.
7. Si erreurs d’intégrité : lancez datastore verify, déterminez le blast radius, choisissez le dernier point de restauration connu bon.

Checklist B: Weekly hygiene that prevents “green backups, dead restores”

1. Lancez datastore verify sur une cadence adaptée à la taille du datastore et au taux de changement. Faites-le tourner sur les snapshots si nécessaire.
2. Revoyez la planification prune et GC pour qu’elles ne concurrencent jamais les fenêtres de restauration ou les pics de production.
3. Vérifiez la santé du stockage (SMART, RAID, ZFS scrubs) et alertez sur les signaux précoces, pas seulement sur les pannes.
4. Standardisez la config du repository sur tous les nœuds PVE ; considérez la dérive comme un bug.
5. Effectuez un drill de restauration (mount + restauration sélective de fichiers + restauration complète de VM au moins trimestriellement).

Checklist C: Hardening decisions (what I’d actually do)

• Identités séparées : un token pour les jobs de sauvegarde, un autre pour les opérations de restauration, tous deux au moindre privilège mais pas self-sabotaging.
• Préférer datastore local SSD pour PBS si vous tenez à l’objectif RTO. NFS peut fonctionner, mais il faut le concevoir pour la latence et les metadata, pas seulement le débit.
• Utiliser la réplication si le datastore est critique : c’est votre assurance contre la corruption et la défaillance d’un hôte unique. Des sauvegardes qui ne se restaurent pas sont de l’art performance.
• Planifier verify + GC intentionnellement : heures creuses, et jamais en chevauchement avec votre pic d’ingestion de sauvegarde si possible.
• Documenter le processus d’empreinte de certificat et traiter les reconstructions PBS comme des changements nécessitant des étapes de re-trust.

Blague n°2 : Si votre politique de rétention est « garder tout pour toujours », félicitations — vous avez inventé une façon très coûteuse d’éviter de prendre des décisions.

Une citation opérationnelle pour rester honnête

Tout échoue, tout le temps. — Werner Vogels

C’est court, peu réconfortant, et opérationnellement correct. Conceptionnez votre pratique de restauration autour de cette idée.

FAQ

1) Pourquoi les sauvegardes peuvent-elles réussir si le datastore a des problèmes d’intégrité ?

Parce que le chemin de sauvegarde peut réussir à accepter de nouveaux chunks et écrire des métadonnées même si d’anciens chunks sont manquants/corrompus. Les restaurations ont souvent besoin de ces vieux chunks pour reconstruire un snapshot. La vérification et les exercices de restauration font remonter cela.

2) Quel est le test de restauration le plus rapide et sûr sans écraser une VM ?

Utilisez proxmox-backup-client mount sur un snapshot récent et parcourez quelques fichiers. Cela exerce l’authentification, l’accès au namespace, les lectures de chunks et la décompression avec un risque minimal.

3) Le NFS est-il une mauvaise idée pour les datastores PBS ?

Pas intrinsèquement, mais c’est facile à mal configurer. Les sauvegardes sont tolérantes aux écritures ; les restaurations sont sensibles à la latence des lectures. Si votre serveur NFS est partagé, a des pics de latence, ou des caches bizarres, les restaurations en pâtiront d’abord. Si vous devez utiliser NFS, mesurez les performances de restauration sous charge et planifiez correctement les jobs de maintenance.

4) Comment les namespaces causent-ils des problèmes « restauration introuvable » ?

Les namespaces partitionnent les groupes de sauvegarde. Si votre nœud PVE est configuré pour utiliser namespace prod mais que les sauvegardes ont été écrites dans le namespace root (ou un autre), le listing diffèrera et les workflows de restauration ne trouveront pas le snapshot attendu. Confirmez toujours avec snapshot list en utilisant le même --ns.

5) Quelle est la relation entre prune et garbage collection ?

Prune supprime les références de snapshot selon la rétention. La garbage collection récupère les chunks qui ne sont plus référencés. Vous pouvez prune agressivement et ne pas récupérer l’espace tant que GC n’a pas tourné. Inversement, lancer GC au mauvais moment peut priver restaurations et sauvegardes d’I/O.

6) Les restaurations échouent seulement depuis un nœud. Que comparer en premier ?

/etc/pve/storage.cfg (username/token/namespace/fingerprint), résolution DNS (getent hosts), différences de routage/pare-feu, et paramètres MTU. En pratique, la dérive de configuration par nœud est le coupable le plus fréquent.

7) À quelle fréquence devrais-je lancer datastore verify ?

Assez souvent pour détecter la corruption avant que votre fenêtre de rétention n’élimine les bons points de restauration. Pour beaucoup d’environnements : verify quotidien ou hebdomadaire des snapshots récents, plus une vérification roulante des snapshots plus anciens. Le calendrier exact dépend de la taille du datastore et de la capacité de performance.

8) Que signifie généralement « missing chunk », et peut-on le réparer ?

Cela signifie qu’un fichier de chunk référencé est absent du datastore, souvent dû à une perte de stockage, corruption, ou migration/copie incomplète. La réparation n’est pas magique ; typiquement vous restaurez depuis un autre snapshot qui ne référence pas le chunk manquant, depuis un datastore répliqué, ou depuis une copie indépendante.

9) Ai-je besoin de tokens séparés pour sauvegarde et restauration ?

Vous n’en avez pas besoin, mais vous devriez en avoir. Cela réduit le blast radius et rend l’audit plus simple. Veillez juste à ne pas scoper le token de sauvegarde si étroitement que personne ne peut restaurer sous pression.

10) Pourquoi les restaurations exposent-elles plus les problèmes de performance que les sauvegardes ?

Les restaurations dédupliquées effectuent beaucoup de lectures de chunks et peuvent être intensives en I/O aléatoire. Les sauvegardes ont tendance à être plus séquentielles et tolérantes. Si votre backend de stockage a une latence élevée ou est saturé, les restaurations seront les premières à paraître « cassées ».

Étapes suivantes (que faire cette semaine)

1. Effectuer un drill de restauration depuis un nœud non primaire : montez un snapshot, puis restaurez une VM dans un réseau isolé. Enregistrez les étapes et les durées.
2. Planifier verify et GC intentionnellement : heures creuses, pas de chevauchement avec l’ingestion de sauvegarde, et pas pendant votre fenêtre réaliste de restauration.
3. Auditer les identités et ACLs : assurez-vous que le chemin de restauration a Datastore.Read et l’accès au namespace correct. Cessez de compter sur « ça a marché pour les sauvegardes ».
4. Mesurer la latence du stockage sous charge de restauration : si iostat montre un await affreux, traitez cela comme un problème de conception du stockage, pas un bug PBS.
5. Standardiser la configuration du repository : même fingerprint, mêmes conventions de namespace, même gestion des tokens sur tous les nœuds PVE.

L’objectif final n’est pas « sauvegardes réussies ». L’objectif final est « restaurations ennuyeuses ». Si vous pouvez restaurer à la demande, sous pression, sans héroïsme, vous avez construit quelque chose de réel.