This article can also be found in the Premium Editorial Download "Storage magazine: How to plan for a disaster before a software upgrade."

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

Monitoring and configuration tools
The difficulty of manually synchronizing a primary environment and a backup environment has led to the development of automated monitoring and configuration tools. The FlashSnap feature in Veritas Storage Foundation Enterprise enables admins to create application server groups that ensure application servers are configured to connect to the appropriate backup storage in the event of a hardware failure in the primary data center, says Sean Derrington, Symantec's director of storage management. This eliminates much of the effort and error associated with manually configuring such servers, he says.

Continuity Software Inc.'s RecoverGuard continually checks to determine that all changes made to the primary site are reflected on the backup site; identifies dependencies among servers, storage devices, databases and apps; and automatically detects gaps such as the passive node on a cluster not being mapped to the correct disk volume, which could cause a problem during a DR event.

RecoverGuard (which Continuity Software plans to offer as a service) currently supports EMC Corp. and NetApp arrays, with support for Hitachi Data Systems hardware expected in the next few months.

WysDM Software Inc.'s WysDM for Backups continually monitors back-up environments and provides customized policy-based alerts about problems that could affect the DR environment.

Requires Free Membership to View

(EMC recently acquired WysDM Software.) Among other conditions, it can report on servers that haven't been backed up within a given period of time, and backups that need to be rescheduled to meet service-level agreements.

BladeLogic's Data Center Automation suite can monitor the configuration of backup data centers to see if they vary from corporate policies. Vick Viren Vaishnavi, BladeLogic's director of product marketing, says some customers are using the suite to help them synchronize changes among sites.

Tracking such changes is much easier when a firm maintains the same hardware and software at both the primary and DR site, and uses virtualization to mask any disparities between the two. Dick Cosby, systems administrator at Estes Express Lines, used system utilities for his firm's IBM System Storage DS8000 storage to mirror changes in data, as well as changes to the sizes of the underlying volumes and LUNs, between the Richmond, VA-based headquarters and a DR facility in Mesa, AZ. But Cosby says he wouldn't be able to rely on this integrated process if, for example, he introduced EMC storage into the environment.

Test more often and more thoroughly
In testing disasterrecovery (DR) plans, IT staffs often overlook how applications depend on each other for data and don't understand which related sets of data need to be backed up and restored to the same point in time, says Bill Peldzus, director of data centers, business continuity and disaster recovery at GlassHouse Technologies Inc., Framingham, MA.

By failing to fully understand application dependencies and properly identify "consistency groups"--related sets of data which should be updated to the same point in time--organizations risk running DR tests that don't accurately reflect how well an app could be recovered after an actual disaster, he says.

For example, an order-entry system might have a recovery point objective (RPO) and a recovery time objective (RTO) of four hours. A customer database with which it shares data might have an RPO and RTO of 12 hours. When the data for both applications is restored in a test, "you have customers without orders and orders without customers because the data wasn't recovered in a consistent fashion," says Peldzus.

While many replication apps can identify consistency groups, they're much more difficult to use across different platforms, such as PC-based, minicomputer and mainframe servers, he says. Often, says Peldzus, test designers lack the time to properly configure such tools to account for all of the platforms a company operates.

Peldzus also recommends that companies test to see if they can recover all of their critical apps within the required time period, rather than (as is often the case) only testing the apps needed by one business unit or that serve one function, such as email.

Finally, he suggests testing critical apps most often. Apps with RPOs or RTOs of less than 24 hours are candidates for testing two to four times per year, rather than just annually, he says.

This was first published in May 2008

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: