Feature

The search for cost-effective disaster recovery

Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Disaster recovery planning options on a shoestring budget."

Download it now to read this article plus other related content.

Setting RPO and RTO benchmarks

    Requires Free Membership to View

Recovery point objective (RPO): RPO is the point in time to which systems and data must be recovered to the DR center. For example, a typical synchronous mirror RPO is to recover the data to the very moment before the interruption at the primary site (e.g., zero data loss). Asynchronous replication RPOs recover the data to within seconds of the interruption at the primary site. Common point-in-time snapshot RPOs recover the data to the last snapshot, which could be anywhere from hours to days.
Recovery time objective (RTO): RTO is the period of time within which systems and applications must be recovered after a disaster or outage, including application recovery time. Think of RTO as the amount of time required to get everything back to the same level of production as before the primary site interruption.

Once you know the RTO and RPO for each application (see "Setting RPO and RTO benchmarks"), you can provide an operational framework for valuing or prioritizing the data (see "Correlating data to RPO and RTO").

The next step is to determine which available DRoptions satisfy each application/data classification's DR requirements and to then match their total cost of ownership (TCO) to the budget. You'll likely find that one size doesn't fit all and a mix of solutions will be required.

DR options
The number of DR options is large and growing. Each technology has advantages and disadvantages, and solves different aspects of the total DR puzzle. Afollow-up article in a future issue of Storage magazine will examine the merits of each DR technology in greater depth.

Matching the appropriate DRtechnology to the DR requirements entails calculating the TCO for each technology option. The TCO includes all capital expenditures (CapEx) as well as operating expenditures (OpEx) for the expected DR lifecycle (see "Simple method for calculating TCO").

When correlating the TCO of selected DR options to each data value, it's likely there will be more data classified as mission critical or essential than the DR budget allows. And in some cases, the application server and its mission-critical data are geographically dispersed and it's not financially practical to use the DRtechnologies that are typically applied. Current DR regulations may be another key factor in this mismatch.

In that case, it may be necessary to relegate some applications and their data to a lower level of DR. Unfortunately, relegating a portion of the data to the important or less-critical data pools may not be a viable option. It may make the organization non-compliant with current regulations, raising the specter of significant financial penalties. Another issue may arise if the organization lacks personnel skills at the required locations to provide adequate DR.

Eliminating the DR GAP
Bridging the DRGAPrequires putting aside the belief that one product will solve all your problems. You need to consider a combination of DR technologies working together in a layered solution. It's the synergistic combination that enables the organization to meet its needs and requirements within its budget.

For example, you may need to use server-to-server replication to a centrally located disk array for remote application servers. From the central location, that data can then be backed up to tape and/or snapped to a DR disk array. This would require fewer backup server licenses and allow better disk array storage utilization.

Correlating data to RPO and RTO

In another example, a continuous snapshot appliance replicates primary data onto a low-cost serial ATA (SATA) RAID or a massive array of idle disks (MAID) array. Then the RAID or MAID array asynchronously replicates the data over long distances to a DR site.

A third example may include an appliance-based distributed backup system that replicates remote sites to a central appliance. At the central facility, the data is then written to tape, MAID, etc. This leverages the DR target platform used for disk-to-disk replication as well.

The possibilities are endless, and each organization will have different needs. The trick is putting together the right combination of technologies that meets the needs at the lowest possible price.

This was first published in November 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: