Replication Bandwidth Calculator for RPO and WAN Link Sizing
Estimate the WAN bandwidth needed to keep replication inside a target RPO. Use protected data size, change rate, compression or dedupe reduction, protocol overhead, link efficiency, headroom, and catch-up backlog to size steady-state and post-outage replication capacity.
Inputs
Results
Core formulas: wire bps = raw change bps x (1 - reduction) x (1 + overhead),
required WAN = wire bps / (efficiency x WAN share) x (1 + headroom), and
data at risk = raw change rate x RPO.
Advertisement
How to use this replication bandwidth calculator
- Measure change rate. Prefer storage, hypervisor, database, backup, or replication reports over guessing from total dataset size.
- Set the RPO target. RPO is the acceptable recovery-point age. The calculator uses it to estimate data at risk and tolerance for replication lag.
- Model the WAN realistically. Efficiency, WAN share, overhead, and headroom prevent the estimate from assuming the whole advertised link is available.
- Check catch-up behavior. Replication must handle normal changes and clear outage backlog. Catch-up sizing is often higher than steady-state sizing.
- Validate with a test. Real replication depends on latency, packet loss, write pattern, encryption, application consistency, snapshots, and vendor limits.
Methodology and assumptions
RPO is commonly defined as the maximum acceptable age of recovered data after a disruption. This calculator treats
RPO as a lag tolerance and estimates source-side data at risk as raw change rate x RPO. For continuous
replication, steady-state bandwidth is primarily driven by the ongoing change rate; a tighter RPO mostly reduces
the amount of queued lag you can tolerate and makes burst handling more important.
Network rates are modeled with decimal bit-rate units such as Mbps and Gbps. The calculator separates raw changed data, reduced replicated payload, wire traffic after overhead, and nominal WAN bandwidth. It assumes a steady average rate and does not model TCP slow start, packet loss recovery, latency windows, storage I/O limits, snapshot stun time, journal retention, or application write bursts.
Example planning scenarios
| Scenario | Useful inputs | Planning note |
|---|---|---|
| VM replication between sites | Protected TB, daily changed blocks, async RPO target, WAN share | Measure changed blocks during peak business periods, not only daily averages. |
| Database replica over WAN | Log generation per hour, compression, latency-aware efficiency, catch-up window | Transaction log spikes can dominate RPO even when daily totals look modest. |
| Post-outage catch-up | Paused replication duration, queued backlog, desired catch-up hours | The link must carry new writes and clear old backlog at the same time. |
| Shared WAN with QoS | WAN share below 100%, headroom, realistic efficiency | Use the bandwidth actually allocated to replication, not the provider circuit size. |
FAQs
Why does the calculator ask for protected data size?
Protected size is needed when you express change rate as a daily percentage. If you already know changed GB per hour or day, use explicit change-rate mode.
Is RPO the same as replication bandwidth?
No. RPO is the data-loss time objective. Bandwidth is one input that helps maintain replication lag under that objective, alongside latency, software behavior, storage speed, and operational procedures.
Should I use average or peak change rate?
Use peak or high-percentile change rate for production sizing. Averages can understate write bursts, patch windows, index rebuilds, backups, and batch jobs.
How should I set compression or dedupe reduction?
Use measured replication statistics where possible. If unknown, start conservative because encrypted, compressed, or media-heavy workloads may not reduce much.
What if the available link is below steady-state required bandwidth?
Replication lag will grow during normal operation, so the target RPO is unlikely to hold without a larger link, lower change rate, stronger reduction, different scheduling, or tighter QoS.
Is this calculator private?
Yes. It runs locally in your browser and does not submit inputs to a server.
Disclaimer
Use these results for planning and comparison. Validate production replication designs with measured change rate, vendor documentation, packet-loss and latency tests, recovery drills, and business continuity requirements.