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.