Architecture PBS : datastore, chunks, déduplication, namespaces¶

Day 0 · ConcevoirNiveau 1 · DécouvrirCoursRédigé · à valider en lab

Proxmox Backup Server (PBS) découpe chaque sauvegarde en blocs (chunks) identifiés par leur empreinte SHA-256 et ne stocke chaque bloc qu'une seule fois : toutes les sauvegardes sont des sauvegardes complètes, mais seule la donnée nouvelle consomme de l'espace. À la fin de cette page, vous savez lire l'arborescence d'un datastore, expliquer la déduplication et choisir entre plusieurs datastores et des namespaces.

Notions clés¶

Terme	Définition	Équivalent VMware / Veeam approximatif
Datastore	Répertoire déclaré dans PBS qui contient un chunk store et les sauvegardes. Unité de rétention, de GC et de droits.	Repository
Chunk	Bloc de données compressé (zstd), éventuellement chiffré, nommé par son empreinte SHA-256.	Bloc dédupliqué
Index	Liste ordonnée des chunks qui reconstituent une archive : `.fidx` (taille fixe, disques de VM) ou `.didx` (taille variable, fichiers `.pxar`).	Métadonnées de la chaîne
Snapshot de sauvegarde	Une sauvegarde à un instant : manifeste `index.json.blob`, index, journal. Exemple : `vm/101/2026-10-22T22:00:00Z`.	Point de restauration
Groupe	Toutes les sauvegardes d'une même source : `vm/101`, `ct/102`, `host/srv-fichiers`.	Job / chaîne
Namespace	Sous-dossier logique d'un datastore, imbriquable jusqu'à 8 niveaux (racine comprise). Les chunks restent partagés.	Dossier de repository

Ce qu'il y a sur le disque¶

/mnt/datastore/pbs01/
├── .chunks/              65 536 répertoires 0000 à ffff
│   ├── a342/a342e8…      un chunk = un fichier
│   └── …
├── .lock
├── vm/101/2026-10-22T22:00:00Z/
│   ├── index.json.blob
│   ├── drive-scsi0.img.fidx
│   └── qemu-server.conf.blob
└── ns/client-a/vm/…      namespaces

Les chunks sont rangés selon les 4 premiers caractères hexadécimaux de leur empreinte. Le système de fichiers doit accepter au moins 65 538 sous-répertoires par répertoire : ext4, XFS et ZFS conviennent, pas ext3. Le grand nombre de petits fichiers explique pourquoi PBS a besoin d'IOPS et pas seulement de capacité.

Comment fonctionne la déduplication¶

flowchart LR
    D["Disque VM 101<br/>(lu par QEMU)"] --> S["Découpe en blocs<br/>de 4 Mio"]
    S --> H["SHA-256<br/>de chaque bloc"]
    H --> Q{"Chunk déjà<br/>sur le PBS ?"}
    Q -- oui --> R["Simple référence<br/>dans l'index .fidx"]
    Q -- non --> U["Compression zstd<br/>(+ chiffrement)<br/>envoi au PBS"]
    U --> C[".chunks/"]
    R --> I["Index de la sauvegarde"]
    C --> I

Disques de VM : blocs de taille fixe, en général 4 Mio. Avec le dirty bitmap de QEMU, PVE sait quels blocs ont changé depuis la dernière sauvegarde vers ce PBS et ne lit que ceux-là (sauvegarde incrémentale rapide).
Conteneurs et hôtes physiques : archive .pxar découpée en blocs de taille variable par un rolling hash. Un fichier inséré au milieu ne décale pas tous les blocs suivants.
La déduplication est globale au datastore : deux VMs clonées depuis le même template partagent leurs blocs communs. Elle ne traverse pas deux datastores différents.
Avec le chiffrement côté client, l'empreinte dépend aussi de la clé : deux clients avec des clés différentes ne dédupliquent pas entre eux.

Datastores ou namespaces ?¶

Besoin	Choix recommandé	Pourquoi
Séparer prod et hors-prod sur le même PBS	Namespaces	Dédup partagée, rétention propre à chaque namespace via des prune jobs
Plusieurs clusters PVE avec des VMID identiques	Un namespace par cluster	Évite la collision `vm/101` d'un cluster sur l'autre
Rétention ou disques physiques très différents (SSD / HDD)	Datastores distincts	GC, verify et support physique séparés
Isoler deux entités qui ne doivent jamais voir les données de l'autre	Datastores distincts (ou PBS distincts)	Droits, chiffrement et blast radius séparés
Recevoir la copie de plusieurs clients chez le MSP	Un datastore par client sur le PBS MSP	Quota, suppression et réversibilité simples

Sur PVE, le namespace se choisit dans la définition du stockage PBS (champ Namespace). Un même datastore peut donc être déclaré deux fois sous deux identifiants, par exemple pbs-local (racine) et pbs-local-test (namespace test).

Architecture MSP type¶

flowchart LR
    subgraph Client["Site client"]
        PVE["Cluster PVE<br/>pve01-pve03"] -->|"vzdump, nuit"| PBSL["PBS local<br/>datastore pbs01<br/>(stockage pbs-local)"]
    end
    PBSL -->|"sync job<br/>push ou pull"| PBSM["PBS du MSP<br/>datastore dédié au client"]

Le PBS local sert les restaurations rapides (RB-12, RB-13) et porte la rétention courte.
Le PBS du MSP porte la copie hors site et une rétention plus longue, avec des droits que le client ne détient pas (voir Stratégie 3-2-1-1-0).

Recommandations MSP¶

Un datastore par support physique, un namespace par usage. Ne créez pas un datastore par VM.
Stockage du datastore : SSD entreprise, ou HDD avec special vdev ZFS en miroir pour les métadonnées. HDD seuls : GC et verify très lents.
Laissez PBS seul maître de son répertoire : aucun autre processus ne doit écrire ou supprimer dans .chunks.

Pièges vus en support

Supprimer « les vieux fichiers » dans .chunks pour gagner de la place : toutes les sauvegardes qui référencent ces blocs deviennent irrestaurables. L'espace se libère uniquement par prune puis garbage collection.
Datastore posé sur un partage NFS ou SMB lent : sauvegardes et GC qui durent des heures. Préférez des disques locaux.
Deux clusters PVE vers la racine du même datastore : la VM 101 de l'un écrase la chaîne de la VM 101 de l'autre. Utilisez des namespaces.
Monter le datastore avec noatime : la garbage collection s'appuie sur l'atime des chunks. Gardez relatime (défaut).

Testez-vous¶

Une VM de 500 Go est sauvegardée chaque nuit, 2 % de ses blocs changent par jour. Combien d'espace consomme environ une sauvegarde quotidienne ?

Réponse

Environ 10 Go avant compression (les blocs modifiés), pas 500 Go. Chaque sauvegarde reste « complète » du point de vue de la restauration, car son index référence tous les chunks nécessaires.
Pourquoi PBS a-t-il besoin d'IOPS plus que de débit séquentiel ?

Réponse

Le datastore contient des millions de petits fichiers (chunks de quelques Mo au plus). Sauvegarde, verify et surtout garbage collection lisent ou touchent chacun d'eux.
Deux clusters ont chacun une VM 101. Comment les sauvegarder sur le même datastore sans collision ?

Réponse

Un namespace par cluster, renseigné dans le champ Namespace du stockage PBS de chaque cluster. Les chunks restent dédupliqués entre les deux.
Deux datastores sur le même PBS dédupliquent-ils entre eux ?

Réponse

Non. Chaque datastore a son propre .chunks. Seuls les namespaces d'un même datastore partagent la déduplication.