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.
Into the life of every organization more than
a few years old, you will find at least a few applications that are
either seriously outdated, or are just plain not made and/or
supported anymore. These legacy applications can pose some
interesting and often unique challenges to your disaster recovery
(DR) planning process. Most of these issues–but by no means
all–can be tied to typical legacy complications such as
configuration issues with the software, licensing issues, and
client connectivity issues.
Configuration issues may come into play when
you attempt to design systems in your DR data center that can
support recovery of legacy systems in the event of an emergency.
Many older software tools require massive amounts of customization
that cannot be easily moved from one server to another via
configuration files. This can make the very setup of these software
systems on other hardware difficult if the settings are mainly
static. Setup can prove nearly impossible if the configuration
changes on a regular basis.
In addition, many applications are designed to
run on certain types of hardware or certain hardware configurations
only. This can make failover for these systems difficult if the
same hardware cannot be acquired for one reason or another. In
these cases, you may only be able to protect the data and restore
it to newly configured hardware and systems in the event of a
disaster. While you can use many tools to limit the amount of data
lost to a disaster, your recovery time will be limited by the
flexibility of the legacy systems in question.
Licensing can be another issue altogether. Just
because a software company no longer makes or supports a particular
type of software doesn’t mean you aren’t still bound by the legal
ramifications of using more copies of the software than you have
licensing for. You may no longer be able to obtain the licensing
required to properly set up DR data systems, leaving you with only
one facility that utilizes this software. Once again, you can
always protect the data via tape, replication systems, and other
tools, but that hinders your ability to recover quickly since you
will have to reinstall the software to new machines if the original
data systems are lost or rebuilt.
Finally, many legacy systems can easily
prohibit your ability to move them from one datacenter to another.
One example is software systems that have IP addresses hard-coded
into their client-side software and utilities. This would make it
impossible to failover to a DR data center that existed on another
IP subnet–which is the more prevalent method of configuration in
data center operations today.
You can, of course, stretch subnets with
bridging, Virtual LAN (VLAN), and other routing technologies. This
can overcome many of these issues, but only at a generally high
price. These technologies don’t come cheap, nor does the expertise
required to install and maintain them. However, by implementing
these technologies you can create failover systems that go beyond
simple disaster recovery and into the realm of high
Legacy applications and systems cannot always
be removed or replaced. In many cases they cannot even be upgraded
to overcome the DR issues they present. Sometimes, the best you can
do is protect their data and prepare to rebuild, but many times you
may be able to find the hardware, software, and other systems
required to go beyond recovery for the most critical of these