Custom applications are the bane of every Disaster Recovery
(DR) professional I know. These applications are almost always vital to the
organization, but are also nearly always badly managed, horribly written, and outdated.
While there are exceptions to this generalization, the majority of custom
applications pose a problem when you begin your DR planning.

There are two general categories of issues that custom
applications cause in DR planning, and both will have to be assessed and
addressed if found. The first is software that is specifically designed (either
on purpose or accidentally) to prohibit fast DR. The second is lack of
management over the software itself.

Tips in your inbox

How well can your organization deal with an emergency? The Disaster Recovery newsletter helps you protect your valuable data.

Automatically sign up today!

Most major software applications are incredibly flexible,
meaning that they can adapt to changing circumstances within their environment—within
certain limitations of course. Custom applications generally do not follow that
form and are often written to work within a very strictly limited set of
conditions and environmental variables. While you can easily protect these
applications’ data with tape backup and basic data replication, they pose an
incredible problem when you discuss High Availability
(HA) solutions
in your environment. Basically, if a custom app cannot work
anywhere except on the exact server for which it has been configured, then you
cannot easily move it to another data-system in the event of a disaster.

The most common DR problem for a custom app is its inability
to work on any other IP address or subnet than the one it was originally
written for. So, if you attempt to fail over to another data center, you’ll
find that the application cannot function, since the alternate data center will
nearly always be on an alternate subnet. You can get around this issue by using a Virtual
Local Area Network (VLAN
) or other subnet-stretching technologies to make available
the IP address that is required when you need to fail over, but these
technologies are expensive and complex to implement and manage.

The second common problem that crops up is the lack of proper
documentation and management for many custom applications, making them enigmas
within their own environments. Employees and technical staffers may know what
the application does, but often no one but the application’s developers know
how it functions. When you attempt to plan for DR, you may find that you have
no clue how to properly configure and/or manage this application either for
backup or for failover. Where does it keep its data, and what files have to be
protected? Can it be backed up while in operation, or does it need to go
offline first? Can it be installed on more than one server at a time, or will
you have to use advanced failover methods to trick the backup server into
thinking it’s the production box at the time of the disaster? All of these
questions can be answered by the programmers and application developers, but
without their input you may find yourself in an impossible DR situation.

Custom applications pose challenges to any organization, but
you can protect them. Bring in the developers, plan according to the needs of
the application, and get management buy-in every step of the way. Perhaps the
most important thing you can do is determine the criticality of these applications
before you begin. Most of them can be backed up to tape or disk rather easily,
and if you have a longer period of time to get them back, you can use the
backup to restore service to a re-installed machine. This may save you a lot of
time and pain when planning for a disaster, or at the very least, let you
properly plan for what is no doubt going to be a long process to come.