Benchmark summary
The three numbers that matter most
First full backup
260.65s
Our one honest loss: the incumbent finished its first full backup faster, at 138s. It's a one-time cost — every backup after it is where XReplicator pulls ahead.
Clean incremental
10.97s
More than 2x faster than the 26s baseline — every incremental after the first counts.
Small change in a large file
17.64 MB
For a 4 GiB file, versus 4.35 GiB shipped by the baseline — that's 99.6% less data over the wire.
Azure DR failover benchmark
From disaster to running VM in under a minute
Attach staged disks as-is
Under 40 seconds
Recovered Azure VM creation after healthy staged DR disks were already synced.
Create disks from snapshots
Around 70 seconds
Recovered Azure VM creation using isolated snapshot-derived disks.
How we ran the drill
No cherry-picking here — this is the exact setup behind the number. Change the workload, readiness state, region, or success criterion and the result will move, so run it your way and see what you get.
- Workload
- One Azure VM with a 30 GB operating-system disk and a 4 GB data disk.
- Readiness
- DR sources were healthy and staged disks were synced before failover.
- Measured event
- Time to create the recovered Azure VM through the selected blueprint path.
- Product path
- XReplicator v1.3.1 Azure-to-Azure DR orchestration.
What that clock actually measures
The published number is recovered VM creation through the selected XReplicator Azure DR workflow, once staging was ready to go.
What your real-world RTO also needs to cover
Azure control-plane response, capacity, operating-system boot, networking, identity, DNS, application startup, and business validation. Budget for these — we do.
Server backup benchmark
Same VM. Same workload. We put it head-to-head anyway.
Every row below is a side-by-side run against a controlled enterprise backup-tool baseline — CPU is average / maximum, RSS is the maximum observed agent process resident memory, and wire TX is measured on the protected VM. It's a point-in-time lab result, not a claim about every version, configuration, or workload — so judge it on the numbers, not the label.
Fresh full
XReplicator used less average CPU; the baseline completed the first full faster.
Full measurements
- Logical / payload: XReplicator 25.75 GiB / 16.56 GB; baseline 19.1 GB / 16.1 GB
- CPU avg / max: XReplicator 21.17% / 63.66%; baseline 34.39% / 77.49%
- Max RSS: XReplicator 3.66 GiB; baseline 717 MiB
Clean 1 GiB incremental
XReplicator completed faster and processed only the changed scope in the measured CBT case.
Full measurements
- Logical / payload: XReplicator 1.50 GiB / 1.025 GB; baseline 17 GB / 1 GB
- CPU avg / max: XReplicator 2.47% / 50.35%; baseline 24.34% / 41.01%
- Max RSS: XReplicator 2.43 GiB; baseline 492 MiB
Small change in a large 4 GiB file
Client-side content deduplication kept existing content off the wire; the restored file checksum matched.
Full measurements
- Logical / payload: XReplicator 4.01 GiB / 17.64 MB; baseline 4 GiB / 4.35 GiB
- CPU avg / max: XReplicator 25.51% / 31.81%; baseline 25.53% / 43.68%
- Max RSS: XReplicator 2.59 GiB; baseline 683 MiB
Don't take our word for it — run it yourself
Get the complete drill, every variable, and the full validation sequence — everything you need to reproduce this before you set your own internal RTO.