Dimensionner un PBS : capacité, IOPS, CPU, réseau¶
Un PBS bien dimensionné tient la rétention prévue pendant 3 ans avec 20 % de marge, termine la sauvegarde dans la fenêtre de nuit, et finit garbage collection et verify avant la sauvegarde suivante. Le facteur limitant n'est presque jamais le CPU : ce sont les IOPS du datastore et le lien vers le MSP. Faites le calcul avec le calculateur PBS, puis validez les hypothèses ci-dessous.
Les quatre dimensions¶
| Dimension | Ce qui la consomme | Ordre de grandeur de départ |
|---|---|---|
| Capacité | Données uniques après déduplication et compression, rétention, croissance | Volume occupé dans les VMs × 1,2 à 2 selon la rétention, avant marge |
| IOPS | Écriture de chunks, GC (touche chaque chunk référencé), verify (relit tout), restauration | SSD entreprise ; HDD uniquement avec special vdev SSD en miroir |
| CPU | Verify (SHA-256 + décompression), TLS, sync ; la compression et le chiffrement des VMs se font sur les nœuds PVE | 4 cœurs minimum (doc officielle), 8 à 16 pour plusieurs dizaines de To |
| RAM | OS, cache, démons ; ARC si ZFS | 4 Gio + environ 1 Gio par Tio de datastore (doc officielle) |
| Réseau | Sauvegarde nocturne, restauration complète, sync MSP | 10 Gb/s côté cluster dès que l'on vise des restaurations rapides ; lien MSP selon le calculateur |
Capacité : la méthode¶
- Mesurer le volume réellement occupé dans les VMs (pas la taille provisionnée des disques). Activez discard sur les disques virtuels : les blocs libérés dans l'invité ne sont alors plus lus ni stockés.
- Estimer le taux de changement quotidien (2 à 5 % typique, davantage pour bases de données et serveurs de fichiers actifs).
- Reporter la rétention prévue (keep-daily, keep-weekly, keep-monthly, keep-yearly) dans le calculateur.
- Appliquer la réduction déduplication + compression : 1,5 à 2 sur des VMs courantes, plus avec beaucoup de clones d'un même template.
- Ajouter 20 % de marge : la garbage collection ne libère l'espace qu'après un délai de grâce d'environ 24 h, et un datastore plein bloque toutes les sauvegardes.
- Projeter à 1 et 3 ans avec la croissance annuelle.
Formules détaillées : Comment on calcule. Sur un PBS en service, la réduction réelle se lit dans Datastore → Summary (Deduplication Factor) après quelques semaines.
IOPS : pourquoi les HDD seuls déçoivent¶
Un datastore de 20 To contient plusieurs millions de chunks. La garbage collection met à jour l'atime de chaque chunk référencé (phase 1), puis parcourt tout .chunks (phase 2). Le verify relit chaque chunk.
| Support | Sauvegarde | GC sur 20 To | Verify complet | Usage |
|---|---|---|---|---|
| SSD / NVMe entreprise | Rapide | Minutes à dizaines de minutes | Limité par le CPU | Recommandé |
| HDD + special vdev SSD miroir (ZFS) | Correcte | Raisonnable (métadonnées sur SSD) | Lent, à étaler | Bon compromis capacité / coût |
| HDD seuls (RAIDZ) | Correcte en séquentiel | Plusieurs heures | Très long | Copie secondaire uniquement |
Ces durées sont indicatives : mesurez-les en lab sur votre matériel.
CPU et réseau : mesurer plutôt que deviner¶
# depuis un nœud PVE : débit TLS, compression, SHA-256, chiffrement AES-256-GCM
proxmox-backup-client benchmark --repository root@pam@pbs01.client.lan:pbs01
La sortie compare les résultats à un processeur de référence. Le TLS mesure le chemin réseau réel vers le PBS.
| Flux | Calcul | Exemple 20 To, 3 %/jour, réduction 1,6 |
|---|---|---|
| 1re sauvegarde | Volume / fenêtre | 20 To en 8 h : environ 700 Mo/s, soit plus de 5 Gb/s |
| Sauvegarde quotidienne | Volume × taux / fenêtre | 600 Go en 8 h : environ 21 Mo/s |
| Sync MSP quotidienne | Volume × taux / réduction / fenêtre | 375 Go en 10 h : environ 85 Mbit/s |
| Restauration complète | Taille de la VM / débit lecture PBS | VM de 2 To à 300 Mo/s : environ 2 h |
La 1re synchronisation vers le MSP transfère tout le volume : prévoyez un seeding (amorçage) par disque amovible ou une montée progressive avec limite de débit, à organiser avec le MSP.
Matrice de départ par architecture livrée¶
| Architecture | Volume protégé typique | PBS local conseillé |
|---|---|---|
| Mono-nœud ZFS | < 5 To | Serveur compact, 4 à 8 SSD, 32 Go de RAM |
| ZFS répliqué 2 nœuds + QDevice | 5 à 15 To | Serveur dédié SSD ou HDD + special vdev, 64 Go de RAM, 10 Gb/s |
| Ceph HCI 3+ nœuds | 15 à 100 To | Serveur dédié, NVMe/SSD ou HDD + special vdev, 128 Go de RAM et plus, 2 × 10/25 Gb/s |
| SAN externe | Variable | Comme Ceph HCI ; jamais de datastore sur la baie sauvegardée |
Recommandations MSP¶
- Le PBS local est une machine physique distincte du cluster. Le QDevice d'un cluster 2 nœuds peut cohabiter sur ce serveur si le dossier d'exploitation le prévoit.
- Datastore sur ZFS en miroirs ou RAIDZ2, jamais sur un seul disque.
- Alerte de remplissage à 80 % (notifications natives), revue trimestrielle de la courbe dans le plan de capacité.
- Copiez le résumé du calculateur dans votre ticket iTop pour toute demande d'extension.
Pièges vus en support
- Dimensionner sur la taille provisionnée au lieu de la taille occupée, ou l'inverse quand discard n'est pas activé dans les VMs.
- Oublier la marge de GC : le datastore atteint 100 % la veille de la GC hebdomadaire.
- Datastore sur HDD seuls avec verify quotidien de tout le contenu : le verify chevauche la sauvegarde suivante.
- Lien MSP calculé sur le volume brut au lieu du volume quotidien dédupliqué, ou l'inverse pour la 1re sync.
- RAM sous-dimensionnée sur un PBS en ZFS : ARC réduit, GC lente.
Testez-vous¶
-
Pourquoi prévoir 20 % de marge au-delà des données uniques calculées ?
Réponse
La GC ne supprime un chunk orphelin qu'après le délai de grâce (environ 24 h après le marquage) : l'espace libéré par un prune n'est disponible qu'au cycle suivant. Il faut aussi absorber la croissance imprévue et les pics de changement.
-
Quelle ressource du PBS le verify consomme-t-il le plus ?
Réponse
Les lectures disque et le CPU (décompression et calcul SHA-256 de chaque chunk). Sur HDD sans special vdev, c'est la lecture qui limite.
-
Comment connaître le débit réel entre un nœud PVE et le PBS ?
Réponse
proxmox-backup-client benchmark --repository <user>@<realm>@<pbs>:<datastore>depuis le nœud : il mesure le TLS sur le chemin réel et les performances de hachage, compression et chiffrement. -
Combien de RAM pour un PBS de 40 Tio selon la recommandation officielle ?
Réponse
4 Gio de base + environ 40 Gio, soit 44 Gio minimum ; 64 Go en pratique, davantage avec ZFS.