Vitesse de restauration Proxmox : réglages PBS, choix de compression et pourquoi les restaurations sont lentes

Comment fonctionnent réellement les restaurations PBS (et pourquoi ce n’est pas juste « recopier le fichier »)

PBS n’est pas un dépôt bête de fichiers tar. C’est un magasin de chunks adressés par contenu avec déduplication et sauvegardes incrémentales.
Lors de la sauvegarde, le client découpe les données en chunks, calcule des checksums, compresse les chunks et envoie les chunks « nouveaux » au serveur.
C’est principalement un travail d’écritures séquentielles plus un peu de hachage. Les systèmes modernes adorent les écritures séquentielles.

La restauration est l’inverse mais pas symétrique. Restaurer une VM ou un conteneur nécessite de lire beaucoup de chunks, dans un ordre précis,
de réassembler les données, de vérifier l’intégrité, de décompresser et de les streamer vers le stockage cible. Les lectures de chunks peuvent être moins séquentielles
que vous l’espérez, surtout si la sauvegarde est fortement dédupliquée dans le temps ou entre machines. La déduplication est excellente pour la capacité.
Elle peut être un peu impolie pour le débit de restauration si votre stockage sous-jacent est faible en lectures aléatoires ou en opérations sur les métadonnées.

Le pipeline de restauration (modèle mental)

• Hôte PVE demande à PBS le contenu du snapshot (via proxmox-backup-client / outils intégrés).
• PBS lit les métadonnées des chunks, localise les fichiers de chunk, les lit depuis le datastore, vérifie les checksums.
• PBS décompresse les chunks (selon la façon dont les données ont été stockées).
• Hôte PVE reçoit un flux et l’écrit dans le stockage cible (ZFS, LVM-thin, Ceph, répertoire, etc.).
• Stockage cible réalise son propre travail : allocation, copy-on-write, checksumming, parité, comportement TRIM, etc.

Votre vitesse de restauration est essentiellement le minimum de quatre plafonds :
IOPS/débit de lecture du datastore, CPU pour décompression/checksums,
débit/latence réseau, et comportement d’écriture du stockage cible.
Il suffit qu’un seul d’entre eux soit mauvais pour que tout soit mauvais.

Une des vérités les plus agaçantes : la « vitesse de sauvegarde » est souvent limitée par le taux de changement, les gains de compression et l’efficacité de la déduplication.
La « vitesse de restauration » est limitée par la rapidité à recréer l’image complète, pas seulement le delta.

Faits intéressants et contexte historique (parce que les systèmes ne sont pas devenus étranges par accident)

1. La déduplication est devenue courante dans les sauvegardes d’entreprise au milieu et à la fin des années 2000 parce que le disque est devenu moins cher que les bibliothèques de bandes et que les liens WAN étaient pénibles.
2. Le stockage adressé par contenu (stocker les blocs par hash) a des racines dans des systèmes de recherche antérieurs, mais il a explosé avec des outils comme Git parce que c’est fiable et dédup-friendly.
3. Les defaults de compression modernes sont passés de gzip à zstd dans de nombreux écosystèmes à la fin des années 2010 car zstd offre de bons ratios avec un décodage beaucoup plus rapide que les codecs plus anciens.
4. Les sauvegardes « incremental forever » optimisent souvent la fenêtre de sauvegarde, pas la fenêtre de restauration ; le chemin de restauration peut devenir un tas d’indirections.
5. ZFS a popularisé le checksumming de bout en bout sur du stockage commodity ; c’est excellent pour la correction, mais chaque checksum reste du travail CPU au moment de la restauration.
6. Les pénalités d’écriture RAID5/6 sont connues ; moins rappelé est que la parité RAID peut aussi être médiocre en lectures aléatoires sous charge, ce que les magasins de chunks peuvent déclencher.
7. NVMe a changé les attentes sur la « vitesse disque » au point que beaucoup d’équipes blâment désormais le réseau en premier—parfois à raison, parfois non.
8. Les jobs de vérification sont une réaction culturelle aux incidents de corruption silencieuse des années 1990 et 2000 ; ils valent le coût, mais ils peuvent entrer en collision avec des restaurations.

Une citation que les ops répètent pour une raison : L’espoir n’est pas une stratégie. — Général Gordon R. Sullivan.
Un plan de restauration qui suppose « ce sera assez rapide » n’est que de l’espoir avec une ligne budgétaire.

Guide de diagnostic rapide (trouver le goulot en minutes)

Les restaurations sont sensibles au temps. Vous n’avez pas le temps d’« optimiser tout ». Il faut identifier rapidement le facteur limitant,
puis changer la chose qui augmente le plafond.

Première étape : côté lecture PBS, réseau ou écriture cible ?

1. Vérifiez le débit en direct aux deux extrémités. Si les disques PBS sont saturés mais que l’hôte cible est inactif, vous êtes limité en lecture. Si le réseau est saturé, c’est le réseau. Si le stockage cible est occupé (iowait élevé) alors que PBS va bien, vous êtes limité en écriture.
2. Vérifiez le CPU. Si un cœur est chaud et les autres inactifs pendant la restauration, vous pourriez être limité en mono-thread quelque part (décompression, checksum ou un driver de stockage).
3. Vérifiez la contention. Si GC/verify/prune tourne sur PBS, vous vous battez peut‑être contre vous-même. Arrêtez les tâches de fond pendant une restauration d’urgence.

Deuxième étape : le datastore se comporte-t-il comme « beaucoup de petites lectures » ou « grandes lectures séquentielles » ?

• Si votre datastore PBS est sur des HDD en RAID et que vous voyez un faible MB/s avec une pression IOPS élevée, le comportement de lecture aléatoire des chunks vous mord.
• Si c’est sur SSD/NVMe et que c’est lent, regardez le CPU, le chiffrement/la compression ou des problèmes d’offload réseau.

Troisième étape : le stockage cible est-il le coupable silencieux ?

• ZFS avec un small recordsize, sync lourd ou un ashift inadapté peut rendre les écritures tristes.
• LVM-thin sous pression métadonnée peut s’effondrer.
• Restaurer dans Ceph/RBD a ses propres réalités de réplication et backfill.

Blague #1 : Une restauration est comme un exercice incendie—sauf que le bâtiment est réellement en feu et tout le monde se rappelle soudain qu’il a « des questions ».

Choix de compression : zstd vs lzo vs aucune, et ce que payent vraiment les restaurations

La compression est le réglage le plus mal compris dans les systèmes de sauvegarde. Les équipes choisissent un algorithme selon la fenêtre de sauvegarde,
puis sont surprises quand le jour de la restauration facture les intérêts.

Ce que vous échangez

• CPU : compression et décompression coûtent des cycles. La décompression est généralement moins coûteuse que la compression, mais pas gratuite.
• Réseau : les données compressées réduisent les octets sur le fil ; cela peut améliorer énormément la restauration si vous êtes limité par le réseau.
• I/O du datastore : moins d’octets lus peut aider si vous êtes limité en débit, mais si vous êtes limité en lectures aléatoires, le CPU peut devenir le goulot suivant.
• Efficacité de la dédup : certaines stratégies de compression interagissent avec le chunking/la dédup. En général, le chunking se fait sur les données brutes puis les chunks sont compressés après ; cela maintient une dédup raisonnable.

Règle empirique valable en production

• zstd (niveaux modérés) est le défaut sensé. Bon ratio, décodage rapide, restaurations généralement amicales.
• lzo peut être attractif pour une faible charge CPU, mais vous payez en taille de données plus grande (plus de lectures disque, plus de réseau). Sur 10GbE+, ça peut encore aller ; sur 1GbE, c’est souvent pénible.
• aucune compression est rarement la réponse à moins d’être à l’étroit côté CPU et d’avoir un disque et un réseau absurdes à disposition.

Réalité de la restauration : le piège « sauvegarde rapide, restauration lente » lié à la compression

Il est courant d’augmenter fortement le niveau de compression pour réduire le coût de stockage. Cela peut se retourner contre vous.
La restauration exige de décompresser l’intégralité du jeu de données que vous voulez récupérer, pas seulement les blocs modifiés. Si votre PBS a un CPU modeste
et que vous avez choisi un niveau de compression élevé, vous pouvez vous retrouver lié au CPU sur le serveur pendant la restauration.

La bonne pratique est ennuyeuse : choisissez un réglage de compression qui maintient à la fois la sauvegarde et la restauration dans vos RTO.
Puis validez avec des tests de restauration réels, pas des intuitions.

Le chemin de stockage compte : datastores PBS, ZFS, RAID, SSD et mythes du cache

La performance de PBS dépend avant tout du datastore. Pas de l’UI. Pas du catalogue. Du datastore : l’endroit où vivent les fichiers de chunk.
Si vous placez votre datastore sur des disques lents, les restaurations vous le rappelleront.

Patrons d’I/O du datastore PBS en termes simples

• Ingest de sauvegarde : beaucoup d’écritures plutôt séquentielles de nouveaux chunks plus des mises à jour de métadonnées.
• Restauration : nombreuses lectures de fichiers de chunk, qui peuvent être partiellement séquentielles mais deviennent souvent « pleines de seeks » selon la distribution des chunks et l’historique de déduplication.
• Vérification : lit beaucoup de chunks pour confirmer l’intégrité ; cela entre en concurrence directe avec la restauration pour la bande passante de lecture.
• GC (garbage collection) : peut effectuer un travail métadonnées substantiel et des lectures disque ; ce n’est pas gratuit.

Recommandations de placement du datastore (opinionnées)

• Meilleur : miroir NVMe (ou SSD redondants) dédié au datastore PBS, surtout pour de nombreuses VMs et restaurations fréquentes.
• Bon : RAID10 SSD ou miroir ZFS avec capacité décente. Les lectures aléatoires comptent.
• Acceptable : RAID10 HDD pour de larges archives où les restaurations sont rares et le RTO flexible.
• À éviter : RAID de parité (RAID5/6) de HDD pour des charges actives de restauration, sauf si vous avez testé et accepté le temps de restauration.
• Évitez aussi : mettre le datastore PBS sur le même pool qui exécute aussi des workloads VM. C’est s’auto-infliger de la douleur supplémentaire.

Spécificités ZFS (parce que la plupart des boîtes PBS finissent sur ZFS)

ZFS peut être excellent pour PBS : checksumming, snapshots et comportement prévisible. Mais vous devez respecter la manière dont ZFS alloue et met en cache.
Un datastore PBS est une charge fichier avec beaucoup de lectures et de recherches de métadonnées. C’est une pression sur l’ARC et potentiellement des lectures à petits blocs.

• Taille ARC : suffisamment de RAM aide les métadonnées et les chunks chauds. Pas assez de RAM signifie plus de lectures disque et des restaurations plus lentes.
• Recordsize : pour un système de fichiers stockant des fichiers de chunk, le recordsize par défaut est souvent correct. Ne modifiez pas le recordsize au hasard sauf si vous connaissez la distribution des tailles de chunk et avez mesuré les résultats.
• SLOG : généralement sans rapport pour les restaurations PBS ; SLOG affecte les écritures synchrones, pas les lectures. Si quelqu’un suggère de « réparer la vitesse de restauration avec un SLOG », vous avez trouvé un devin confiant.
• L2ARC : peut aider si votre working set de chunks est mise en cache et répétée. Pour une restauration ponctuelle de catastrophe, il se réchauffe souvent lentement et fait peu.

Blague #2 : L2ARC, c’est comme un stagiaire—utile après l’intégration, mais il ne vous sauvera pas le premier jour de l’incident.

Réseau et transport : quand le 10GbE restaure comme en 2009

Les problèmes réseau sont ennuyeux jusqu’à ce qu’ils ne le soient plus. Une restauration est un flux soutenu qui rend visibles tous les mauvais réglages de NIC et chaque
switch surabonné.

À surveiller

• Mauvais MTU : des jumbo frames sur une extrémité et pas sur l’autre entraînent fragmentation ou blackholing. Les performances deviennent « mystérieusement mauvaises ».
• CPU par paquet : de petits paquets à haut débit peuvent saturer un cœur. Cela arrive plus souvent que beaucoup ne l’admettent.
• Erreurs de bonding/LACP : vous n’obtenez pas forcément un débit agrégé pour un seul flux ; beaucoup de restaurations sont un seul flux TCP.
• Firewall/IPS : l’inspection profonde des paquets sur le VLAN de sauvegarde est une excellente façon de transformer les restaurations en art de performance.

La latence compte plus que vous ne le pensez

Les motifs de fetch de chunks dédupliqués peuvent impliquer beaucoup de petites lectures et de recherches de métadonnées. Si l’interaction client-serveur nécessite
beaucoup de cycles requête/réponse, la latence et la perte de paquets comptent. C’est pourquoi « 10GbE » n’est pas une garantie. C’est un plafond.

Réglages PBS qui déplacent réellement la jauge

PBS n’a pas 400 réglages de performance cachés, ce qui est une bonne chose. Les gains sont surtout architecturaux :
stockage rapide, CPU suffisant, RAM suffisante, et planification des jobs de fond pour qu’ils ne se battent pas avec les restaurations.

Planification et contention : le gain le plus simple

• Les jobs de verify sont importants mais ne devraient pas tourner pendant les heures de production si les restaurations doivent être rapides.
• La GC doit être planifiée en tenant compte des fenêtres de restauration. GC + restauration = disques tristes.
• Prune est généralement plus léger mais peut tout de même provoquer du churn si les snapshots sont énormes et fréquents.

Considérations sur le chiffrement

Si vous utilisez le chiffrement, vous ajoutez une charge CPU. Sur les CPU modernes avec AES-NI, c’est souvent acceptable. Mais « souvent » n’est pas « toujours ».
Si votre PBS est un ancien serveur recyclé d’un labo, le chiffrement peut devenir le goulot en restauration.

Disposition du datastore

Gardez le datastore sur une pile filesystem/block device que vous comprenez. Les couches exotiques (systèmes de fichiers distants, chiffrement empilé,
thin provisioning sous thin provisioning) ont tendance à produire un comportement imprévisible sous pression de restauration.

Côté Proxmox : QEMU, LVM-thin, zvols ZFS, et où la vitesse meurt

Les gens aiment blâmer PBS parce que c’est « le truc de sauvegarde ». Mais les restaurations écrivent dans quelque chose. Ce quelque chose peut être lent.

Stockage cible ZFS

Restaurer une grosse VM dans un zvol ZFS signifie que ZFS alloue, vérifie et écrit. Si le pool cible est fragmenté,
presque plein ou basé sur des HDD, ça se verra. Aussi : si vous avez sync=always ou une charge forçant des écritures sync,
vous pouvez mettre à genoux le débit.

Stockage cible LVM-thin

Les thin pools peuvent restaurer rapidement quand ils sont sains. Quand les métadonnées du thin sont sous pression, ou quand le pool est proche du plein,
les performances peuvent s’effondrer. Ça échoue comme un adulte : silencieusement, lentement, et pendant la seule restauration qui compte.

Ceph / stockage répliqué

Restaurer dans Ceph signifie écrire des objets répliqués, ce qui peut déclencher backfill ou recovery si le cluster n’est pas parfaitement calme.
Votre vitesse de restauration devient « ce que le cluster peut ingérer en toute sécurité sans basculer ».

Tâches pratiques : commandes, interprétation des sorties et décision à prendre

Ce ne sont pas des commandes « lancez-les et sentez-vous productif ». Chacune vous dit où la restauration est bridée et quoi faire ensuite.
Exécutez-les pendant un test de restauration ou une restauration réelle, car les systèmes inactifs mentent.

Tâche 1 : Identifier si PBS est lié au CPU pendant la restauration

cr0x@pbs1:~$ top -H -b -n 1 | head -n 25
top - 10:14:21 up 42 days,  3:11,  2 users,  load average: 11.42, 10.98, 9.87
Threads: 412 total,   9 running, 403 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.1 us,  3.2 sy,  0.0 ni,  1.8 id,  2.9 wa,  0.0 hi,  0.0 si,  0.0 st
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
51231 backup    20   0 5348128 612144  28740 R  198.0   3.8  12:41.22 proxmox-backup
51244 backup    20   0 5348128 612144  28740 R  183.5   3.8  12:39.08 proxmox-backup

Ce que cela signifie : Si des threads proxmox-backup consomment beaucoup de CPU et que l’iowait est bas, vous êtes probablement lié au CPU (décompression, chiffrement, checksum).

Décision : Baisser le niveau de compression pour les futures sauvegardes, scaler le CPU du PBS, ou déplacer le datastore vers un stockage plus rapide pour que le CPU n’attende pas.

Tâche 2 : Confirmer l’utilisation disque du datastore et l’iowait sur PBS

cr0x@pbs1:~$ iostat -xm 1 5
Linux 6.2.16-20-pve (pbs1) 	12/28/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.54    0.00    6.91   41.33    0.00   29.22

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s  w_await aqu-sz  %util
nvme0n1         220.0  85432.0     0.0    0.0    3.12   388.3      15.0   6240.0   8.90   1.20   78.0

Ce que cela signifie : Un iowait élevé et une forte utilisation du périphérique suggèrent que le datastore est le goulot. Regardez r_await—s’il est élevé (dizaines de ms sur SSD, centaines sur HDD), les lectures bloquent.

Décision : Déplacer le datastore vers un média plus rapide, ajouter des spindles (RAID10), ou arrêter les jobs concurrents (verify/GC).

Tâche 3 : Confirmer si verify ou GC est en concurrence avec les restaurations

cr0x@pbs1:~$ systemctl list-units --type=service | egrep 'proxmox-backup-(garbage|verify|prune)'
proxmox-backup-garbage-collection.service loaded active running Proxmox Backup Garbage Collection
proxmox-backup-verify.service              loaded active running Proxmox Backup Verify Job

Ce que cela signifie : Si GC/verify tourne pendant une restauration, vous créez volontairement une contention de lecture.

Décision : Arrêter ou reprogrammer ces jobs pendant les restaurations urgentes ; définir des fenêtres de jobs qui respectent le RTO.

Tâche 4 : Inspecter les logs des tâches PBS pour les phases lentes

cr0x@pbs1:~$ proxmox-backup-manager task list --limit 5
┌──────────┬──────────────────────────┬───────────────┬─────────┬──────────┬───────────┐
│  upid    │          starttime       │     worker    │  type   │ status   │ duration  │
╞══════════╪══════════════════════════╪═══════════════╪═════════╪══════════╪═══════════╡
│ UPID:... │ 2025-12-28T09:58:03Z     │ reader        │ restore │ running  │ 00:16:22  │
└──────────┴──────────────────────────┴───────────────┴─────────┴──────────┴───────────┘

Ce que cela signifie : La liste des tâches montre ce que PBS croit faire et depuis combien de temps. Croisez avec les métriques système.

Décision : Si les tâches de restauration durent longtemps alors que le système est inactif, suspectez le réseau/côté client. Si le système est chargé, suspectez le stockage/CPU PBS.

Tâche 5 : Valider l’espace libre du datastore et le risque de fragmentation

cr0x@pbs1:~$ df -h /mnt/datastore
Filesystem      Size  Used Avail Use% Mounted on
rpool/pbsdata   7.1T  6.5T  0.6T  92% /mnt/datastore

Ce que cela signifie : Les systèmes de fichiers très pleins peuvent ralentir les allocations et les mises à jour de métadonnées, surtout sur les systèmes CoW.

Décision : Pruner agressivement, étendre le stockage ou ajouter un second datastore. Garder une marge ; 80–85 % est plus confortable.

Tâche 6 : Vérifier la santé du pool ZFS et la latence sur PBS (si datastore sur ZFS)

cr0x@pbs1:~$ zpool iostat -v 1 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                       6.50T   600G   1200     80   140M  10.2M
  mirror                    6.50T   600G   1200     80   140M  10.2M
    nvme0n1                 -      -       600     40   70.0M  5.1M
    nvme1n1                 -      -       600     40   70.0M  5.1M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Confirme si les vdevs ZFS sont le facteur limitant et si la bande passante de lecture correspond aux attentes.

Décision : Si la bande passante est faible et les ops élevées, vous êtes IOPS-bound ; passez à NVMe ou ajoutez des vdevs (prudemment) pour améliorer le parallélisme.

Tâche 7 : Vérifier la pression ARC (cache ZFS) sur PBS

cr0x@pbs1:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:20:01  3420  1210     35  1100  91    110   9     0   0   28.5G  32.0G
10:20:02  3588  1402     39  1280  91    122   9     0   0   28.5G  32.0G

Ce que cela signifie : Un miss% élevé pendant la restauration signifie que ZFS va souvent sur disque. Quelques misses sont normaux ; des misses persistants suggèrent que la RAM limite ou que la charge ne se met pas en cache.

Décision : Ajouter de la RAM si les métadonnées/chunks sont potentiellement cacheables, ou accepter que la restauration soit limitée par le disque et upgrader les disques.

Tâche 8 : Mesurer le débit réseau et les retransmissions pendant la restauration

cr0x@pve1:~$ ip -s link show vmbr0
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    8123456789  7212345      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    6234567890  6123456      0       0       0       0

Ce que cela signifie : Des drops sur le bridge/NIC pendant une restauration sont un signal d’alarme. Les drops provoquent des retransmissions et écrasent le débit.

Décision : Corriger la couche physique/réseau : cohérence MTU, buffers de switch, offloads NIC, ou déplacer le trafic de restauration hors des segments congestionnés.

Tâche 9 : Valider le MTU de bout en bout (tueur silencieux fréquent)

cr0x@pve1:~$ ping -M do -s 8972 -c 2 10.10.10.20
PING 10.10.10.20 (10.10.10.20) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 10.10.10.20 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Ce que cela signifie : Cet hôte n’est pas configuré pour les jumbo frames. Si vous attendiez MTU 9000, vous ne l’avez pas.

Décision : Standardiser sur 1500 partout ou configurer les jumbo frames partout (NICs, bridges, switches). « Quelque part » n’est pas un MTU valide.

Tâche 10 : Vérifier les performances d’écriture côté client (datastore cible sur PVE)

cr0x@pve1:~$ iostat -xm 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.87   55.21    0.00   29.80

Device            r/s     rkB/s   r_await  w/s     wkB/s   w_await  %util
dm-3              1.0      8.0     2.10  920.0  94208.0   34.90   99.0

Ce que cela signifie : Si le périphérique cible est à ~99 % d’utilisation et l’iowait est élevé, la restauration est liée aux écritures sur l’hôte PVE.

Décision : Restaurer sur un stockage plus rapide, changer la cible (par ex. restaurer sur NVMe local puis migrer), ou réparer le pool/array sous-jacent.

Tâche 11 : Vérifier si le thin pool est proche du plein (LVM-thin)

cr0x@pve1:~$ lvs -a -o+seg_monitor,metadata_percent,data_percent vg0
  LV               VG  Attr       LSize   Pool Origin Data%  Meta%  Monitor
  vmdata           vg0 twi-aotz--  2.50t             93.12  78.55  monitored
  [vmdata_tmeta]   vg0 ewi-ao----  4.00g
  [vmdata_tdata]   vg0 ewi-ao----  2.50t

Ce que cela signifie : Un thin pool à 93 % d’utilisation des données est un problème de performance et de risque ; des métadonnées à ~79 % ne sont pas non plus idéales.

Décision : Étendre le thin pool, libérer de l’espace, ou déplacer les restaurations ailleurs. Envisager aussi le trimming et la surveillance avant d’atteindre le mur.

Tâche 12 : Vérifier l’occupation du pool ZFS cible et le risque de fragmentation

cr0x@pve1:~$ zfs list -o name,used,avail,refer,mountpoint
NAME            USED  AVAIL  REFER  MOUNTPOINT
rpool           1.92T   110G   192K  /rpool
rpool/ROOT       32G   110G    32G  /
rpool/vmdata    1.88T   110G   1.88T  -

Ce que cela signifie : 110G disponible sur un pool de plusieurs téraoctets, c’est « on vit dangereusement ». Les performances ZFS se dégradent quand les pools se remplissent.

Décision : Libérer de l’espace ou ajouter de la capacité avant des restaurations massives ; cibler un pool avec de la marge.

Tâche 13 : Confirmer le chemin et le processus de restauration sur l’hôte PVE

cr0x@pve1:~$ ps aux | egrep 'proxmox-backup-client|qemu-img|vma' | grep -v egrep
root     144233  110  2.1 2154320 342112 ?      Sl   10:02   8:14 proxmox-backup-client restore vm/102/2025-12-28T09:40:12Z drive-scsi0.img.fidx --repository pbs@pam@10.10.10.20:pbs --target /dev/zvol/rpool/vm-102-disk-0

Ce que cela signifie : Montre quel outil et quel chemin cible sont en jeu. Restaurer dans un zvol vs un fichier vs LVM change le comportement.

Décision : Si vous écrivez dans un backend lent, changez la cible de restauration (restaurer dans un répertoire sur NVMe rapide, puis importer/migrer).

Tâche 14 : Vérifier les bizarreries évidentes d’offloads NIC (sanity rapide)

cr0x@pve1:~$ ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Ce que cela signifie : Des offloads désactivés peuvent augmenter le coût CPU par paquet. Des offloads activés mais bugués peuvent aussi nuire, mais commencez par les basiques.

Décision : Si le CPU est saturé sur softirq pendant la restauration, testez la désactivation des offloads (prudemment) et validez les versions du driver/firmware.

Tâche 15 : Test de débit disque rapide et sale sur le datastore PBS (hors heures)

cr0x@pbs1:~$ fio --name=readtest --directory=/mnt/datastore --rw=read --bs=1M --iodepth=16 --numjobs=1 --size=8G --direct=1 --runtime=30 --time_based
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
read: IOPS=820, BW=820MiB/s (860MB/s)(24.0GiB/30001msec)

Ce que cela signifie : Ceci approxime les lectures séquentielles ; les restaurations peuvent être plus aléatoires. Néanmoins, si votre datastore ne peut pas fournir de bonnes lectures ici, il ne restaurera pas vite.

Décision : Si le BW est bien en dessous des capacités matérielles attendues, investiguez les réglages du contrôleur, la disposition du pool et la santé des disques.

Tâche 16 : Détecter des disques lents ou des erreurs sur PBS

cr0x@pbs1:~$ dmesg -T | egrep -i 'error|reset|timeout|nvme|ata' | tail -n 10
[Sat Dec 27 22:14:09 2025] nvme nvme1: I/O 123 QID 4 timeout, reset controller
[Sat Dec 27 22:14:10 2025] nvme nvme1: Abort status: 0x371

Ce que cela signifie : Les timeouts et resets de contrôleur vont creuser les performances et la fiabilité. Une restauration amplifie la douleur.

Décision : Remplacer le média défaillant, mettre à jour le firmware, et arrêter de traiter les erreurs comme du « bruit ».

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a consolidé ses sauvegardes sur PBS et a fêté : fenêtres de sauvegarde réduites, croissance de stockage ralentie, et tableaux de bord calmes.
L’équipe a supposé que la restauration évoluerait de la même façon parce que « c’est juste relire ce qu’on a écrit ».

Le premier vrai test est arrivé lors d’une panne applicative nécessitant la restauration rapide d’une VM de plusieurs téraoctets. La restauration a démarré, puis a ramé.
Les graphiques réseau montraient de la marge. Les graphiques CPU étaient normaux. Les disques du datastore PBS étaient à forte utilisation avec une latence de lecture moche.

Le datastore résidait sur un grand RAID de parité en HDD. Il avait été choisi pour le coût par capacité, et il excellait pour les écritures en streaming.
Les restaurations, en revanche, ont déclenché un motif de lectures semi-aléatoires que le tableau a mal supporté : l’array a souffert poliment.

Ils ont corrigé ça en déplaçant le datastore actif vers des SSD en miroir (et en laissant les données plus anciennes sur le pool HDD). Les temps de restauration sont devenus prévisibles.
L’hypothèse erronée ne portait pas sur PBS ; elle portait sur l’idée que le comportement de lecture serait « identique » au comportement d’écriture. Le stockage ne promet jamais la symétrie.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait réduire le coût du stockage de sauvegarde. Quelqu’un a proposé d’augmenter fortement la compression parce que les sauvegardes étaient « pour la plupart les mêmes »
et « le CPU est bon marché ». Ils ont tourné le bouton et ont vu l’utilisation du datastore s’aplatir. Le changement avait l’air brillant.

Des mois plus tard, ils ont dû restaurer plusieurs VMs simultanément après un mauvais déploiement. Les restaurations étaient douloureusement lentes et instables.
Le CPU PBS était saturé, mais pas de manière « efficace »—plutôt « je n’arrive plus à respirer ».

Le niveau de compression choisi allait pour les sauvegardes nocturnes, mais la restauration était une urgence diurne. La décompression est devenue le goulot,
et parce que plusieurs restaurations tournaient en même temps, elles ont amplifié la contention CPU. Le stockage était rapide. Le réseau était OK. Le CPU ne l’était pas.

La correction n’était pas héroïque : ils ont réduit la compression à un niveau zstd modéré, ajouté un peu de CPU, et—ce que personne n’aime entendre—testé les restaurations chaque trimestre.
Les coûts de stockage ont légèrement augmenté. Le RTO s’est amélioré drastiquement. L’« optimisation » avait optimisé la mauvaise chose.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise réglementée avait une règle ingrate : chaque trimestre, choisir une VM au hasard et faire une restauration complète en bare-metal dans un VLAN isolé.
Ils notaient le temps, le goulot et les étapes nécessaires. Personne n’aimait ça. Ça prenait des heures et ne produisait aucune fonctionnalité brillante.

Un trimestre, la restauration a été plus lente que prévu. L’environnement de test a montré des paquets perdus sur un port de switch et un compteur d’erreurs RX en hausse.
La VM a quand même été restaurée—finalement—mais le postmortem indiquait « réparer le chemin réseau avant que ça n’ait de l’importance ».

Deux mois plus tard, un hôte a échoué. Ils ont restauré plusieurs VMs sous pression. Les restaurations se sont déroulées proches des chiffres testés, parce que le port de switch défaillant avait déjà été remplacé.
Personne n’a applaudi. Personne n’a acheté de gâteau. Le canal d’incident est resté ennuyeux, ce qui est le meilleur résultat que l’opération puisse espérer.

La pratique n’était pas brillante. Elle était reproductible. Elle les a sauvés d’apprendre leur réseau pendant une vraie panne.

Erreurs fréquentes : symptôme → cause racine → correction

1) « Les sauvegardes sont rapides, les restaurations sont lentes » (classique)

Symptôme : Les jobs de sauvegarde se terminent vite ; les restaurations rampent, surtout pour de grosses VMs.

Cause racine : Datastore optimisé pour les écritures séquentielles, pas pour les lectures massives de chunks (HDD en RAID de parité, pool occupé, ou faible IOPS).

Correction : Mettre le datastore actif sur SSD/NVMe en miroir/RAID10. Séparer le datastore « hot restore » de l’archive froide.

2) La vitesse de restauration varie fortement d’une heure à l’autre

Symptôme : Parfois les restaurations vont bien ; parfois elles sont inutilisables.

Cause racine : Contention avec verify/GC/prune, ou stockage partagé avec d’autres workloads.

Correction : Programmer les jobs de fond ; isoler le stockage PBS ; limiter la concurrence pendant les heures de travail.

3) La restauration se bloque à un pourcentage et « estimation » semble figé

Symptôme : La progression UI bouge à peine ; les logs montrent de longues pauses.

Cause racine : Pics de latence de lecture disque, disques SMR, timeouts de contrôleur, ou média défaillant provoquant des retries.

Correction : Vérifier dmesg, logs SMART/NVMe et iostat latence. Remplacer les disques instables ; éviter les SMR pour un datastore actif.

4) Lien 10GbE, mais la restauration plafonne à 80–150 MB/s

Symptôme : Le réseau « devrait » donner plus, mais le débit reste bas.

Cause racine : Limites d’un seul flux, MTU mal configuré, paquets perdus, surcharge firewall/IPS, ou saturation softirq CPU.

Correction : Valider MTU bout en bout ; vérifier drops et retransmissions ; déplacer le trafic de restauration ; tuner offloads NIC et affinité IRQ si nécessaire.

5) CPU saturé sur PBS pendant la restauration

Symptôme : Forte utilisation CPU, faible utilisation disque ; restaurations lentes.

Cause racine : Niveau de compression élevé, surcharge de chiffrement, ou nombre de cœurs insuffisants pour des restaurations concurrentes.

Correction : Utiliser zstd modéré ; activer accélération AES si chiffré ; ajouter des cœurs ; limiter les restaurations concurrentes ; envisager séparer les workloads ingest et restore (plus grand PBS ou second PBS).

6) Restauration dans ZFS plus lente que prévu

Symptôme : PBS va bien ; iowait PVE élevé, écritures lentes.

Cause racine : Pool cible presque plein, layout vdev lent, fragmentation, ou réglages sync.

Correction : Ajouter de la capacité, garder une marge libre, restaurer sur un stockage temporaire plus rapide puis migrer, vérifier le design du pool ZFS (miroirs pour IOPS).

7) Les restaurations LVM-thin démarrent vite puis se dégradent

Symptôme : Les premières minutes sont excellentes ; ensuite ça chute.

Cause racine : Thin pool ou métadonnées proches du plein ; contention I/O métadonnées.

Correction : Étendre le thin pool ; libérer de l’espace ; surveiller Data% et Meta% ; éviter d’exploiter les thin pools à haute utilisation.

8) Plusieurs restaurations à la fois rendent tout inutilisable

Symptôme : Une restauration est acceptable ; trois restaurations sont catastrophiques.

Cause racine : Goulot partagé (IOPS datastore, CPU PBS, files d’attente réseau, ou limites d’écriture du stockage cible).

Correction : Limiter la concurrence ; étaler les restaurations ; upgrader le goulot partagé ; envisager des datastores ou nœuds PBS séparés.

Listes de vérification / plan étape par étape

Étape par étape : accélérer les restaurations sans tuning cargo-cult

1. Choisir une cible de restauration : définir un RTO pour « une VM critique » et « pire jour : 5 VMs critiques ». Si vous ne pouvez pas nommer de chiffres, vous ne pouvez pas tuner.
2. Effectuer un vrai test de restauration pendant une fenêtre calme. Mesurer le débit de bout en bout (disque PBS, CPU PBS, réseau, disque PVE).
3. Éliminer la contention : programmer verify/GC loin des fenêtres de restauration. Ne pas partager le datastore PBS avec des workloads VM.
4. Décider du goulot en utilisant le guide de diagnostic rapide. Ne passez pas à l’upgrade de trois choses à la fois.
5. Si le côté lecture est le goulot : déplacer le datastore vers SSD/NVMe, préférer miroirs/RAID10, garantir assez de RAM pour le cache métadonnées.
6. Si le CPU est le goulot : baisser le niveau de compression, activer l’accélération AES si chiffré, ajouter des cœurs, limiter les restaurations concurrentes.
7. Si le réseau est le goulot : valider MTU, éliminer les drops, nettoyer le chemin (pas d’inspection surprise), et vérifier le débit single-flow attendu.
8. Si l’écriture cible est le goulot : restaurer sur un stockage local plus rapide puis migrer ; corriger l’espace libre ZFS ; étendre les thin pools.
9. Retester après chaque changement et enregistrer le résultat. « On dirait plus rapide » n’est pas une métrique.
10. Institutionnaliser la pratique ennuyeuse : exercices de restauration trimestriels, avec temps et goulots consignés.

Checklist jour de restauration (quand c’est déjà l’incendie)

• Arrêter/suspendre temporairement les jobs verify et GC PBS s’ils concourent pour la lecture I/O.
• Lancer iostat sur PBS et PVE pour décider lecture-bound vs write-bound.
• Vérifier la saturation CPU PBS et l’iowait PVE.
• Vérifier drops NIC et signes de MTU mal configuré.
• Limiter les restaurations concurrentes jusqu’à compréhension du goulot.
• Si le stockage cible est lent, restaurer sur une cible temporaire plus rapide puis migrer.

FAQ

1) Pourquoi mes sauvegardes se terminent rapidement mais les restaurations prennent une éternité ?

Les sauvegardes peuvent être incrémentales et dédupliquées—donc vous envoyez surtout des chunks modifiés. Les restaurations reconstruisent l’image complète et peuvent déclencher beaucoup de lectures de chunks plus la décompression.
La latence et les IOPS de lecture du datastore comptent bien plus pour la restauration que pour la sauvegarde.

2) La vitesse de restauration PBS dépend surtout du disque, du CPU ou du réseau ?

Cela dépend de l’élément le plus faible sur le chemin. En pratique, la latence de lecture du disque datastore est le limiteur le plus fréquent, suivie par les performances d’écriture cible.
Le CPU devient limitant lorsque la compression/le chiffrement est lourd ou que le PBS est sous-dimensionné.

3) Dois-je utiliser zstd ou lzo pour de meilleures restaurations ?

Le zstd modéré est habituellement le meilleur choix global : bonne compression avec une décompression rapide. Le lzo réduit le CPU mais augmente les octets lus/transférés.
Si vous êtes limité par le réseau (1GbE), zstd restaure souvent plus vite. Si vous êtes limité CPU et avez stockage/réseau très rapides, lzo peut aider.

4) La déduplication ralentit-elle les restaurations ?

La dédup peut complexifier le motif de lecture, ce qui nuit sur un stockage à lectures aléatoires lentes. Sur SSD/NVMe, la pénalité est généralement faible.
La dédup vaut souvent le coût ; évitez simplement de placer le datastore sur des disques qui détestent les lectures aléatoires.

5) Ajouter un SLOG accélérera-t-il les restaurations ?

Pas de manière significative. Le SLOG aide la latence des écritures synchrones, pas le débit de lecture. Les restaurations sont orientées lecture sur PBS et écriture sur la cible.
Dépensez votre budget sur un datastore plus rapide et sur de meilleures performances d’écriture cible.

6) Dois-je exécuter les jobs de verify quotidiennement ?

Vérifier l’intégrité est sage. L’exécuter en collision avec des restaurations est mauvais. Planifiez verify quand l’urgence des restaurations est faible,
et dimensionnez le datastore pour que verify ne prenne pas toute la journée.

7) Pourquoi restaurer beaucoup de VMs à la fois est-il si lent ?

Vous augmentez la contention sur des ressources partagées : IOPS du datastore, CPU PBS, files réseau et écritures du stockage cible.
Si vous avez besoin de restaurations parallèles, concevez pour cela : plus d’IOPS (miroirs NVMe), plus de CPU et un chemin réseau propre.

8) Mieux vaut restaurer sur un stockage local puis migrer, plutôt que restaurer directement sur du stockage partagé ?

Souvent oui. Restaurer sur un NVMe local rapide peut réduire considérablement le temps jusqu’au premier boot.
Vous pouvez ensuite migrer la VM vers un stockage plus lent/répliqué après l’incident, quand tout le monde est moins nerveux.

9) Combien d’espace libre garder sur le datastore PBS et les pools ZFS ?

Assez pour ne pas être constamment au bord du gouffre. Une cible pratique est de garder 15–20% d’espace libre sur les pools qui nécessitent performance et allocations prévisibles.
Si vous êtes à 90%+, attendez-vous à des surprises de performance.

10) Quelle est la mise à niveau la plus impactante pour les restaurations ?

Mettre le datastore PBS sur SSD/NVMe avec une disposition fournissant des IOPS (miroirs/RAID10). Les arrays HDD parité centrés sur la capacité sont un goulot de restauration courant.
Ensuite, assurez-vous que le stockage cible peut accepter les écritures au rythme de la restauration.

Conclusion : les actions suivantes qui rapportent

La performance de restauration n’est pas mystique. C’est un pipeline avec des points d’étranglement prévisibles. Si vos restaurations sont lentes, arrêtez de deviner et mesurez :
latence de lecture du datastore, CPU PBS, santé réseau et comportement d’écriture cible. Vous trouverez généralement une ressource qui crie plus fort que les autres.

Actions pratiques suivantes qui produisent souvent une amélioration immédiate :

• Programmer GC/verify pour qu’ils ne concurrencent jamais les fenêtres de restauration.
• Déplacer le datastore actif sur SSD/NVMe en miroir (ou RAID10) si la vitesse de restauration compte.
• Choisir une compression sensée (zstd modéré) et valider avec des restaurations trimestrielles.
• Garder de la marge sur le datastore PBS et les pools cibles ; les systèmes pleins sont lents.
• Documenter un runbook de restauration incluant les commandes de diagnostic rapide, pour ne pas déboguer sous adrénaline.

L’objectif n’est pas de rendre les restaurations « rapides ». L’objectif est de les rendre prévisibles. Des restaurations prévisibles vous laissent dormir la nuit.
Ou au moins dormir jusqu’au prochain incident, différent.