Verify jobs dans Proxmox Backup Server : ce qu'ils vérifient, ce qu'ils ne prouvent pas

1. Ce que verify relit

Pour chaque snapshot à vérifier, PBS reprend la liste de ses fichiers et contrôle chacun d'eux (src/backup/verify.rs) :

• Les petits fichiers (blobs : configuration de la VM, journal du client) : taille et somme de contrôle.
• Les index (.fidx pour un disque, .didx pour une archive de fichiers) : taille et somme de contrôle de l'index lui-même.
• Chaque bloc référencé par l'index : le bloc est lu sur le disque. S'il est en clair, PBS le décompresse, recalcule son empreinte SHA-256 et la compare à son nom, puis contrôle sa taille. S'il est chiffré, le serveur n'a pas la clé : il ne contrôle que la somme CRC-32 du bloc stocké.

Au sein d'une même tâche, un bloc partagé par plusieurs snapshots n'est lu qu'une fois. Le résultat (ok ou failed, avec la date et l'identifiant de la tâche) est enregistré avec le snapshot ; c'est lui qu'affiche la colonne Verify State de l'onglet Content, qui signale aussi comme outdated une vérification de plus de 30 jours.

Quand un bloc est mauvais

Un bloc illisible, absent ou dont l'empreinte ne correspond pas est compté en erreur. S'il existe sur le disque, il est renommé en <empreinte>.0.bad : il n'est plus considéré comme présent. Le snapshot passe en failed. La suite est utile à connaître (src/api2/backup/mod.rs) :

• si le dernier snapshot d'une machine (VM, conteneur ou hôte) est en failed, la sauvegarde suivante ne s'appuie pas sur lui : le client renvoie tous les blocs, et ceux qui manquaient sur le serveur, dont le bloc écarté, sont réécrits ;
• les anciens snapshots qui référençaient ce bloc restent marqués failed jusqu'à leur prochaine vérification. Avec Skip Verified, elle n'aura lieu qu'après le délai de Re-Verify After : relancez-la à la main, une fois la sauvegarde suivante terminée, avec l'icône V. sur la ligne du snapshot dans l'onglet Content (sur un snapshot seul, elle revérifie toujours ; sur un groupe, elle saute les vérifications de moins de 29 jours).

2. Le coût : des lectures, beaucoup

Vérifier un snapshot, c'est relire tous ses blocs, pas seulement ceux qu'il a ajoutés. La déduplication économise de la place, pas de la lecture : un bloc vérifié la veille, dans une autre tâche, est relu aujourd'hui s'il appartient au nouveau snapshot.

Exemple : une VM dont le disque contient 400 Go de données, sauvegardée chaque nuit. Le verify job de la nuit relit les quelque 400 Go de blocs du nouveau snapshot, même si la sauvegarde n'en a envoyé que 3 Go. Le verify lit beaucoup plus que la sauvegarde n'écrit ; c'est souvent la tâche la plus longue d'un PBS.

• Parallélisme : les options read-threads (1 par défaut) et verify-threads (4 par défaut), de 1 à 32, règlent le nombre de lecteurs et de vérificateurs (doc). Sur des disques mécaniques, augmenter les lecteurs aide jusqu'à saturer les disques, pas au-delà.
• Special device ZFS : la documentation le recommande avec des disques mécaniques (System Requirements). Il accélère surtout ce qui touche aux métadonnées : parcours du répertoire .chunks/, marquage du garbage collection. Le verify, lui, lit le contenu des blocs, qui reste sur les disques de données ; il en profite beaucoup moins.

3. Skip Verified et Re-Verify After

Deux options décident des snapshots qu'un job examine (ignore-verified et outdated-after en ligne de commande) :

Le piège est dans la dernière ligne. L'interface propose 30 jours par défaut, mais en ligne de commande, outdated-after n'a pas de valeur par défaut : un job créé sans cette option ne revérifie jamais. Le calcul se fait en jours entiers, et un snapshot est revérifié quand sa dernière vérification a strictement plus de 30 jours. Attention aussi : le résultat compte peu. Un snapshot en failed est traité comme déjà vérifié et attend lui aussi le délai.

proxmox-backup-manager verify-job create verify-<datastore> --store <datastore> \
  --schedule daily --ignore-verified true --outdated-after 30

# vérification ponctuelle de tout le datastore, sans rien ignorer
proxmox-backup-manager verify <datastore> --ignore-verified false

La documentation suggère deux jobs : un fréquent pour les nouvelles sauvegardes, un hebdomadaire ou mensuel qui revérifie tout. Un job quotidien avec 30 jours de Re-Verify After obtient le même résultat en un seul job, et étale les relectures au lieu de les concentrer sur une nuit.

Vérifier dès la fin de la sauvegarde

L'option de datastore verify-new lance une vérification de chaque snapshot dès que la sauvegarde se termine (« all new backups will be verified right after completion »). Elle raccourcit le délai de détection, au prix d'une relecture complète juste après chaque écriture.

4. Verify et synchronisation

Une copie d'un PBS vers un autre (sync job) ne transporte pas l'état de vérification. Le code le dit en toutes lettres : il est retiré « to be reverified independent from the sync » (src/server/pull.rs). Un snapshot synchronisé arrive donc non vérifié, et c'est le verify job du PBS de destination qui le contrôlera, sur ses propres disques.

• verified-only : ne copie que les snapshots dont la dernière vérification à la source est ok.
• resync-corrupt : si un snapshot local a échoué à la vérification, la synchronisation suivante le recopie depuis la source.

Les deux se complètent : on évite de recopier un snapshot déjà abîmé à la source, et on répare la copie locale à partir d'une source saine. Les deux côtés ont besoin de leur propre verify job.

5. Ce qu'un verify réussi ne prouve pas

• Que la VM démarre. Les blocs peuvent être intacts et le système invité inutilisable : sauvegarde d'un disque déjà corrompu, pilote manquant, configuration absente sur la nouvelle machine.
• Que les données applicatives sont cohérentes. Une base de données sauvegardée à chaud sans gel du système de fichiers (agent invité) est fidèlement stockée, et peut quand même nécessiter une récupération au démarrage.
• Que vous avez la clé. Pour une sauvegarde chiffrée, le serveur ne contrôle que la somme CRC-32 du bloc chiffré ; sans la clé, rien n'est restaurable. Voir la clé de chiffrement PBS.
• Le temps de restauration. Il dépend du débit réseau et des disques ; il se mesure en restaurant.

Seule une restauration testée répond à ces questions. Chez NimbusBackup, les tests de restauration se font dans le cadre de nos trois offres d'infogérance, pour les clients dont nous administrons le Proxmox VE, avec la clé que nous détenons déjà en tant qu'administrateur. Pour la sauvegarde seule, la clé n'est pas demandée : le test de restauration reste de votre côté.

6. Et le garbage collection ?

Le garbage collection est l'autre tâche planifiée d'un datastore. Il ne vérifie rien : il libère la place des blocs que plus aucun snapshot ne référence, avec un délai de grâce d'un peu plus de 24 h. Comme le verify, il parcourt tous les index, et les deux se partagent les disques. Le détail, et pourquoi l'espace ne revient pas tout de suite, est dans la section garbage collection de l'article sur la déduplication.

7. Nos réglages par défaut

Sur chaque datastore NimbusBackup, verify et garbage collection tournent avec les valeurs par défaut que propose l'interface de PBS : vérification quotidienne, Skip Verified, revérification après 30 jours, garbage collection quotidien. Ce sont les valeurs de PBS, et nous les gardons. Le tableau est sur notre page PBS managé.

Questions fréquentes