Configuration, rétention et vérification
L'onglet Configuration centralise les réglages qui garantissent la durabilité, la propreté et l'intégrité de votre datastore PBS.
Namespaces
Les namespaces permettent de segmenter logiquement les sauvegardes à l'intérieur d'un même datastore. Ils sont stockés comme une structure de répertoires imbriqués, sans configuration supplémentaire.
Cas d'usage
- Séparer plusieurs clusters Proxmox VE partageant le même datastore (VMIDs qui se chevauchent)
- Isoler les environnements :
prod,preprod,dev - Cloisonner par client ou par projet dans un contexte hébergeur
Structure imbriquée
Les namespaces sont hiérarchiques et s'expriment avec la notation slash :
/
├── prod/
│ ├── vm-infra/
│ └── vm-clients/
├── preprod/
└── client-a/
Création
Depuis l'onglet Configuration → Namespaces :
- Renseignez le Nom du namespace (ex.
prod) - Sélectionnez le Parent (
/pour racine, ou un namespace existant) - Cliquez sur +
Si vous sauvegardez plusieurs clusters Proxmox VE avec des VMIDs identiques, utilisez un namespace par cluster pour éviter les conflits de nommage dans le datastore.
Job Prune (rétention)
Le prune supprime les snapshots anciens selon votre politique de rétention. Il supprime uniquement les métadonnées (manifest, index, logs) — les chunks réels ne sont libérés que par le Garbage Collection.
Options de rétention disponibles
| Option | Comportement |
|---|---|
keep-last N | Conserve les N derniers snapshots, quelle que soit la date |
keep-hourly N | Conserve le snapshot le plus récent pour chacune des N dernières heures |
keep-daily N | Conserve le snapshot le plus récent pour chacun des N derniers jours |
keep-weekly N | Conserve le snapshot le plus récent pour chacune des N dernières semaines |
keep-monthly N | Conserve le snapshot le plus récent pour chacun des N derniers mois |
keep-yearly N | Conserve le snapshot le plus récent pour chacune des N dernières années |
Les semaines commencent le lundi et se terminent le dimanche (norme ISO 8601).
Exemple de politique : sauvegarde quotidienne, 10 ans de rétention
Voici l'exemple de la documentation officielle PBS pour une rétention longue durée sur des backups quotidiens :
| Option | Valeur | Raison |
|---|---|---|
keep-last | 3 | Conserve les backups manuels récents avant/après intervention |
keep-daily | 13 | Garantit au moins 2 semaines (en complément de keep-last) |
keep-weekly | 8 | Garantit au moins 2 mois complets |
keep-monthly | 11 | Garantit une année de points mensuels |
keep-yearly | 9 | Archive longue durée — 9 ans supplémentaires |
Exemple minimal : usage courant
keep-last: 3
keep-daily: 5
keep-weekly: 3
keep-monthly: 1
Testez votre politique avec le simulateur de prune PBS avant de l'appliquer.
Portée du prune
Un prune job peut être limité à :
- un datastore entier
- un namespace spécifique (
ns) - une profondeur de namespace (
max-depth)
Garbage Collection (GC)
Le Garbage Collection libère l'espace disque réel en supprimant les chunks orphelins — c'est-à-dire les blocs qui ne sont plus référencés par aucun snapshot.
Différence prune / GC
| Opération | Ce qu'elle supprime |
|---|---|
| Prune | Métadonnées des snapshots (manifest, index) |
| GC | Chunks physiques devenus orphelins après le prune |
Le prune seul ne libère aucun espace disque. Le GC est indispensable.
Comment fonctionne le GC (mécanisme interne)
Le GC s'exécute en deux phases :
- Phase Mark : PBS lit tous les index du datastore et met à jour l'horodatage d'accès (
atime) de chaque chunk référencé - Phase Sweep : PBS parcourt tous les chunks et supprime ceux dont l'
atimeest plus ancien que le seuil de grâce
Période de grâce : 24h05
PBS attend 24 heures et 5 minutes avant de supprimer un chunk orphelin. Cette durée est liée à l'option relatime des systèmes de fichiers Linux (l'atime n'est mis à jour que si le fichier n'a pas été accédé depuis plus de 24h). Ce délai évite de supprimer des chunks encore en cours d'écriture par un job de backup actif.
Exécutez toujours le prune avant le GC. Le GC doit s'exécuter après que le prune a supprimé les métadonnées, pour identifier correctement les chunks devenus orphelins.
Planification recommandée
| Fréquence | Cas d'usage |
|---|---|
| Quotidien | Environnements avec beaucoup de suppressions ou de snapshots |
| Hebdomadaire | Cas standard — bon compromis |
| Manuel | Après suppression massive de snapshots |
Jobs de vérification
Les jobs de vérification contrôlent l'intégrité des sauvegardes en vérifiant les checksums de chaque chunk.
Pourquoi vérifier ?
Les disques physiques se dégradent avec le temps — un phénomène connu sous le nom de bit rot (dégradation silencieuse des données). Un backup en apparence intact peut être corrompu sans aucun signal visible.
Configuration d'un job de vérification
Depuis Configuration → Jobs de vérification → Ajouter un job de vérification :
| Paramètre | Recommandation |
|---|---|
| Fréquence | Hebdomadaire (nouveaux snapshots) + Mensuelle (tout re-vérifier) |
| Namespace | Cibler un namespace spécifique ou tout le datastore |
| Ignorer déjà vérifiés | Non pour le job mensuel complet |
| Threads | 1 reader, 4 verify threads (défaut PBS) |
Stratégie de double job (recommandée)
- Job quotidien ou hebdomadaire : vérifie uniquement les snapshots récents non encore vérifiés
- Job mensuel : re-vérifie l'intégralité des snapshots (détecte le bit rot sur les anciens backups)
La vérification confirme l'intégrité des chunks stockés mais ne garantit pas qu'une VM démarrera correctement après restauration. Complétez toujours avec des tests de restauration réels.
Stratégie globale recommandée
| Tâche | Fréquence | Heure |
|---|---|---|
| Job de sauvegarde | Quotidien | 02h00 |
| Prune | Quotidien | 03h00 (après backup) |
| Garbage Collection | Quotidien | 04h00 (après prune, au moins 1h plus tard) |
| Vérification (récents) | Hebdomadaire | Samedi 05h00 |
| Vérification (complète) | Mensuelle | 1er du mois 05h00 |