Context: first real production run of the GUI client

After several months of development and internal testing, our Proxmox Backup Server Windows client (open source GUI) has just completed its first full production backup on a meaningful volume. The target datastore is hosted with NimbusBackup, a sovereign cloud PBS operated in France — no dedicated line, no special VPN: just HTTPS to a managed Proxmox Backup Server.

Machine profile: a Windows bare metal server of roughly 1 TB, in an SMB / mid-market environment. No identifying information is disclosed — the goal is to capitalize on the actual run figures, not on the end customer.

On the procedural side, the client itself is documented step by step in our Proxmox Backup Client Windows tutorial (install, API token, first scheduler — and if Windows flags the executable on download, it's a false positive); on the infrastructure side, day-to-day operation of the Proxmox cluster pushing these backups is part of our Proxmox managed services.

Why publish these numbers

The market is full of promises ("10× deduplication", "line-rate throughput") and very few concrete measurements. This article documents one real run, what it shows, what it limits, and what it does not yet prove.

Timeline: 20h30 of uninterrupted transfer

The run was triggered overnight by the client's internal scheduler and ran without incident until the successfully finished backup message on the PBS side.

Event	Timestamp (Paris)
Client scheduler starts	2026-04-15 01:30:38
Auto-Split analysis ends	2026-04-15 02:01:00
PBS index creation	2026-04-16 01:40:49
PBS finish (successfully finished)	2026-04-16 22:13:08
PBS transfer duration	20 h 32 min 19 s

The run is an initial full backup: no previous snapshot existed for this group (GET /previous: 400 no valid previous backup). This is the most expensive scenario — everything is transferred, with no benefit from a delta against a previous run.

Volumes processed

Metric	Value
Source size (pxar Size)	876,602,075,764 bytes ≈ 876.6 GB (816.4 GiB)
Total chunks	286,616
Average chunk size	~3.06 MB
Catalog (pcat1)	55.4 MB across 17 chunks

Deduplication and compression: 57 % end-to-end savings

This is where the PBS pipeline pays off, even on a first backup.

Proxmox Backup Server Windows client: 75 % of chunks already known or duplicated

Deduplicated chunks: 215,784 out of 286,616 → 75.3 % of chunks were either already present on the datastore or identified as internal duplicates within the volume.
Unique chunks transmitted: 70,832 (24.7 %)
Unique bytes to transmit: 624.1 GB (71 % of the source) — meaning 252.5 GB saved by dedup (29 %)

Honest reading: on a first backup, the 75 % dedup figure does not come from comparison against a previous backup — there is none. It comes essentially from internal duplicates within the volume (identical files replicated across folders, zero blocks, common headers…). Subsequent runs will additionally hit chunks already present on the datastore.

Compression: 60 % of post-dedup size

On the 624.1 GB of unique bytes to transmit, PBS applies client-side compression before upload (logged ratio: Compression: 60%).

Result on the wire: 624.1 GB × 60 % ≈ 374.5 GB actually transmitted over the network.

Dedup + compression summary

876.6 GB

source

~374.5 GB

on the wire

57.3 %

savings

Average throughput

Source-side read

876.6 GB / 20.54 h

≈ 42.7 GB/h • 11.85 MB/s

Effective network traffic

After dedup + compression

≈ 18.2 GB/h • 5.06 MB/s • 40.5 Mbps

These figures are averages over the entire run. Peaks are likely higher, and individual phases (large contiguous files vs. millions of small files) boost or drag instantaneous throughput. Without fine-grained profiling, we cannot isolate those variations — see "What we cannot yet claim" below.

Resilience proven: 20h30 with no rupture

This run was the 3^rd attempt. The two previous ones had failed:

Attempt 1 (Apr 13): Windows VSS broken, snapshot impossible. Client-side fix applied.
Attempt 2 (Apr 14): extended network outage + lost HTTP/2 session on the PBS side. The client failed cleanly, leaving no orphan snapshot.
Attempt 3 (Apr 15-16): successfully finished backup after 20 h 32 min of continuous transfer.

Several recent GUI client fixes were exercised under real conditions during this run:

Session-lost retry (25 min)

On a lost HTTP/2 session against PBS, the client waits and retries instead of giving up.

H2 keepalive

Keeps the HTTP/2 connection alive during long analysis phases, to avoid silent drops.

Per-directory Finish()

Per-folder validation rather than a single final block, to limit the cost of a late-run failure.

These fixes existed before this run, but had never been exercised on a 20 h continuous window. They have now.

Mechanical bonus: the incremental demonstration

In parallel, another folder on the same machine — much smaller and already backed up over the previous days — was reprocessed on Apr 17 at 01:18. Result:

pxar: 472 bytes (a single chunk, 100 % upload size)
catalog: 72 bytes
Total duration: under one second

Important: this folder is not the large-volume one described above. It is on the same machine but a different backup group. This measurement therefore proves nothing about the future incremental behavior of the large volume — it merely illustrates the PBS mechanism: when a previous snapshot exists and nothing changed, the client re-registers the previous snapshot's chunks and closes the index, with zero unnecessary upload.

Run 2 (Apr 18-19) — Adding Windows ACL support: the regression surfaces

Overnight from Apr 18 to Apr 19, a 2^nd run was launched against the same group with version v0.2.69 of the GUI client (fixes on NTFS ACL upload and on the finalization handshake). The numbers are what you would hope for from an incremental against a near-stable volume — and they surface one last client-side bug.

On an 876 GB Windows dataset, the 2^nd daily backup pushed ≈ 1.2 GB over the wire (vs. 374 GB on day one) — ≈ 310× less traffic for exactly the same volume protected. The PBS dedup promise, verified in production against a real client.

Metric	Run 1 (Apr 15-16)	Run 2 (Apr 18-19)	Run 3 (Apr 19-20)
Source	876.6 GB	876.9 GB	876.9 GB
Chunks	286,616	286,695	286,695
Deduplicated chunks	215,784 (75.3 %)	286,620 (99.97 %)	286,694 (99.9997 %)
Network upload (uncompressed)	624 GB (71 %)	1.73 GB (~0 %)	1.61 GiB (1 chunk)
Duration	20 h 30	14 h 10	9 h 08
NTFS ACLs uploaded	no (regex 400 bug)	yes, 10 MB	yes
`/finish` on PBS	OK	400 (rollback)	OK — snapshot sealed

The pipeline holds: 99.97 % of chunks are recognized as already present on the datastore, real network upload drops to under 2 GB for an 877 GB source volume. The expected incremental ratio is confirmed on this dataset — at least on the chunk / dedup / transfer side.

The last bug: a 400 from PBS on the final /finish call prevented the snapshot from being sealed. PBS will most likely rollback this snapshot, as it did during the 2^nd attempt of the initial run.

What did go through: every piece of content was chunked and deduplicated correctly server-side, the NTFS ACL blob arrived, the catalog and manifest are consistent. Only the final validation is missing. The 876 GB scanned and 14 h of compute are not wasted: the chunks already live on the datastore. The next run, with the corrected /finish, will only replay the source scan and the final call — and will again benefit from the 99.97 % dedup. No full retransmission required.

Another signal: duration falls from 20h30 to 14h10 with the source essentially unchanged. The delta comes mostly from avoided upload time (1.73 GB vs 624 GB); Auto-Split analysis and client-side disk reads remain incompressible costs on this volume.

Run 3 (Apr 19-20) — manifest-csum fix: first sealed snapshot on 1 TB

Overnight from Apr 19 to Apr 20, a 3^rd run was launched with the PBS fix manifest-csum (commit 26025ba), which specifically targeted the /finish 400 from run 2. This time, the UploadBlob path (nimbus-acls.json.gz.blob, index.json.blob) made it through final validation, and PBS sealed the snapshot.

Real 1 TB production volume processed: 876.9 GB source, 9 h 08 min end-to-end, 1.61 GiB actually uploaded, 99.9997 % of chunks deduplicated (one single new chunk), /finish validated, snapshot sealed server-side. The chunk + dedup + upload + final-seal chain is functional on a 1 TB production volume — one last verify-side residue remains to fix (see below).

Run 3 — key numbers

Source: 876,897,205,286 bytes ≈ 876.9 GB (816.7 GiB)
Chunks: 286,695 total, of which 286,694 deduplicated (286,283 global + 411 from the previous snapshot index) → a single chunk actually uploaded
Deduplication ratio: 99.80 % by volume (508:1), 99.9997 % by chunk count
Compression: 71 % on the little data actually sent
On the wire: 1,725,366,850 bytes ≈ 1.61 GiB (metadata + unique chunk + catalog ~52.9 MiB)
Window: 17:54:48 → 03:03:29 (next day) — 9 h 08 min
Breakdown: ~5 min 47 s for register chunks + previous .didx download + scan/chunking; ~9 h 02 min on chunk-by-chunk verification (hash + PBS lookup). The bottleneck is not bandwidth (1.6 GiB in 9 h) but local processing of 816 GiB of source.

This run closes the loop left open on Apr 19: the chunking + dedup + compression + /finish pipeline holds end-to-end on a real production volume of ~1 TB, producing a sealed snapshot server-side. The 26025ba fix on manifest-csum is holding in production.

Engineering journal — regression introduced by the ACL feature. The chronology matters to read these runs correctly:

Run 1 (Apr 15-16, no ACL support): /finish OK and verify OK ✅ — the "sealed snapshot" and "20h30 resilience proven" claims hold without reservation.
Runs 2 & 3 (Apr 18-20, with ACL): adding the Windows ACL sidecar nimbus-acls.json.gz.blob surfaces a constant −12 byte wrong size at verify time (10,019,169 vs 10,019,181; 251,472 vs 251,484; 908,386 vs 908,398). Those 12 bytes exactly match a PBS DataBlob header (8-byte magic + 4-byte CRC32). /finish passes, but PBS marks these snapshots as corrupted until verify passes.
Next run: targeted fix on the ACL blob write path (align the manifest-declared size with the actual payload size, header included). Re-verify to be validated in production.

Honest reading: this is not a bug in the backup per se — the chunk / dedup / upload / /finish chain holds on 1 TB (proved by Run 1). It is a functional regression introduced by a new feature (Windows ACL support, a differentiator vs. Veeam), on a specific code path (sidecar write), well localized. This article will be updated once the post-fix run passes verify.

What we cannot (yet) claim

Three points deserve to be stated openly:

Snapshots carrying the Windows ACL sidecar do not yet pass verify. Run 1 (no ACL) passes verify OK; Runs 2 & 3 (with ACL) have their /finish sealed but verify KO on the ACL blob write path (12 B regression, see engineering journal above). An end-to-end restore of an ACL-bearing snapshot is therefore not yet trusted. Fix in progress, post-fix run pending.
Per-variable bottlenecks (client CPU, source disk I/O, PBS client version, TLS negotiation, network latency) are not isolated here. Average throughput is measured but not attributed.
Representativeness: a run on a "business data" volume says little about a run on an active SQL database, on a folder of millions of small files, or on highly entropic data (already-compressed video, application-encrypted archives).

Planned follow-up

Detailed profiling (CPU, I/O, PBS client version) could not be performed in the context of this test. An internal lab will be the subject of a follow-up article to isolate bottlenecks per variable on controlled datasets (large files, small files, entropic data, open databases).

Takeaways

✅ The Windows GUI client sustains a 20h30 continuous transferwindow without rupture on a near-1 TB volume.
✅ On a first backup, we already observe 57 % end-to-end savings thanks to in-volume dedup + PBS compression.
✅ The recent network fixes (session-lost retry, H2 keepalive, per-directory Finish) proved themselves in production on a long run.
⚠️ Average throughput (~5 MB/s effective on the wire, ~12 MB/s source-side read) is measurable but not yet attributed — bottlenecks will be isolated in a dedicated lab.
✅ The 2^nd run (Apr 18-19, client v0.2.69) measures 99.97 % deduplicated chunks and 1.73 GB of effective upload on 877 GB of source — the expected incremental ratio is confirmed on this dataset.
✅ Run 3 (Apr 19-20): first sealed snapshot in production on a real ~1 TB volume. 9 h 08 min, 1.61 GiB uploaded, 99.9997 % chunks deduplicated (a single new chunk), /finish validated. The manifest-csum fix (26025ba) holds.
✅ Run 1 (no ACL) passes PBS verify cleanly — the pxar + chunks + final-seal chain is integrity-checked end-to-end on 1 TB.
⚠️ Runs 2 & 3 (with ACL support): verify KO on the sidecar nimbus-acls.json.gz.blob with a constant −12 B delta = PBS DataBlob header (8 B magic + 4 B CRC32). PBS marks these 3 snapshots as corrupted. Functional regression introduced by the ACL feature, well localized — the main chain (pxar + chunks + /finish) is not implicated. Fix in progress.

Natural next step once the snapshot is stabilized: setting up PBS push/pull replication to a second datastore — moving from a single backup to a real 3-2-1 architecture. That is the run scheduled right after this one.

What about Veeam?

Compared to a standard Veeam agent on the same volume profile, the PBS pipeline plays on a different plane: no ingest into a proprietary repository, no synthetic full to replay, no per-socket licensing. The traffic savings observed here (57 % on run 1, ~310× less on run 2) come from client-side dedup and stable PBS chunking. Veeam reports comparable ratios on forever-forward jobs, but behind a very different commercial model and restore chain.

The detailed breakdown is in our Proxmox Backup Server vs Veeam comparison — compression, dedup, cost per TB, granular restore.

Going further

The Windows GUI client for PBS (main article)

The article presenting the open source client used for this backup, with the installation and configuration guide.

Read the article

Create and manage your PBS API tokens

The authentication prerequisite used by the GUI client: one token per machine, independently revocable.