When do you require remote disaster recovery options?

by Mike Talon | May 01, 2006 7:00:00 AM

Tags: Mike Talon, failover, disaster recovery, failover option, Disaster Recovery Newsletter

Takeaway: At some point, you have to decide if local failover options are enough for your organization, or whether you need to add remote failover to protect you from a major disaster. Mike Talon discusses some of the considerations for making that decision.

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.

Print/View all Posts Comments on this article

Good Post ! gauravd.chd@... | 11/03/08