Bandwidth planning for disaster recovery systems

by Mike Talon | Mar 28, 2005 8:00:00 AM

Tags: Mike Talon, bandwidth, disaster recovery, Disaster Recovery Newsletter

Takeaway: Don't forget to evaluate your disaster recovery system for bandwidth needs. This tip tells you what factors are important, and how you can prepare for the needs of your particular environment.

How well can your organization deal with an emergency? Automatically sign up for our free Disaster Recovery newsletter, delivered each Tuesday, and make sure you're prepared for the next catastrophe.

Bandwidth is always an issue in disaster recovery, even if you're not planning to send data between sites. If you're using only tape devices, then your bandwidth concerns are limited. If you're replicating data for potential failover—both locally and remotely—then your bandwidth issues become more complicated. So how do you prepare for the bandwidth you will need?

Locally, your concerns are going to revolve around not crowding out your local users in order to maintain your DR strategy. For example, LAN-based backup tools will usually offer compression options, but still utilize a dramatic amount of bandwidth across the local network during operations. This means that you will most likely want to put in a backup network that is local-only in order to allow that traffic to flow without chewing up the available bandwidth your end users need. At the very least, you'll want to perform backups only when there are very few, if any, users on the network.

If you're performing replication, your bandwidth needs increase proportionally to the type of system you're using. Hardware systems require dramatically more bandwidth than software systems on the whole, and both use differing amounts of bandwidth dependent on what they're being used for.

Hardware systems require either direct fiber or SCSI connectivity between the disk systems locally, and generally require channel-extension hardware that uses a great deal of network bandwidth to perform over longer distances. You will absolutely need to plan ahead and ensure the proper amount of bandwidth prior to installing these systems, as lack of available network space can quickly slow your production systems to a crawl for real-time replication systems. For point-in-time copy systems, failure to adequately spec out bandwidth needs will result in the replication taking longer than 24 hours to complete in many cases—leaving you with a wholly inadequate system for recovery.

Software-based systems tend to use dramatically less bandwidth, but that doesn't mean you can ignore this factor. While most software systems won't slow down your production machine significantly if the bandwidth gets choked, they will start to buffer and/or queue data on your production servers until it can be transmitted. If this is a short-term bottleneck, then you will catch up, but if you're constantly faced with less bandwidth than you need to protect the data, you'll be constantly latent and therefore have DR systems that are running behind the production servers. This is generally not a prohibitive issue when it comes to failover, but it does mean that you'll lose the data that hasn't made it across the wire yet.

How much bandwidth you need differs in each environment, but most of the solutions providers that offer these systems can help you to determine exactly how much pipe you'll need for a given set of servers. Many can even assist in finding the best trade-off between bandwidth and latency so that you can protect your data without breaking the bank on monthly charges. In any case, overlooking bandwidth, either locally or across a WAN, can easily lead to a DR solution that simply won't function.