Failing over across a wide-area network is never an easy thing
to contemplate. If a single system fails, you will probably fail to a local
server instead, keeping your users close to the data systems they’re using. If
multiple systems fail at once, you may have to fail over to another site.

When putting together your disaster recovery (DR) plan and
budget, the first decision you need to make is whether your systems require a remote
failover option, or if storing the data locally for restoration is sufficient
for your needs. Failover is usually only required if you must restore both the
data and services within one business day. Keep in mind that if you’re failing
over to a remote site, there has been a major disaster, and your end users may
not have access to their workstations and/or physical sites. That would mean
that they have no immediate need for their systems to be running, so the
important thing is that the data is kept safe to be restored whenever they are
ready.

If you, indeed, need to fail over remotely, the next decision
is how you will get the data to the remote location. There are a few ways to do
this, and which one you use will depend mainly on your budget and
infrastructure. The simplest way is to use tape backups
for your production systems, and then ship those tapes to the DR location,
where restoration occurs on a regular basis. The benefits to this solution set
are that it tends to be the least expensive in terms of hardware, especially if
you can create backup-restore systems that rely on a limited number of tape
drives. The main drawback is that it’s an entirely manual solution. You will be
responsible for moving the data, putting it on the remote systems, and
performing all failover actions.

Replication
systems come in two flavors. There are synchronous systems (typically
hardware-based) and asynchronous (usually software-based). The differences are
that synchronous systems require, at the very least, identical storage systems.
Identical server systems are required also if you plan on an automated failover
option that would replicate OS partitions. Otherwise, you’ll have to fail over
manually when the time comes. The benefit to these systems is that they nearly
always cover multiple types of OSs (Windows, Linux, Solaris, etc.) and allow
for zero bytes of data loss, though at the cost of tremendous amounts of
bandwidth.

Asynchronous replication systems do not have the same hardware
requirements in the majority of cases. They do have the potential of minimal
amounts of data loss, but allow for much lower bandwidth requirements and many
more types of automated and/or automatic failover options. Generally speaking,
they will maintain transactional integrity of your data, so even if they aren’t
real-time, they still allow for proper failover, even of databases. You will
have to give up some system resources (CPU, disk space, RAM), as they are
mostly software-based, so these solutions aren’t a good idea for overtaxed
machines.

Remote failover is never an easy decision and is harder on the
budget; however, if your business cannot withstand the loss of a data center
for a business day, it may be your only choice.

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.