Replication Bandwidth Calculator

Size the link for site-to-site or cloud replication from how much data changes each day and the RPO you need to hold.

Inputs

Protected data

Everything you replicate: the initial seed sends all of it once.

Data change per day

The data written or overwritten in a day that replication has to send. Your backup or replication software reports it; the size of a daily incremental backup is a close stand-in.

Recovery point objective (RPO)

Peak-hour factor

How much faster data changes in your busiest hour than the 24-hour average. 1 means changes are spread evenly. If half the day’s changes happen across an 8-hour business day, the factor is at least 1.5 (50% of the change in a third of the day); batch jobs and nightly loads push it higher. Replication reports show your real peak.

Compression ratio (n:1)

Compression or WAN optimization applied to the replication traffic. 1 means none. Already-compressed or encrypted data hardly shrinks.

Link efficiency

The share of the link that carries replicated data after protocol overhead. 90% is a planning assumption.

Your replication link (optional)

The bandwidth you can give replication. Needed for the seed time.

Seed by shipment: time to ship and load (optional)

Copying the data to a drive or appliance, shipping it and loading it at the target, end to end. The changes made meanwhile still cross the link afterward.

Result

Enter the protected data, the daily change and the RPO to see the bandwidth you need.

Related Tools

Backup Restore Time Calculator
Find out how long it would take to get all your data back from backup, and whether that meets your recovery time target.
RPO and RTO Calculator
Set how much data and time you can afford to lose for each system, and see what kind of protection that takes.
Backup Storage Calculator
See how much storage your backup retention policy needs and what it will cost each month at your quoted prices.
Uptime and SLA Calculator
See how much downtime an uptime percentage really allows, and what an outage is worth in SLA credits.
Data Transfer Time Calculator
Find out how long it will take to move your data over a network link, or how fast a link you need to hit a deadline.

How the calculation works

The model in one sentence: to hold the RPO, the changes made in the busiest RPO-length window have to cross the link within that same length of time.

Daily change sent = daily change ÷ compression ratio. A percentage is taken of the protected data.
Average change rate = daily change sent × 8 ÷ 86,400 seconds.
Busiest RPO window factor depends on the RPO (R, in hours) and the peak-hour factor (p): for an RPO of an hour or less it is p; for a longer RPO the window holds the peak hour plus R − 1 average hours, so the factor is (p + R − 1) ÷ R, never more than a whole day’s change and never below 1. From a 24-hour RPO the average is enough.
Short RPOs: the peak-hour factor describes a whole hour, so for an RPO under an hour the result assumes changes are even within that busiest hour. Bursts shorter than an hour, such as a database load that writes for ten minutes, need more; if your tools report change per minute or per RPO interval, use that peak as the factor instead.
Link needed = average change rate × window factor ÷ link efficiency. This is the minimum sustained rate; it doesn’t add headroom for growth or for catching up after an outage.

Initial seed = protected data ÷ compression ratio × 8 ÷ (your link × efficiency − average change rate). The link has to carry the changes that keep arriving while the seed runs, so only the capacity left over goes to the seed. If nothing is left over, the seed never finishes.

Seed by shipment = your shipping time + the time to send the changes made while the data was in transit, again over the spare capacity.

Units. Decimal sizes use powers of 1,000 (1 TB = 10¹² bytes); binary sizes use powers of 1,024 (1 TiB = 2⁴⁰ bytes). Link speeds are decimal (1 Mbps = 10⁶ bits per second).

The peak-hour factor and the compression ratio are yours to enter; the defaults (1 and 1) assume changes spread evenly and no compression, which understates the bandwidth for most busy systems.

Worked example

20 TB protected, 3% a day, 2:1 compression, a 15-minute RPO and a peak-hour factor of 3:

Daily change: 3% of 20 TB = 600 GB; 300 GB a day is sent after compression
Average rate: 300 × 10⁹ bytes × 8 ÷ 86,400 s = 27.78 Mbps (3.472 MB/s)
The RPO is under an hour, so the window factor is the peak factor, 3, assuming changes are even within the busiest hour: 27.78 × 3 = 83.33 Mbps of data
At 90% efficiency the link needs at least 92.59 Mbps sustained

The initial seed over a 200 Mbps link: 180 Mbps of data capacity, less the 27.78 Mbps of ongoing change, leaves 152.22 Mbps for the seed. The 10 TB seed (20 TB ÷ 2) is 8 × 10¹³ bits, which takes 525,547 seconds, about 6 days 1 h 59 min.

Seeding by shipment in 4 days: the changes made meanwhile (4 days at 27.78 Mbps) take about 17.5 hours to send afterward, so the total is about 4 days 17 h 31 min, faster than the network seed by about 1 day 8 h 28 min.

With a 4-hour RPO instead, the window holds the peak hour plus three average hours: (3 + 4 − 1) ÷ 4 = 1.5 times the average, so the link needs 46.3 Mbps, half as much.

Frequently Asked Questions

Why does a short RPO need more bandwidth than the daily average?

Data doesn't change at an even rate. With a 15-minute RPO, the changes from your busiest 15 minutes have to cross the link within about 15 minutes, so the link has to keep up with the peak, not the day's average. For RPOs under an hour, measure the peak over the RPO interval if you can: an hourly figure hides shorter bursts. A long RPO lets replication spread a busy hour's changes over the quieter hours around it.

How do we find our daily change rate?

Your backup or replication software usually reports it: the size of each daily incremental backup is a close stand-in, and replication tools often show change per hour. Look at a few weeks, including month-end or other busy periods, and use a high day rather than the average.

What is the peak-hour factor?

It's how much faster data changes in your busiest hour than the 24-hour average. 1 means changes are spread evenly across the day. If half a day's changes land within an 8-hour business day, the busiest hour runs at least 1.5 times the average; nightly batch jobs, database maintenance and backups of their own can push it much higher. Hourly change reports show the real figure.

What happens if the link is smaller than the result?

During busy periods replication falls behind, and the copy at the recovery site gets older than the RPO until traffic quiets down and it catches up. If the link can't even carry the daily average, it never catches up. Compression, WAN optimization, a longer RPO for some systems or a bigger link are the usual fixes.

Why can the initial seed take longer than the data size suggests?

While the first full copy crosses the link, the data keeps changing, and those changes have to be sent too. The calculator only counts the link capacity left after the ongoing changes, so on a busy system a link that looks big enough can take much longer, or never finish. Seeding by shipment avoids most of the transfer but still leaves the changes made meanwhile to send.