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.While a great deal of attention is paid to servers and software during disaster recovery (DR) planning, DR planners often overlook the networking that will be used to carry their data and connect their users during both normal and DR operations. Most technology professionals realize that bandwidth is needed to create a DR plan, but there are two general areas that are often neglected when dealing with networking and DR planning.
First, during normal business operations, you will need to properly size and configure bandwidth between your primary facility and your DR operations system, whatever and wherever that may be. Even if you are only doing tape backup, and intend to restore data after a disaster, you will still need to consider bandwidth for use in monitoring the DR center and pre-configuring VPN and other remote access.
If you are doing any form of replication or nightly data push to a DR facility, you will need to prepare for the extra data that will go across you existing pipes, or create new links to the DR center for the express use of the DR replication systems. Depending on what systems you are using in your primary facility, you will almost certainly need a great deal more bandwidth than would be used for normal operations of your business. Especially in the case of enterprise-level operations that require regular maintenance of their databases, you may find that you experience large spikes in replication traffic that will have to be sent to your DR site eventually.
While most tools for DR solutions that move data in real-time or near real-time allow for some form of buffering for traffic spikes, you will still need to be able to spool out the buffers at some point, or risk falling permanently behind your production systems in terms of live data. Hardware-based synchronous replication systems make sure that each data transaction is performed on the DR machine before it is applied to the production machine, so while there can be no traffic spikes in these types of systems, you will need to allocate a sufficiently large pipe to the system to avoid dramatically slowing down the production systems as they wait for each transaction to occur at the DR site and return.
Secondly, post-disaster, you will also need to deal with networking issues. First and foremost, there is the issue of routing end users to the newly functioning data centers. If only the data systems at the production site are lost or unreachable, then you will need to dynamically move connectivity for those users still at that site to regain access to the newly brought online systems at the DR site. This could be as simple as redirecting connections via a VPN, but it may mean having additional data connections available to take over for failed lines.
In addition to concerns at the primary site, you will need to make arrangements for connectivity from alternate sites as well, in the case of a loss of all functions at your production facility. This generally comes down to allowing for VPN and other remote access from various facilities and locations for key members of your staff—which usually need to be put into place well ahead of the disaster.
While protection of the data and data systems is perhaps the most important aspect of DR planning, you must not forget the networking solutions that go hand-in-hand with these systems. Failure to protect the networks and plan for their proper use can easily result in perfectly functioning DR systems that no one can talk to at all.