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 cloud 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.
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
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 3e 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 backupaprè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.
Mise à jour 19/04 — le 2e run confirme la mécanique (et expose un dernier bug)
Dans la nuit du 18 au 19 avril, un 2e 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 2e 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) |
|---|---|---|
| Source | 876,6 GB | 876,9 GB |
| Chunks | 286 616 | 286 695 |
| Chunks dédupliqués | 215 784 (75,3 %) | 286 620 (99,97 %) |
| Upload réseau (non compressé) | 624 GB (71 %) | 1,73 GB (~0 %) |
| Durée | 20 h 30 | 14 h 10 |
| ACL NTFS uploadées | non (bug regex 400) | oui, 10 MB |
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 2e 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.
Ce qu'on ne peut pas (encore) affirmer
Trois points méritent d'être posés avec honnêteté :
- Un snapshot incrémental formellement scellé reste à produire. Le 2e run a mesuré le ratio de dédup (99,97 %) et l'upload effectif (1,73 GB), mais le
/finish400 a empêché PBS de valider le snapshot côté serveur. La mécanique dédup+upload est donc confirmée, mais la restauration bout-en-bout d'un incrémental sur ce groupe ne sera prouvée qu'au run suivant. - 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 2e 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.
- ⚠️ Ce 2e run n'a pas posé le sceau final (
/finish400 côté PBS) — le snapshot sera probablement rollback. Le premier snapshot incrémental restaurable est attendu sur le run suivant, une fois le fix client déployé.
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 1er run, ~310× moins au 2e) 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
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'articleCré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.
Lire l'articleVos volumes Windows méritent les mêmes garanties
NimbusBackup est un cloud PBS souverain : un Proxmox Backup Server hébergé en France, avec datastore dédié, déduplication native et client Windows open source. La même mécanique que celle décrite dans cet article, packagée et opérée pour vous.