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.

Many times, when discussing Disaster Recovery
(DR), engineers tend to lump together both servers and the
applications that sit on those servers. The mistake made in these
situations is that most disaster scenarios require only a limited
number of users or systems be supported by an application, which in
turn will require fewer server resources than the frontline version
of the app. I must admit I’ve fallen into this habit myself on
occasion, and very few qualified engineers are immune.

The main issue with this line of thinking is
that–in many cases–doing so will limit your ability to failover
applications, and this will often force you to allocate a larger
budget number to a disaster recovery project than is necessary.
There are two common repercussions that can come about as a result
of not thinking about applications separately from servers:

  • You may allocate an entire failover server to
    an application that could have shared space with another app on a
    DR server.
  • You could also allocate hardware that is
    powerful enough to handle normal operations to the DR center, when
    only a small sub-set of the total processing power is needed for
    failover scenarios.

Many applications must be allocated to their
own servers in order to operate at top capacity or to operate at
all. Common examples are data systems that are single-engine
programs, where only one copy of the software can conceivably run
at any given time. In these cases, you will no doubt find that you
do have to protect and failover these applications and servers as a
unit. However, you may not need to allocate nearly the same budget
amount to the backup data-systems as to those in production.

Unless all operations are going to failover in
the event of an emergency, you will have far fewer users–both
internal and external–after a disaster has occurred. Because of
this, your data-systems will almost definitely be able to operate
with much lower levels of hardware in terms of CPU, RAM and other
critical and often expensive components. In many cases, you can
even use equipment made available by a hardware refresh to be
repurposed as disaster recovery equipment.

In the majority of cases, applications have no
problem sharing servers with other applications. A large number of
applications are beginning to be built with this idea in mind,
allowing for multi-instancing or the ability to limit the amount of
system resources they consume. This allows you to either failover
multiple applications to a single physical machine, or deploy
multiple redundant instances of the same application, depending on
the application in question.

Just make certain to properly size the DR
servers so they can handle the load of multiple applications,
keeping in mind that there will be fewer users on each app.

As server virtualization tools become more
mature and readily available, you will be further empowered to
create customized combinations of failover systems that take into
account the distinction between applications and their parent
servers. No matter what combinations of solutions you decide on,
taking this into account during disaster recovery planning will
ensure that you have the most effective combination of budget and