Le contexte : premier vrai run prod du client GUI

Après plusieurs mois de développement et de tests internes, notre client Proxmox Backup Server Windows (GUI open source) vient de boucler son premier backup complet en production sur un volume significatif. Le datastore cible est hébergé chez NimbusBackup, un Backup PBS souverain opéré en France — aucune ligne dédiée, aucun VPN spécifique : juste HTTPS vers un Proxmox Backup Server managé.

Profil de la machine : un serveur Windows bare metal d'environ 1 To, en environnement PME / entreprise. Aucune donnée identifiante n'est divulguée — l'objectif est de capitaliser sur les chiffres réels du run, pas sur le client final.

Côté procédure, le client lui-même est documenté pas à pas dans notre tutoriel Proxmox Backup Client Windows (install, token API, premier scheduler — et si Windows signale l'exécutable au téléchargement, c'est un faux positif) ; côté infrastructure, l'exploitation continue du cluster Proxmox qui pousse ces backups relève de notre activité d' infogérance Proxmox.

Pourquoi publier ces chiffres

Sur le marché, on lit beaucoup de promesses (« déduplication × 10 », « débits line-rate ») et très peu de mesures concrètes. Cet article documente un run réel, ses bons points, ses limites, et ce qu'il ne prouve pas encore.

Chronologie : 20 h 30 de transfert, sans interruption

Le run a été déclenché par le scheduler interne du client en pleine nuit, et a tenu sans incident jusqu'au message successfully finished backup côté PBS.

Événement	Horodatage (Paris)
Démarrage du scheduler client	2026-04-15 01:30:38
Fin de l'analyse Auto-Split	2026-04-15 02:01:00
Création de l'index PBS	2026-04-16 01:40:49
Fin côté PBS (successfully finished)	2026-04-16 22:13:08
Durée du transfert PBS	20 h 32 min 19 s

Le type de run est backup complet initial : aucun snapshot précédent n'existait pour ce groupe (GET /previous: 400 no valid previous backup). C'est le scénario le plus coûteux, celui qui transfère tout, sans bénéficier d'un éventuel delta avec la veille.

Volumes traités

Métrique	Valeur
Taille source (pxar Size)	876 602 075 764 octets ≈ 876,6 GB (816,4 GiB)
Nombre total de chunks	286 616
Taille moyenne d'un chunk	~3,06 MB
Catalogue (pcat1)	55,4 MB en 17 chunks

Déduplication et compression : 57 % d'économie bout-en-bout

C'est ici que la mécanique PBS prend tout son sens, même sur un premier backup.

Déduplication côté client Proxmox Backup Server Windows : 75 % des chunks déjà connus

Chunks dédupliqués : 215 784 sur 286 616 → 75,3 % des chunks soit déjà présents sur le datastore, soit identifiés comme doublons internes au volume.
Chunks uniques transmis : 70 832 (24,7 %)
Octets uniques à transmettre : 624,1 GB (71 % de la source) — soit 252,5 GB économisés par la dédup (29 %)

Lecture honnête : sur un premier backup, les 75 % de dédup ne viennent pas d'une comparaison avec un backup antérieur — il n'y en a pas. Ils viennent essentiellement des doublons internes au volume (fichiers identiques répliqués dans plusieurs dossiers, blocs nuls, headers communs…). Les runs suivants iront chercher en plus les chunks déjà présents sur le datastore.

Compression : 60 % de la taille post-dédup

Sur les 624,1 GB d'octets uniques à transmettre, PBS applique sa compression côté client avant envoi (ratio annoncé dans les logs : Compression: 60%).

Résultat sur le fil : 624,1 GB × 60 % ≈ 374,5 GB réellement transmis sur le réseau.

Bilan dédup + compression

876,6 GB

source

~374,5 GB

sur le fil

57,3 %

d'économie

Débits moyens

Lecture côté source

876,6 GB / 20,54 h

≈ 42,7 GB/h • 11,85 MB/s

Trafic réseau effectif

Après dédup + compression

≈ 18,2 GB/h • 5,06 MB/s • 40,5 Mbps

Ces chiffres sont des moyennes sur l'ensemble du run. Les pics sont probablement plus élevés, et certaines phases (gros fichiers contigus vs millions de petits fichiers) tirent ou plombent le débit instantané. Sans profiling fin, on ne peut pas isoler ces variations — voir la section « Ce qu'on ne peut pas encore affirmer » en clôture.

La résilience prouvée : 20 h 30 sans rupture

Ce run est le 3^e essai. Les deux précédents avaient échoué :

Tentative 1 (13/04) : VSS Windows cassé, snapshot impossible. Fix appliqué côté client.
Tentative 2 (14/04) : coupure réseau prolongée + perte de session HTTP/2 côté PBS. Le client a échoué proprement, sans laisser de snapshot orphelin.
Tentative 3 (15-16/04) : successfully finished backup après 20 h 32 min de transfert continu.

Plusieurs correctifs récents du client GUI ont été éprouvés en conditions réelles pendant ce run :

Retry session-lost (25 min)

Sur perte de session HTTP/2 côté PBS, le client attend et retente plutôt que d'abandonner.

H2 keepalive

Maintien actif de la connexion HTTP/2 sur les phases d'analyse longues, pour éviter les coupures en silence.

Per-directory Finish()

Validation par dossier plutôt qu'en bloc final, pour limiter le coût d'une rupture en fin de run.

Ces fixes existaient déjà before ce run, mais ils n'avaient jamais été éprouvés sur une fenêtre de 20 h continues. C'est désormais le cas.

Bonus mécanique : la démonstration de l'incrémental

En parallèle, un autre dossier de la même machine, beaucoup plus petit et déjà sauvegardé les jours précédents, a été retraité le 17/04 à 01:18. Résultat :

pxar : 472 octets (1 seul chunk, 100 % upload size)
catalog : 72 octets
Durée totale : moins d'une seconde

Important : ce dossier n'est pas celui du gros volume qu'on vient de décrire. Il est sur la même machine, mais c'est un autre groupe de backup. Cette mesure ne prouve donc rien sur le comportement incrémental futur du gros volume — elle illustre le mécanisme PBS : quand un snapshot précédent existe et que rien n'a bougé, le client ré-enregistre les chunks du snapshot précédent et ferme l'index, sans rien uploader d'inutile.

Run 2 (18→19/04) — Ajout du support ACL Windows : la régression découverte

Dans la nuit du 18 au 19 avril, un 2^e run a été lancé sur le même groupe avec la version v0.2.69 du client GUI (correctifs sur l'upload des ACL NTFS et sur le handshake de finalisation). Les chiffres sont ce qu'on pouvait espérer d'un incrémental sur un volume quasi-stable — et exposent un dernier bug côté client.

Sur un dataset Windows de 876 GB, le 2^e backup quotidien a transféré ≈ 1,2 GB sur le réseau (vs 374 GB le premier jour) — soit ≈ 310× moins de trafic pour exactement le même volume sauvegardé. La promesse de la dédup PBS, vérifiée en production sur un client réel.

Métrique	Run 1 (15→16/04)	Run 2 (18→19/04)	Run 3 (19→20/04)
Source	876,6 GB	876,9 GB	876,9 GB
Chunks	286 616	286 695	286 695
Chunks dédupliqués	215 784 (75,3 %)	286 620 (99,97 %)	286 694 (99,9997 %)
Upload réseau (non compressé)	624 GB (71 %)	1,73 GB (~0 %)	1,61 GiB (1 chunk)
Durée	20 h 30	14 h 10	9 h 08
ACL NTFS uploadées	non (bug regex 400)	oui, 10 MB	oui
`/finish` côté PBS	OK	400 (rollback)	OK — snapshot scellé

La mécanique tient : 99,97 % des chunks sont reconnus comme déjà présents sur le datastore, l'upload réseau réel tombe à moins de 2 GB pour un volume source de 877 GB. Le ratio incrémental attendu est confirmé sur ce dataset — au moins sur la partie chunk / dédup / transfert.

Le dernier bug : un 400 côté PBS sur l'appel final /finish a empêché la pose du sceau sur le snapshot. PBS va très probablement rollback ce snapshot, comme il l'avait fait lors de la 2^e tentative du run initial.

Ce qui est passé quand même : tout le contenu a été chunké et dédupliqué correctement côté serveur, le blob d'ACL NTFS est arrivé, le catalog et le manifeste sont cohérents. Il ne manque que la validation finale. Les 876 GB scannés et les 14 h de calcul ne sont pas perdus : les chunks sont déjà présents sur le datastore. Le run suivant, avec le /finish corrigé, ne rejouera que le scan source et l'appel final — et bénéficiera à nouveau des 99,97 % de dédup. Aucune retransmission complète n'est nécessaire.

Autre signal : la durée tombe de 20 h 30 à 14 h 10 sans que la source ait changé. Le delta vient essentiellement du temps d'upload évité (1,73 GB vs 624 GB) ; l'analyse Auto-Split et la lecture disque côté client restent des coûts incompressibles sur ce volume.

Run 3 (19→20/04) — Correctif manifest-csum : premier snapshot scellé sur 1 To

Dans la nuit du 19 au 20 avril, un 3^e run a été lancé avec le correctif PBS manifest-csum (commit 26025ba) qui ciblait précisément le /finish 400 du run 2. Cette fois, le chemin UploadBlob (nimbus-acls.json.gz.blob, index.json.blob) a franchi la validation finale, et PBS a posé le sceau sur le snapshot.

Sauvegarde d'un vrai volume de prod de 876,9 GB (~1 To) : 9 h 08 min de bout-en-bout, 1,61 GiB réellement uploadé, 99,9997 % de chunks dédupliqués (1 seul nouveau chunk),/finish validé, snapshot scellé côté PBS. La chaîne chunk + dédup + upload + sceau final est fonctionnelle sur un volume prod 1 To — un dernier résidu côté verify reste à corriger (voir plus bas).

Run 3 — chiffres clés

Source : 876 897 205 286 octets ≈ 876,9 GB (816,7 GiB)
Chunks : 286 695 total, dont 286 694 dédupliqués (286 283 globaux + 411 depuis l'index du snapshot précédent) → 1 seul chunk réellement uploadé
Taux de déduplication : 99,80 % par volume (508 : 1), 99,9997 % par chunks
Compression : 71 % sur le peu de données réellement envoyées
Uploadé sur le fil : 1 725 366 850 octets ≈ 1,61 GiB (metadata + chunk unique + catalog ~52,9 MiB)
Fenêtre : 17:54:48 → 03:03:29 (J+1) — 9 h 08 min
Décomposition approximative : ~5 min 47 s pour register chunks + download .didx précédent + scan/chunking ; ~9 h 02 min sur la phase de vérification chunk-par-chunk (hash + interrogation PBS). Le goulot n'est pas la bande passante (1,6 GiB en 9 h) mais le traitement local de 816 GiB de source.

Ce run ferme la boucle ouverte en 19/04 : la mécanique chunking + dédup + compression + /finish tient bout-en-bout sur un vrai volume de production de ~1 To, avec un snapshot scellé côté PBS. Le correctif 26025ba sur manifest-csum tient en production.

Journal d'ingénierie — régression introduite par la feature ACL. La chronologie est importante pour lire ces runs correctement :

Run 1 (15-16/04, sans support ACL) : /finish OK et verify OK ✅ — les claims « snapshot scellé » et « résilience prouvée sur 20 h 30 » tiennent sans réserve.
Runs 2 & 3 (18→20/04, avec ACL) : l'ajout du sidecar ACL Windows nimbus-acls.json.gz.blob fait apparaître un wrong size constant de −12 octets côté verify (10 019 169 vs 10 019 181, 251 472 vs 251 484, 908 386 vs 908 398). Ces 12 octets correspondent exactement à la taille d'un header DataBlob PBS (magic 8 o + CRC32 4 o). Le sceau /finish passe, mais PBS marque ces snapshots comme corrompus tant que verify ne passe pas.
Run à venir : fix ciblé sur l'écriture du blob ACL (aligner la taille déclarée au manifeste avec la taille réelle du payload, header compris). Re-verify à valider en production.

Lecture factuelle : ce n'est pas un bug du backup en tant que tel — la chaîne chunk / dédup / upload / /finish tient sur 1 To (prouvé par Run 1). C'est une régression fonctionnelle introduite par une nouvelle feature (support ACL Windows, différenciant vs Veeam), sur un chemin spécifique (écriture du sidecar), bien localisé. L'article sera mis à jour quand le run post-fix aura passé verify.

Ce qu'on ne peut pas (encore) affirmer

Trois points méritent d'être posés avec honnêteté :

Les snapshots embarquant le sidecar ACL Windows ne passent pas encore verify. Run 1 (sans ACL) passe verify OK ; Runs 2 et 3 (avec ACL) ont leur /finish scellé mais verify KO sur l'écriture du blob ACL (régression 12 o, voir journal d'ingénierie ci-dessus). Un restore bout-en-bout d'un snapshot avec ACL n'est donc pas encore de confiance. Correctif en cours, run post-fix attendu.
Les bottlenecks par variable (CPU client, I/O disque source, version du client PBS, négociation TLS, latence réseau) ne sont pas isolés ici. Le débit moyen est mesuré, mais pas attribué.
La représentativité : un run sur un volume « data métier » ne dit pas grand-chose d'un run sur une base SQL active, sur un dossier de millions de petits fichiers, ou sur un volume très entropique (vidéos déjà compressées, archives chiffrées côté applicatif).

Suite prévue

Le profiling détaillé (CPU, I/O, version client PBS) n'a pas pu être réalisé dans le contexte de ce test. Un lab interne fera l'objet d'un article complémentaire pour isoler les bottlenecks par variable, sur des datasets contrôlés (gros fichiers, petits fichiers, données entropiques, bases ouvertes).

Ce qu'on retient

✅ Le client GUI Windows tient une fenêtre de 20 h 30 de transfert continu sans rupture sur un volume de presque 1 To.
✅ Sur un premier backup, on observe déjà 57 % d'économie bout-en-bout grâce à la dédup interne au volume + la compression PBS.
✅ Les correctifs réseau récents (retry session-lost, H2 keepalive, per-directory Finish) ont fait leurs preuves en production sur un run long.
⚠️ Le débit moyen (~5 MB/s effectifs sur le fil, ~12 MB/s en lecture source) est mesurable mais pas encore attribué — les bottlenecks seront isolés dans un lab dédié.
✅ Le 2^e run (18→19/04, client v0.2.69) mesure 99,97 % de chunks dédupliqués et 1,73 GB d'upload effectif sur 877 GB de source — le ratio incrémental attendu est confirmé sur ce dataset.
✅ Run 3 (19→20/04) : premier snapshot scellé en production sur un vrai volume de ~1 To. 9 h 08 min, 1,61 GiB uploadé, 99,9997 % de chunks dédupliqués (1 seul nouveau chunk), /finish validé. Le correctif manifest-csum (26025ba) tient.
✅ Run 1 (sans ACL) passe verify PBS sans erreur — la chaîne pxar + chunks + sceau final est intègre bout-en-bout sur 1 To.
⚠️ Runs 2 & 3 (avec support ACL) : verify KO sur le sidecar nimbus-acls.json.gz.blob avec un delta constant de −12 o = header DataBlob PBS (magic 8 o + CRC32 4 o). PBS marque ces 3 snapshots comme corrompus. Régression fonctionnelle introduite par la feature ACL, bien localisée — la chaîne principale (pxar + chunks + /finish) n'est pas en cause. Correctif en cours.

Étape suivante naturelle, une fois le snapshot stabilisé : poser une réplication PBS push/pull vers un second datastore pour passer d'un backup unique à une vraie architecture 3-2-1 — c'est le run prévu derrière celui-ci.

Et par rapport à Veeam ?

Comparé à un agent Veeam classique sur le même profil de volume, la mécanique PBS joue sur un autre plan : pas d'ingestion dans un repository propriétaire, pas de full synthétique à rejouer, pas de licence par socket. L'économie de trafic observée ici (57 % au 1^er run, ~310× moins au 2^e) tient à la dédup côté client et au chunking stable de PBS. Veeam propose de son côté des ratios comparables sur ses jobs forever-forward, mais derrière un modèle économique et une chaîne de restore très différents.

L'analyse détaillée se trouve dans notre dossier Proxmox Backup Server vs Veeam — compression, dédup, coût par To, restore granulaire.

Pour aller plus loin

Synthèse business du cas : 1 To Windows, −57 % de stockage

La version condensée côté décideur : volumétrie, économie bout-en-bout, fenêtre de sauvegarde et intégrité — sans le détail technique des runs.

Voir la synthèse business

Le client GUI Windows pour PBS (article principal)

L'article qui présente le client open source utilisé pour ce backup, avec le guide d'installation et de configuration.

Lire l'article

Créer et gérer ses tokens API PBS

Le prérequis d'authentification utilisé par le client GUI : un token par machine, révocable indépendamment.