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
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.