Disaster Recovery

Get ready for legacy systems' disaster recovery complications

This tip gives you some issues to think about in planning for the recovery of legacy applications.

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

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

0 comments