Replication bandwidth for disaster recovery: calculating Mbit/s from change rate and RPO

How to calculate replication bandwidth for disaster recovery

The bandwidth a replication link needs is the amount of data one replication run transfers, after compression, divided by the length of the interval. Take that amount from the busiest run, not the daily average, and add headroom for other traffic. Broadcom’s vSphere Replication documentation for VCF 9.1 (updated 9 October 2026) assumes that “only about 70% of a link is available for traffic replication”.

As a formula with the units written out, Mbit/s = GB × 8000 ÷ s ÷ 0.7, where GB is the data transferred in the busiest run in decimal gigabytes, s is the interval in seconds and 0.7 is Broadcom’s usable share of the link. A run that transfers 10 GB within a 15-minute interval (900 seconds) therefore needs 10 × 8,000 ÷ 900 ÷ 0.7, or about 127 Mbit/s.

Broadcom’s procedure “Calculate Bandwidth For vSphere Replication” derives the change rate within the RPO, then asks you to “Calculate how much traffic this data change rate generates in each RPO period” and to “Measure the traffic against your link speed.” In our reading the method fits Veeam replication as well, since Veeam’s Best Practice Guide names the change rate and the RPO target among the factors replication bandwidth depends on. How to set the RPO for each tier of systems is covered in our guide on choosing RPO and RTO.

Inputs for the calculation and how to measure them

Broadcom TechDocs, VCF 9.1, Bandwidth Requirements and Calculate Bandwidth For vSphere Replication (updated 9 October 2026); Broadcom KB 317503; Veeam Backup & Replication Best Practice Guide, Replication jobs and WAN Acceleration pages.

For Veeam, the Best Practice Guide states that “Replication bandwidth estimation has always been a challenge because it depends on multiple factors”. It suggests a backup job “having the same settings as the replication job” as a test, because “the backup job will transfer the same amount of data as the replication job”, and says Veeam ONE “may help with estimating change rates”. Run that test job at the interval you plan, because a nightly incremental shows the blocks changed in 24 hours, not those of a 15-minute run.

Only the protected VMs count. Broadcom’s KB 317503 gives the example of 2 TB of VMs with half of them protected, so at most 1 TB to replicate. Broadcom’s vSphere Replication Calculator at vcf.broadcom.com, written for vSphere Replication 8.5, takes the VM count, disk size and utilisation, compression, the daily change rate, the largest change burst and the RPO, and solves for bandwidth, RPO or the number of VMs.

Size for the peak change rate, not the daily average

Change rates follow the working day and the batch schedule. Broadcom’s bandwidth page notes that the change rate “might vary throughout the day, which alters the traffic that vSphere Replication generates at different times”. Its procedure starts from the average change rate within the RPO; for a link that has to hold the RPO at the busiest time of day, we size from the busiest run. Database maintenance, month-end closing and software rollouts can write far more blocks in one hour than an average hour does.

A link sized for the daily average falls behind at the peak: the run outlasts its interval, the next run starts late, and the replica grows older until the load drops. Collect per-run statistics over a full business cycle, month-end included.

The daily total can also mislead in the other direction. Broadcom’s KB 317503 explains that vSphere Replication sends a changed block once, in its state when the bundle for transfer is created, and “only registers that the block has changed within the RPO period, not how many times it changed.” A storage counter that sums every write therefore overstates what replication sends, and the KB calls the average daily change rate “a high watermark rather than a realistic estimation”.

15-minute or hourly replication interval

A shorter interval does not reduce the bandwidth you need. Each run sends every block that changed since the previous run, so a block that is rewritten all day travels once per run. Broadcom’s KB 317503 notes that “If you set an RPO of 1 hour, replication occurs 24 times per day”, so such a block can travel up to 24 times a day, and by the same arithmetic up to 96 times at 15 minutes. An hourly run also absorbs short bursts, while a 15-minute run carries its burst within 900 seconds.

Our arithmetic: GB × 8,000 ÷ interval in seconds ÷ 0.7, data per run after compression in decimal GB (10⁹ bytes), link in Mbit/s (10⁶ bits per second); 0.7 is the usable share Broadcom’s vSphere Replication documentation assumes.

Broadcom’s procedure gives about 3 hours for 100 GB on a 100 Mbit/s link, in line with this rule: the link moves 45 GB per hour at line rate and about 31.5 GB at 70%.

The interval also sets how old the replica can get. By our arithmetic, a run’s restore point reflects the moment the run started and is usable once the transfer completes, so just before a run completes, the newest usable point is one interval plus that transfer time old. If the busiest run fills the whole 15-minute interval, the replica can be close to 30 minutes old at that moment. Sizing the busiest run to finish in half the interval doubles the bandwidth from the table, and the RPO tier decides whether that is needed.

Worked example: 800 VMs replicated to a recovery site

This example is ours, and every input is an assumption. A company with 1,500 VMs replicates the 800 VMs of its critical and important tiers, with 60 TB of used data. We assume 3% of that data changes per day (the default value in Broadcom’s calculator, not a measurement), counted as what the runs transfer before compression. We assume the busiest 15-minute run carries three times the average run and the busiest hourly run twice the average hour. We assume compression halves the data; your job statistics show your own ratio.

Worked example with assumed inputs; method from Broadcom’s Calculate Bandwidth For vSphere Replication (TechDocs, VCF 9.1, updated 9 October 2026); arithmetic ours: GB × 8,000 ÷ seconds, then ÷ 0.7.

At the 15-minute interval, 28.1 GB is about 225,000 Mbit. Spread over 900 seconds that is 250 Mbit/s, and divided by 0.7 the link needs about 357 Mbit/s. Sizing from the daily average would give 9.4 GB per run and about 119 Mbit/s, a third of that. The hourly column keeps the 15-minute daily total, which overstates it slightly, since blocks rewritten within the hour are sent once.

Our disaster recovery service replicates virtual machines with Veeam from a 15-minute interval to a recovery site in Baltneta’s Tier-3 data centres in Lithuania. Send us your VM count, used capacity and the change rate per run through the form below.

Units in the calculation: bits, bytes, GB and GiB

Links are rated in bits per second with decimal prefixes, so 1 Mbit/s is 10⁶ bits per second. One byte is 8 bits, so one decimal gigabyte (10⁹ bytes) is 8,000 Mbit. A 1 Gbit/s link therefore carries at most 125 MB per second, or 450 GB per hour at line rate.

Some reports count in binary units. NIST’s page on binary prefixes defines “1 GiB = 2³⁰ B = 1 073 741 824 B” against “1 GB = 10⁹ B = 1 000 000 000 B”, so a gibibyte is about 7.4% larger than a gigabyte. In the worked example, 28.1 GiB per run instead of 28.1 GB raises the link from about 357 to about 383 Mbit/s, so check which unit your job statistics use.

Seeding the first copy, WAN acceleration and throttling

The first run copies the whole VM and is the largest transfer of the project. On the example’s link of about 357 Mbit/s, of which 250 Mbit/s is left for replication, 60 TB of used data takes about 22 days before compression, by our arithmetic (4.8 × 10¹⁴ bits ÷ 2.5 × 10⁸ bits per second, about 1.9 million seconds). If compression halves it as assumed above, about 11 days remain, and the next run then carries the blocks changed while the first copy was running.

Veeam’s Best Practice Guide lists replica seeding, replica mapping, WAN acceleration and replica from backup for off-site replication, as mechanisms that “reduce the amount of replication traffic”. How seeding and mapping start the first run from data already at the DR site is covered in our comparison of Veeam replication vs backup copy. The guide notes that “WAN Accelerators can help replication jobs fit into allowed windows when bandwidth is not sufficient”. Its design page recommends low bandwidth mode “for the links with less than 100Mbps throughput” and direct mode with high compression above 100 Mbit/s. High bandwidth mode remains for high-bandwidth links with latency above 100 ms and for workloads with a daily change rate above 10%. The guide gives no fixed saving, so measure it with a test job.

For replication to a remote DR site, the guide adds that “you can also manage network traffic by applying traffic throttling rules”. The throttled rate has to stay above the busiest run’s throughput, or the replica falls behind.

Part of the technical assessment in our disaster recovery service is a review of the infrastructure, the DR strategy and site sizing. Tell us how much data the first copy would carry and which link connects your sites today.

Encryption, latency and other traffic on the link

Our recovery site receives Veeam Cloud Connect replication over an encrypted TLS/SSL channel, and Veeam’s Best Practice Guide suggests in-transit encryption whenever traffic between Veeam components crosses untrusted networks. Neither vendor document we read gives a figure for the volume encryption or protocol headers add, so run the test job with encryption enabled and keep the 70% assumption until your own figures replace it.

Broadcom’s 70% is the share of the link it expects replication to reach. If backup copy jobs, user traffic or management traffic share the link at the same hours, subtract their throughput before you apply it. Broadcom’s KB 317503 adds that with network-based storage “Each piece of replicated data travels over the network several times”, a concern mainly when replicating within a single vCenter Server instance on a shared network. Distance and latency, which can lower replication throughput, are covered in our article on how far a DR site should be.

NIST SP 800-34 Rev. 1 lists “WAN/VLAN replication” among backup options for moderate-impact systems in its Table 3-2. vSphere Replication licensing is covered in our guide to VMware Live Site Recovery after Broadcom, and the compute and storage of the recovery site in sizing a DR site.

What we do

Under our disaster recovery service, our engineering partner Vixen.UNO designs the DR strategy with you: critical systems, target RPO and RTO for each tier, and the disaster scenarios you protect against. Virtual machines replicate with Veeam from a 15-minute interval via Veeam Cloud Connect, over an encrypted TLS/SSL channel, to a recovery site in Baltneta’s Tier-3 data centres in Lithuania (ISO 27001, PCI DSS). You manage replication from your existing Veeam console, or we manage it entirely on our side. Scheduled failover tests run in an isolated environment, with a report after each on what came up, how fast and what to fix. Site, replication, tests and support come on one EU contract and invoice from Eurokommerz.

FAQ