Log Shipping Bandwidth Calculator

Log shipping can also fail, but usualy without fanfare or screaming red alarms. You just wake up to discover that your replica database hasn’t been refreshed in the last four hours, due to WAN link being jammed by unexpected backup traffic. Or maybe your SIEM collector drop events while running a security scan, thinking that the pipe was going to remain open. Log shipping bandwidth planning is an abstract concept until the pipe chokes.

So plan for worst-case scenario, the peak burst rate, to see if your link will survive in real world. To get a number, most admins begin by figuring out how many megabits per second they needs on average to transport their day’s worth of log volume. That provides a reassuring baseline. But it fails to take into account that log traffic doesn’t behave as if it’s water in a pipe flowing steady.

Plan for Peak Burst Traffic, Not Just Average Use

It comes in chunks. Your database writes out a chunk, compresses it, then ships it off all at once when it hits its shipping interval. You’re pushing PostgreSQL WAL files every five minutes? The network see a 5-minute spike every five minutes, then nothing. The calculator above will crunch the numbers and tell you how those spikes is different than your available link capacity.

Compression: Don’t count on any maximum theoretical value; text-heavy application logs and JSON audit trails can often shrink by 80 percent or more. Binary logs or encrypted traffic get little or no compression. This is one you should of tweaked the tool with after seeing how much it actualy compresses in your own environment. Under-estimating compression is better than over-estimating it.

Little or no compression for binary logs or encrypted traffic. This is one you can tweak the tool with after seeing how much it actualy compresses in your own environment. Under-estimating compression is better then over-estimating it. Protocol acknowledgements and encryption overhead add a few percent to each packet with TLS wrapping. Handshakes from synchronous replication modes consumes part of your transfer window. These little things add up fast when you’re trying to get a big batch through a small time slice.

Most designs breaks at peak. Your peak burst is ninety percent of your link’s capacity. Any small amount of background traffic or jitter will push you over the edge and time out with a retry. The table in the reference on the page make it clear: You want to stay under seventy percent peak to have some headroom for unexpected surges.

And if you’re increasing number of destinations (for example, replicating to several region for compliance), then you’re multiplying the required bandwidth. Fan-out is handled automatically by the tool, but understand that every destination receiver require a slice of pipe.

This is sometimes called catch up / retrieval time, but nobody ever thinks about that until it’s broken. The calculator looks at your spare capacity (beyond your normal traffic) and calculates how quickly it will empty out the backlog if your sender gets behind. That tells you whether you have a short catchup time; in which case you’ll be able to survive some small hiccup of your network without violating your recovery point objectives or losing any data correctness. Or does it indicate you should increase your retention buffer on the sender side because otherwise too much will get deleted from older logs before they make it to their destination?

Don’t guess if your link is big enough, design for those moments that actualy matter. Know the difference between average flow and burst pressure. Run real samples through your compression ratios. Compare your peak multipliers against past busy hour. Make sure your intervals gives you time for batches to clear out before the next comes in. Don’t let log shipping use whatever leftover capacity is available after your users’ queries are done. Treat it as critical application traffic that deserves its own capacity reservation.