Proxmox Backup Manager : Vérifier et Auditer un Datastore

Vérifier l'intégrité d'un datastore Proxmox Backup Server (PBS) constitue un pilier souvent négligé de toute stratégie de sauvegarde robuste. Au-delà du simple backup quotidien, la commande proxmox-backup-manager datastore verify garantit que chaque chunk déduplikué stocké sur disque correspond bien à son hash SHA-256 d'origine, détectant ainsi la corruption silencieuse (bit rot), les défaillances matérielles latentes et les erreurs de système de fichiers. Ce guide exhaustif explore l'ensemble du cycle de vérification d'un datastore PBS : commandes CLI complètes avec leurs options (--backup-id, --since, --outdated-after, --filter), audit du status (espace, déduplication, garbage collection), planification automatique via jobs PBS et cron Linux, gestion des erreurs de corruption, optimisation des performances multi-thread, intégration au monitoring Prometheus/Grafana, gestion du chiffrement et stratégies de récupération. Vous trouverez également trois scénarios concrets (disque défaillant, après upgrade majeur, post-migration) ainsi qu'une FAQ détaillée. Cet article s'adresse aux administrateurs Proxmox confirmés gérant des environnements de production où la fiabilité des sauvegardes n'est pas négociable.

1. Pourquoi vérifier un datastore PBS

La sauvegarde n'est utile que si elle est restaurable. Pourtant, dans la plupart des incidents majeurs, la cause racine n'est pas l'absence de sauvegarde mais sa corruption non détectée. Proxmox Backup Server stocke les données sous forme de chunks de 4 Mo déduplikués, indexés par leur SHA-256. Cette architecture, héritée de restic et borgbackup, est exceptionnellement résiliente — à condition d'auditer régulièrement l'intégrité physique des chunks sur le filesystem sous-jacent.

1.1 La corruption silencieuse (bit rot)

Les disques modernes (HDD ou SSD) ne sont pas exempts de défaillances silencieuses. Un secteur magnétique peut perdre quelques bits sans que le firmware ne signale d'erreur S.M.A.R.T. Les études Backblaze et CERN documentent un taux de bit rot d'environ 1 bit pour 10^14 à 10^15 bits lus. Sur un datastore de 50 To, cela représente statistiquement plusieurs erreurs par an. Sans vérification active, cette corruption reste invisible jusqu'à la tentative de restauration — moment fatal.

1.2 Le rôle complémentaire de ZFS scrub

Si vous hébergez votre datastore PBS sur ZFS (recommandé), zpool scrub détecte et corrige automatiquement les erreurs grâce au checksumming au niveau du pool. Toutefois, ZFS scrub vérifie l'intégrité du filesystem, pas la cohérence cryptographique des chunks PBS avec le manifest des sauvegardes. Un chunk peut être physiquement intact sur ZFS tout en étant absent ou corrompu logiquement dans le manifest PBS suite à un crash ou un bug. Verify et scrub sont donc complémentaires, pas redondants. Pour aller plus loin sur ZFS, consultez notre guide de dimensionnement Proxmox.

1.3 Intégrité des chunks et du manifest

Chaque sauvegarde PBS produit un fichier index.json (manifest) listant les hashes SHA-256 des chunks composant le snapshot. La commande verify recharge ces hashes, lit chaque chunk depuis .chunks/, recalcule son SHA-256 et compare. Toute divergence entraîne le marquage du snapshot comme verify failed avec horodatage dans la base. Ce processus est strictement non destructif : verify ne modifie jamais les données, seulement les métadonnées de vérification.

1.4 Le coût du défaut de vérification

Imaginez le scénario suivant : un ransomware chiffre 800 VMs en production, vous déclenchez le plan de reprise et lancez la restauration depuis PBS. Au bout de 3 heures, sur la VM SQL Server critique, la restauration échoue : chunk corrupted. Aucune autre sauvegarde disponible — l'incident s'est propagé au datastore réplica. Cette situation, malheureusement vécue par plusieurs organisations en 2024-2025, illustre pourquoi la vérification proactive n'est pas optionnelle. Le RTO (Recovery Time Objective) ne peut être respecté que si l'intégrité a été validée avant l'incident, pas découverte pendant.

1.5 Architecture interne du datastore PBS

Un datastore PBS sur disque ressemble à ceci :

/mnt/datastore/prod-bkp/
├── .chunks/
│   ├── 0000/
│   ├── 0001/
│   ├── ...
│   └── ffff/  (65536 sous-répertoires hexadécimaux)
├── vm/101/
│   ├── 2026-05-08T22:00:00Z/
│   │   ├── index.json.blob
│   │   ├── client.log.blob
│   │   ├── drive-scsi0.img.fidx
│   │   └── drive-scsi1.img.fidx
│   └── 2026-05-07T22:00:00Z/
└── ct/200/
    └── 2026-05-08T22:00:00Z/
        ├── index.json.blob
        └── root.pxar.didx

Les fichiers .fidx (fixed index) référencent les chunks de disques VM ; les .didx (dynamic index) ceux des containers et fichiers. Verify parcourt ces index, lit chaque chunk dans .chunks/XXXX/ et valide cryptographiquement.

2. La commande datastore verify : syntaxe et options

La commande de référence pour auditer un datastore est proxmox-backup-manager datastore verify. Elle s'exécute sur l'hôte PBS (pas sur l'hyperviseur PVE) et nécessite les droits Datastore.Verify sur le datastore ciblé.

2.1 Syntaxe générale

proxmox-backup-manager datastore verify <store> [OPTIONS]

Le paramètre <store> est le nom du datastore tel que défini dans /etc/proxmox-backup/datastore.cfg. Exemple minimal pour un datastore nommé prod-bkp :

proxmox-backup-manager datastore verify prod-bkp

Sans option, la commande vérifie l'intégralité des snapshots du datastore. Sur un volume de plusieurs téraoctets, cela peut prendre plusieurs heures. Les options de filtrage permettent de cibler un sous-ensemble.

3.2 Option --backup-id pour cibler une VM ou un CT

Pour vérifier uniquement les sauvegardes d'une VM ou d'un container LXC spécifique, utilisez --backup-id couplé à --backup-type :

proxmox-backup-manager datastore verify prod-bkp \
  --backup-type vm \
  --backup-id 101

Ici, seules les sauvegardes de la VM 101 seront auditées. Les types valides sont vm, ct et host (pour les sauvegardes de fichiers via proxmox-backup-client). Cette granularité est utile après une restauration partielle ou une investigation forensique.

2.3 Filtrage temporel : --since et --outdated-after

Deux options complémentaires gèrent le périmètre temporel :

• --ignore-verified : ignore les snapshots déjà vérifiés avec succès récemment.
• --outdated-after <jours> : revérifie uniquement les snapshots dont la dernière vérification date de plus de N jours. Valeur typique : 30 ou 60.

proxmox-backup-manager datastore verify prod-bkp \
  --ignore-verified true \
  --outdated-after 30

Cette combinaison est la base d'une stratégie incrémentale : un job hebdomadaire qui ne revisite que les sauvegardes anciennes, économisant 80% du temps machine.

2.4 Sortie structurée avec --output-format

Pour intégration dans un pipeline de monitoring, le drapeau --output-format accepte text (défaut), json, json-pretty. La sortie JSON est directement parsable :

proxmox-backup-manager datastore verify prod-bkp \
  --output-format json | jq '.[] | select(.state=="failed")'

Vous pouvez ainsi extraire les snapshots en échec et déclencher une alerte. Voir notre guide d'optimisation Proxmox pour des exemples d'industrialisation.

2.5 Filtrer par groupe avec --filter

L'option --filter (PBS 3.1+) accepte une expression de filtrage sur les groupes de sauvegarde. Syntaxe :

proxmox-backup-manager datastore verify prod-bkp \
  --filter 'vm/1*'

Vérifie toutes les VMs dont l'ID commence par 1 (100, 101, 110, 199, etc.). Vous pouvez combiner plusieurs filtres séparés par des virgules. Cette syntaxe est précieuse pour des environnements multi-tenants où vous regroupez les VMs par tranches d'IDs (par client, par environnement).

2.6 Verify d'un snapshot unique

Pour cibler un snapshot précis (debug, audit forensique), spécifiez le triplet type/id/timestamp :

proxmox-backup-manager datastore verify prod-bkp \
  --backup-type vm \
  --backup-id 101 \
  --backup-time 2026-05-08T22:00:00Z

Le timestamp doit être au format ISO-8601 UTC strict. Cette commande est utile lorsque vous suspectez un snapshot précis suite à une alerte applicative (ex. base SQL Server qui ne restaure pas correctement).

2.7 Dry-run et simulation

Verify lui-même est un dry-run par nature : il n'écrit jamais sur les chunks. Toutefois, certaines automatisations enchaînent verify + actions correctives (suppression des snapshots failed). Pour ces pipelines, ajoutez une étape de validation manuelle avant action destructive — un --ignore-verified false --dry-run n'existe pas en PBS, donc l'isolation logique se fait dans le script orchestrateur.

3. Audit capacitaire : datastore status

La commande proxmox-backup-manager datastore status est l'outil de diagnostic capacitaire. Elle ne vérifie pas l'intégrité mais expose en temps réel l'utilisation, le taux de déduplication et la santé fonctionnelle du datastore.

3.1 Lecture du status

proxmox-backup-manager datastore status prod-bkp

Sortie typique :

Datastore: prod-bkp
  Total: 50.00 TiB
  Used:  18.42 TiB (36.84%)
  Avail: 31.58 TiB
  Estimated Full Date: 2027-08-12
  Deduplication Factor: 4.21x
  Last GC: 2026-05-06 03:00:01
  Last Verify: 2026-05-05 04:12:33

Quatre métriques critiques émergent : taux d'utilisation, projection de saturation, ratio de déduplication, dates des derniers GC et verify. Surveillez surtout l'Estimated Full Date : si elle tombe à moins de 90 jours, planifiez une extension ou un prune agressif.

3.2 Comprendre le facteur de déduplication

Un ratio inférieur à 2x suggère un sous-dimensionnement du chunk size, des données déjà compressées (vidéo, archives), ou un nombre insuffisant de snapshots historiques pour amortir la déduplication. Au-dessus de 5x, vous bénéficiez pleinement du modèle PBS. La stratégie 3-2-1 immutable exploite ce ratio pour stocker davantage d'historique sans exploser la facture stockage.

3.3 Garbage Collection et prune

Le GC est un processus en deux phases : mark (parcours des manifests) puis sweep (suppression des chunks orphelins). Sans GC régulier, l'espace ne se libère jamais, même après prune. Configurez un GC hebdomadaire :

proxmox-backup-manager garbage-collection start prod-bkp

Pour simuler sans supprimer (dry-run dans une logique différente — PBS n'a pas de --dry-run sur GC, mais vous pouvez auditer via list-snapshots avant prune).

3.4 Comprendre prune et son interaction avec verify

Le prune supprime les snapshots selon une rétention configurée (keep-daily, keep-weekly, keep-monthly, keep-yearly). Il marque seulement les snapshots comme protégés ou à supprimer ; le GC ultérieur libère réellement l'espace. Conséquence pour verify : un snapshot pruné mais non encore garbage-collected reste vérifiable. Il est même recommandé de verifier avant le GC pour s'assurer qu'aucun chunk encore référencé n'est défaillant — une corruption détectée tard peut imposer la conservation d'un snapshot censé être supprimé.

3.5 API REST de status

Pour intégration externe, l'endpoint GET /api2/json/status/datastore-usage retourne le status JSON natif :

curl -k -s -H "Authorization: PBSAPIToken=root@pam!monitor:TOKEN" \
  https://pbs.example.com:8007/api2/json/status/datastore-usage \
  | jq '.data[]'

Privilégiez les API tokens aux mots de passe pour l'automation. Créez un token dédié monitor avec rôle DatastoreAudit en lecture seule.

4. Planification automatique des vérifications

Toute vérification manuelle finit par être oubliée. La planification est non négociable.

4.1 Verify Jobs via la GUI PBS

Dans l'interface web PBS, naviguez vers Datastore → [nom] → Verify Jobs → Add. Les paramètres clés :

• Schedule : syntaxe systemd-timer (ex: sat 02:00, *-*-* 03:00).
• Ignore verified : true (recommandé).
• Outdated After : 30 jours.
• Worker Threads : 4 par défaut, ajustable selon CPU disponible.

4.2 Cron Linux pour orchestration externe

Si vous orchestrez depuis un serveur central (Ansible, Rundeck), un cron classique fonctionne :

# /etc/cron.d/pbs-verify
0 2 * * 6 root /usr/sbin/proxmox-backup-manager datastore verify prod-bkp \
  --ignore-verified true --outdated-after 30 \
  --output-format json >> /var/log/pbs-verify.log 2>&1

Veillez à ce que le serveur PBS dispose d'une horloge précise — voir notre guide NTP Proxmox. Une dérive temporelle perturbe les schedules systemd et fausse les estimations de fenêtre maintenance.

4.3 Calendrier recommandé

Pour un datastore de production de taille moyenne (10-50 TiB) :

• Lundi 03:00 : GC complet
• Mardi à vendredi 02:00 : prune des jobs quotidiens
• Samedi 02:00 : verify incrémental (--outdated-after 30)
• 1er dimanche du mois 01:00 : verify exhaustif (sans --ignore-verified)

4.4 Notifications natives PBS

PBS 3.x intègre un système de notifications par matcher (depuis PBS 3.2). Configurez un matcher verify-failed dans Configuration → Notifications qui route vers SMTP, Gotify, ou un webhook. Exemple de matcher routant les échecs vers PagerDuty :

# /etc/proxmox-backup/notifications.cfg
matcher: pagerduty-critical
        match-field exact:type=verify
        match-severity error
        target pagerduty

Avant PBS 3.2, utilisez les notifications email globales avec parsing du sujet. Migrez dès que possible vers le système matcher : il offre un routage granulaire par sévérité et type de tâche.

4.5 systemd timers vs cron

Les Verify Jobs PBS s'appuient sur systemd timers en interne. Avantages : journalisation native via journalctl, randomisation du démarrage (RandomizedDelaySec) pour éviter les pics simultanés sur plusieurs serveurs, et reprise automatique après reboot. Si vous gérez plusieurs PBS, harmonisez les schedules via Ansible plutôt que de configurer chaque GUI manuellement.

5. Gestion des erreurs et de la corruption

Une vérification qui échoue n'est pas une catastrophe — c'est précisément la raison d'être de l'outil. Voici la procédure de remédiation.

5.1 Identifier les chunks corrompus

Lorsque verify détecte une erreur, le log indique le hash du chunk défaillant :

verify group vm/101 (3 snapshots)
verify vm/101/2026-04-15T22:00:00Z
ERROR: chunk 9f3e2a1b...c4d corrupted

Le snapshot est marqué verify failed dans verification.log. Les autres snapshots partageant ce chunk sont également impactés (architecture déduplication).

5.2 Manifest mismatch

Une erreur manifest mismatch indique que le fichier index.json ne référence plus correctement les chunks. Causes fréquentes : interruption brutale d'une sauvegarde, FS corrompu (ext4 sans journal), bug PBS pré-3.0. La récupération impose souvent de supprimer le snapshot corrompu et de relancer une sauvegarde complète depuis le PVE source.

5.3 GC dry-run et reconstruction

PBS ne propose pas de --dry-run natif sur GC, mais vous pouvez analyser verification.log et gc.log avant toute action destructive. Si la corruption est massive, envisagez une restauration depuis un datastore secondaire (réplication PBS-to-PBS via sync jobs). C'est précisément l'objectif d'une architecture 3-2-1 décrite dans notre livre blanc Proxmox VE 9.

5.4 Procédure de remédiation détaillée

Lorsque verify détecte une corruption, suivez cette procédure éprouvée :

1. Isoler le problème : identifier les snapshots failed via proxmox-backup-manager task log. Ne pas paniquer ni supprimer aveuglément.
2. Audit hardware : smartctl -a /dev/sdX sur chaque disque du pool, zpool status -v backup-pool pour ZFS. Documenter l'état avant action.
3. Audit filesystem : si ext4/XFS, fsck -n en lecture seule pendant que le datastore est en lecture seule (maintenance-mode read-only dans datastore.cfg).
4. Croiser avec sync replica : si vous disposez d'un PBS secondaire synchronisé, lancer un verify sur la cible pour comparer. Si la cible est saine, vous pouvez restaurer depuis elle.
5. Décision : si snapshot failed mais autres OK pour la même VM, supprimer le failed (proxmox-backup-manager snapshot forget). Si tous les snapshots de la VM sont failed, relancer une sauvegarde complète depuis PVE.
6. Post-mortem : documenter dans le ticket. Ajuster la fréquence de verify à la hausse temporairement.

5.5 Maintenance mode pour interventions

Avant toute opération risquée (réparation FS, remplacement disque), activez le maintenance mode du datastore :

proxmox-backup-manager datastore update prod-bkp \
  --maintenance-mode read-only

Trois modes existent : read-only, offline, delete. read-only bloque les nouveaux backups mais autorise restaurations et verify. offline bloque tout. Toujours laisser read-only pendant les diagnostics — n'utilisez offline que pour les opérations destructives.

6. Performance et impact production

Verify est intensif en lecture séquentielle sur le datastore. Sur un pool ZFS RAIDZ2 de 12 disques 7200 rpm, attendez-vous à 600-900 Mo/s en pic, saturant l'I/O. Un datastore de 20 TiB se vérifie en 6 à 10 heures.

6.1 Multi-threading

Depuis PBS 2.4, le paramètre verify_threads dans datastore.cfg contrôle le parallélisme. Valeur par défaut : 4. Au-delà de 8, les gains sont marginaux et l'IOPS sature avant le CPU. Adaptez selon votre stockage : NVMe peut supporter 16+, HDD plafonne à 4-6.

6.2 Impact sur les sauvegardes en cours

Si verify s'exécute pendant une fenêtre de backup, les nouvelles sauvegardes ralentissent significativement (latence × 2 à 4). Solution : planifier verify hors fenêtre de backup, ou utiliser ionice -c2 -n7 pour réduire la priorité I/O :

ionice -c2 -n7 proxmox-backup-manager datastore verify prod-bkp \
  --ignore-verified true --outdated-after 30

6.3 Cas spécifique du stockage objet

PBS 3.x supporte les datastores S3-compatibles (MinIO, Ceph RGW). La latence par chunk étant 10× supérieure à un disque local, verify sur stockage objet peut prendre 30+ heures pour 10 TiB. Privilégiez alors un cache SSD local pour les hot chunks.

6.4 Benchmark de référence

Voici des chiffres mesurés sur trois architectures de référence (datastore 10 TiB, ratio dédup 4×) :

Architecture	Throughput verify	Durée 10 TiB	Threads optimaux
HDD 7200 rpm RAIDZ2 ×8	700 Mo/s	4h10	4
SSD SATA RAID10 ×8	2.1 Go/s	1h20	6
NVMe Gen4 mirror ×4	5.8 Go/s	30 min	12
S3 (MinIO 1Gbps)	110 Mo/s	26h	2

Ces chiffres servent de baseline : si votre throughput observé est très inférieur, suspectez un goulot CPU (vieux Xeon, AES-NI désactivé), une saturation réseau (PBS distant), ou une fragmentation FS (ext4 sans tune2fs -O extent).

6.5 Optimisation de la verify task queue

PBS sérialise par défaut les verify tasks sur un même datastore. Pour paralléliser sur plusieurs datastores indépendants, lancez les commandes en arrière-plan via systemd :

systemd-run --unit=verify-prod \
  proxmox-backup-manager datastore verify prod-bkp
systemd-run --unit=verify-archive \
  proxmox-backup-manager datastore verify archive-bkp

Surveillez l'I/O global via iostat -xz 5 : si %util sature à 100% sur les disques sous-jacents, vous êtes I/O bound, inutile d'ajouter du parallélisme.

7. Intégration au monitoring

Une vérification silencieuse est une vérification inutile. L'intégration au monitoring est obligatoire en production.

7.1 pbs-exporter (Prometheus)

Le projet open-source pbs-exporter expose les métriques PBS au format Prometheus :

• pbs_datastore_used_bytes
• pbs_datastore_total_bytes
• pbs_verify_failed_total
• pbs_last_verify_timestamp
• pbs_gc_duration_seconds

7.2 Tableau de bord Grafana

Un dashboard type comprend : jauge utilisation datastore, courbe ratio déduplication, table des dernières vérifications par snapshot, alertes pbs_verify_failed_total > 0. La guide de durcissement Proxmox VE 9 détaille l'isolation réseau du subnet monitoring.

7.3 Alertes Slack et email

Via Alertmanager, configurez un receiver Slack avec routing par sévérité. Exemple de règle :

- alert: PBSVerifyFailed
  expr: increase(pbs_verify_failed_total[24h]) > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Verify failure on {{ $labels.datastore }}"

- alert: PBSDatastoreFull
  expr: pbs_datastore_used_bytes / pbs_datastore_total_bytes > 0.85
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "Datastore {{ $labels.datastore }} above 85% usage"

- alert: PBSVerifyStale
  expr: time() - pbs_last_verify_timestamp > 1209600
  for: 1h
  labels:
    severity: warning
  annotations:
    summary: "No verify in last 14 days on {{ $labels.datastore }}"

7.4 Logs structurés et SIEM

Configurez rsyslog pour exporter /var/log/proxmox-backup/tasks/ vers votre SIEM (Splunk, ELK, Wazuh). Le format des tâches PBS suit un pattern strict :

UPID:pbs01:00012A4B:00CD9F3E:6850A8E1:verify:prod-bkp:root@pam:

Décomposable en : nœud, PID, task counter, timestamp epoch, type, datastore, user. Un parser SIEM dédié extrait ces champs pour reporting compliance.

7.5 Health check externe (Healthchecks.io, Uptime Kuma)

Pour un dead-man switch indépendant de votre stack monitoring interne, encadrez votre script verify d'un ping :

curl -fsS -m 10 https://hc-ping.com/UUID/start
proxmox-backup-manager datastore verify prod-bkp
RC=$?
curl -fsS -m 10 https://hc-ping.com/UUID/$RC

Si le verify ne s'exécute pas (cron en panne, disque saturé), Healthchecks alerte après le délai grâce. Solution low-tech mais redoutablement efficace pour les TPE/PME sans Prometheus.

8. Chiffrement et gestion des clés

PBS supporte le chiffrement client-side AES-256-GCM. Verify fonctionne sur les chunks chiffrés sans déchiffrement (il vérifie le SHA-256 des données chiffrées telles que stockées). Cela signifie que la perte de la clé n'empêche pas verify, mais empêche toute restauration.

8.1 Backup de la clé maître

La clé est stockée par défaut dans /etc/proxmox-backup/master-key.bin (côté serveur si configuré) ou en ~/.config/proxmox-backup/encryption-key.json côté client. Sauvegardez-la hors du datastore — sinon, en cas de désastre, vous restaurez des données illisibles.

8.2 Rotation des clés

PBS ne supporte pas la rotation transparente : changer la clé impose de relancer une sauvegarde complète. Planifiez une rotation annuelle, en gardant l'ancienne clé archivée tant que les snapshots associés ne sont pas prunés.

8.3 Master Key vs encryption-key par client

Deux modèles de chiffrement coexistent dans PBS :

• Encryption-key par client : chaque PVE possède sa propre clé. Compromission limitée mais gestion complexe à grande échelle.
• Master Key (RSA) : la clé symétrique de chaque sauvegarde est chiffrée par la clé publique du master. Le détenteur de la clé privée RSA peut tout déchiffrer en cas d'urgence (BCP/DRP).

Pour des environnements multi-tenants ou multi-sites, privilégiez le master key avec stockage HSM ou coffre-fort logique (HashiCorp Vault, AWS KMS) pour la clé privée.

8.4 Verify et chiffrement

Verify ne déchiffre jamais les chunks — il valide le SHA-256 sur les données chiffrées telles que stockées. Conséquence : verify peut détecter une corruption physique mais ne peut pas détecter une altération sémantique du clair. Si un attaquant possède la clé et modifie le clair puis re-chiffre, le SHA-256 du chiffré change et verify détecte. Si l'attaquant ne possède pas la clé mais altère le chiffré, verify détecte aussi. Le seul scénario indétectable : un attaquant possédant la clé, qui modifie le clair, re-chiffre, ET met à jour le manifest. C'est pourquoi le chiffrement client-side avec clé privée hors PBS est essentiel.

9. Bonnes pratiques opérationnelles

Synthèse des règles éprouvées sur des centaines de déploiements PBS.

9.1 Fréquence recommandée

• Verify incrémental : hebdomadaire (samedi nuit).
• Verify exhaustif : mensuel (1er dimanche).
• Status check : quotidien automatisé via Prometheus.
• GC : hebdomadaire (lundi nuit), avant le verify.

9.2 Ratio chunks/RAM

PBS charge en RAM les index des chunks pendant verify. Comptez environ 1 Go de RAM par 10 millions de chunks. Un datastore de 50 TiB déduplikué ratio 4× contient ~12 millions de chunks → ~1.5 Go RAM minimum, prévoir 4 Go pour confort.

9.3 Fenêtres de maintenance

Communiquez les fenêtres aux équipes applicatives. Verify lui-même ne perturbe pas les VMs (il s'exécute sur PBS, pas PVE), mais s'il sature l'I/O du datastore, les nouvelles sauvegardes échouent par timeout.

9.4 Stratégie multi-datastore

Séparez datastores chauds (sauvegardes < 30 jours) et froids (archives > 90 jours). Verify le froid mensuellement, le chaud hebdomadairement. Voir notre guide complet Proxmox VE pour l'architecture détaillée.

9.5 Tuning ZFS pour datastore PBS

Si vous hébergez le datastore sur ZFS, certains paramètres améliorent significativement les performances de verify :

# Recordsize aligné au chunk PBS (4 Mo)
zfs set recordsize=4M backup-pool/datastore

# Compression LZ4 active (rapide, économique)
zfs set compression=lz4 backup-pool/datastore

# atime désactivé (chunks lus en lecture seule)
zfs set atime=off backup-pool/datastore

# xattr=sa pour réduire les I/O metadata
zfs set xattr=sa backup-pool/datastore

# ARC max : 50% RAM hôte (ajuster selon usage)
echo "options zfs zfs_arc_max=17179869184" \
  > /etc/modprobe.d/zfs.conf

Le recordsize 4 Mo aligne parfaitement avec les chunks PBS, éliminant le read amplification. Sur HDD, ces tunings doublent souvent le throughput de verify.

9.6 Réplication PBS-to-PBS (sync jobs)

Configurez systématiquement un PBS secondaire en réplication asynchrone. Sync job hebdomadaire :

proxmox-backup-manager sync-job create sync-to-dr \
  --remote pbs-dr \
  --remote-store dr-bkp \
  --store prod-bkp \
  --schedule "sun 04:00"

Verifyez les deux datastores indépendamment. Si verify échoue côté primaire mais réussit côté DR, vous avez la garantie d'une copie saine récupérable. Cette architecture est la pierre angulaire de la stratégie 3-2-1.

10. Automation avec Ansible

Pour les flottes de PBS, l'automation Ansible est incontournable. Voici un playbook minimaliste :

---
- name: PBS verify automation
  hosts: pbs_servers
  tasks:
    - name: Run verify on all datastores
      command: >
        proxmox-backup-manager datastore verify {{ item }}
        --ignore-verified true --outdated-after 30
        --output-format json
      register: verify_result
      loop: "{{ pbs_datastores }}"

    - name: Parse JSON output
      set_fact:
        failed_snapshots: >-
          {{ verify_result.results | map(attribute='stdout')
          | map('from_json') | flatten
          | selectattr('state', 'equalto', 'failed') | list }}

    - name: Alert on failures
      mail:
        to: ops@example.com
        subject: "PBS verify failed: {{ inventory_hostname }}"
        body: "{{ failed_snapshots | to_nice_json }}"
      when: failed_snapshots | length > 0

Inventory groupé par site géographique, variables pbs_datastores par hôte. Lancez le playbook via Tower/AWX pour traçabilité complète.

10.1 Module communautaire pbs-cli

Le module Ansible communautaire community.general.proxmox_backup_info simplifie la collecte de métriques. Combinez-le avec un appel command pour les actions, le module pour la lecture. Cette approche hybride limite les permissions API aux strictes nécessités.

11. Cas pratiques : trois scénarios réels

11.1 Scénario 1 : Disque défaillant détecté par S.M.A.R.T.

Un HDD du pool ZFS retourne Reallocated_Sector_Ct croissant. Procédure :

1. Lancer zpool scrub backup-pool pour forcer la réécriture des secteurs.
2. Une fois scrub terminé, exécuter proxmox-backup-manager datastore verify prod-bkp sans --ignore-verified.
3. Si verify remonte des erreurs persistantes, remplacer le disque (zpool replace) et relancer scrub puis verify.
4. Documenter dans un ticket post-mortem.

11.2 Scénario 2 : Après upgrade PBS 2.x → 3.x

Les upgrades majeurs peuvent introduire des changements de format de manifest. Bonne pratique :

1. Snapshot ZFS du dataset PBS avant upgrade.
2. Procéder à l'upgrade selon la doc officielle pbs.proxmox.com.
3. Lancer un verify exhaustif sans aucun filtre dans les 24h post-upgrade.
4. Si erreurs > 1% des snapshots, rollback ZFS snapshot.

11.3 Scénario 3 : Migration de datastore

Migration d'un datastore vers un nouveau stockage (NVMe RAID10 par exemple) :

1. Configurer un sync job PBS-to-PBS du datastore source vers la nouvelle cible.
2. Attendre la convergence (peut prendre plusieurs jours).
3. Lancer un verify exhaustif sur la cible.
4. Comparer les outputs JSON : diff <(verify source --output-format json) <(verify target --output-format json).
5. Basculer les jobs de backup PVE vers la nouvelle cible.
6. Conserver l'ancien datastore en lecture seule pendant 30 jours minimum.

12. Verify et conformité réglementaire

Pour les organisations soumises à RGPD, NIS2, DORA ou ISO 27001, la preuve d'intégrité des sauvegardes est exigible lors d'audit. Conservez les logs verify (verification.log) au moins 12 mois et exportez-les périodiquement vers un SIEM. Le timestamp signé du dernier verify réussi par snapshot constitue une preuve technique opposable.

12.1 Logs et traçabilité

Les logs PBS sont dans /var/log/proxmox-backup/tasks/. Activez la rotation logrotate avec rétention 13 mois pour conformité. Pour les environnements multi-tenants, utilisez les ACLs PBS pour restreindre l'accès aux logs par datastore.

13. Limites connues et pièges courants

13.1 Verify n'est pas une restauration test

Verify confirme l'intégrité cryptographique mais ne garantit pas la restaurabilité applicative (cohérence base de données, consistance LVM, etc.). Complétez par des restaurations test mensuelles vers un environnement isolé.

13.2 Concurrence verify + GC

PBS sérialise GC et verify sur un même datastore. Si vous lancez les deux simultanément, le second attend. Planifiez en séquence : GC puis verify avec 30 minutes de marge.

13.3 Limitation API

L'API REST POST /api2/json/admin/datastore/{store}/verify retourne un upid (worker task ID) qu'il faut interroger via GET /api2/json/nodes/{node}/tasks/{upid}/status. Exemple curl complet dans la doc API Viewer Proxmox.

14. FAQ

Comment programmer un verify automatique sur Proxmox Backup Server ?

Deux approches : la GUI PBS (Datastore → Verify Jobs → Add) avec un schedule systemd-timer (ex. sat 02:00), ou un cron Linux invoquant proxmox-backup-manager datastore verify --ignore-verified true --outdated-after 30. La GUI offre traçabilité et notifications natives ; cron permet l'orchestration externe via Ansible ou Rundeck.

Combien de temps prend un verify complet ?

Le verify est I/O bound. Comptez environ 1 To par heure sur HDD 7200 rpm en RAIDZ2, 3 To/h sur SSD SATA, et 8-10 To/h sur NVMe. Un datastore de 20 TiB sur HDD nécessite 6 à 10 heures. Utilisez --outdated-after pour réduire à un sous-ensemble (typiquement 80% de réduction).

Que faire si verify échoue sur plusieurs snapshots ?

Identifier le pattern : un seul chunk impacte plusieurs snapshots (déduplication). Localiser le chunk corrompu via verification.log, vérifier l'état du disque physique (smartctl -a), lancer un zpool scrub si ZFS. Si la corruption persiste, supprimer les snapshots failed, relancer une sauvegarde complète depuis PVE, et envisager une restauration depuis un datastore secondaire (sync replica).

Quelle différence entre datastore verify et datastore status ?

Verify audite l'intégrité cryptographique (SHA-256 des chunks vs manifest) — opération longue, lecture intégrale. Status expose l'état capacitaire (espace, déduplication, dates derniers GC/verify) — opération instantanée. Les deux sont complémentaires : status pour le monitoring quotidien, verify pour l'audit hebdomadaire.

Quel est le coût en performance d'un verify ?

Verify sature l'I/O du datastore (60-90% du throughput disque). Sur un PBS dédié, l'impact se limite aux nouvelles sauvegardes simultanées qui ralentissent (latence ×2 à ×4). Aucun impact sur les VMs/CTs côté PVE puisque verify s'exécute exclusivement sur le serveur PBS. Utilisez ionice -c2 -n7 pour atténuer.

Faut-il faire un GC avant chaque verify ?

Pas obligatoire mais recommandé hebdomadairement. Le GC supprime les chunks orphelins, réduisant la surface de verify. Séquence type : lundi GC, samedi verify. Évitez d'exécuter GC et verify simultanément (PBS les sérialise, l'un attend l'autre). Pour les architectures critiques, voir notre guide 3-2-1 immutable.

15. Ressources et documentation officielle

Pour approfondir, consultez la documentation officielle Proxmox Backup Server, en particulier les chapitres Maintenance Tasks et Managing Remotes. Le code source est disponible sur le git Proxmox pour les contributeurs avancés.

16. Glossaire technique

Chunk

Bloc de données de taille fixe (4 Mo par défaut dans PBS) résultant de la déduplication. Identifié par son hash SHA-256.

Manifest (index.json.blob)

Fichier JSON listant les chunks composant un snapshot, avec leur hash et leur ordre. Critique pour la restauration.

Datastore

Volume de stockage PBS organisé selon une structure spécifique (.chunks, vm/, ct/, host/). Peut être local ou distant (S3).

Snapshot

Une sauvegarde individuelle horodatée d'une VM, container ou hôte. Représente un état figé.

Verify Job

Tâche planifiée PBS exécutant une vérification d'intégrité selon un schedule systemd-timer.

Garbage Collection (GC)

Processus de libération d'espace supprimant les chunks orphelins (non référencés par aucun manifest).

Sync Job

Tâche de réplication asynchrone d'un datastore vers un PBS distant. Base d'une stratégie 3-2-1.

Bit rot

Corruption silencieuse de données sur stockage longue durée, sans signalement par le firmware. Détectable uniquement par checksum applicatif.

UPID (Unique Process ID)

Identifiant unique d'une tâche PBS, format UPID:node:pid:counter:epoch:type:store:user:.

17. Conclusion

La vérification d'un datastore PBS n'est pas une coquetterie d'administrateur paranoïaque : c'est le seul moyen de garantir que vos sauvegardes sont effectivement restaurables le jour J. La combinaison datastore verify + datastore status, planifiée via Verify Jobs ou cron, intégrée au monitoring Prometheus/Grafana, et complétée par des restaurations test trimestrielles, constitue le socle d'une stratégie de continuité d'activité crédible. Investissez maintenant dans cette discipline : le coût d'une vérification hebdomadaire est dérisoire face au coût d'une restauration impossible. Pour aller plus loin sur l'écosystème Proxmox dans son ensemble, parcourez notre guide complet Proxmox VE et notre guide pratique d'optimisation.