A data recovery solution, whether it is remote or local, is a set of technologies that supports your disaster recovery (DR) strategy. This combination forms the backbone of your company's business continuity program. But is your data backup and recovery solution working to make your disaster recovery solution successful? Here are some tips on how to make the most successful data recovery solution for your company.
Don't rely on a single vendor for your recovery plan. The luxury of calling a single support number isn't much of an advantage if the vendor is incapable of providing the right set of technologies.
Sometimes a single-vendor strategy will suffice. Most disaster recovery experts will tell you to avoid putting all of your eggs in one basket, but you don't have to be obsessive about being multivendor. In some cases, a single-vendor strategy will suffice. But if you're putting a new plan in place, you should try to evaluate "best-of-breed" products that -- with perhaps a little effort -- can be made to work together to meet your disaster recovery objectives.
Make use of both block-level replication and database replication. Let's take the most common and often contentious example: database replication. Many DBAs and storage folks are at odds over selecting the best database replication tool. Storage vendors will tout their proprietary block-level replication solutions as superior to built-in database replication solutions such as Oracle's Data Guard. DBAs are more inclined to opt for the latter replication scenario. So why not implement a strategy that makes use of both?
Block-level solutions provide you with a "restar...
To continue reading for free, register below or login
To read more you must become a member of SearchDisasterRecovery.com
table" copy of your database, while database replication solutions provide a "recoverable" copy. When designing an enterprise-wide solution, I would lean toward an application-agnostic, block-level solution that's closer to the storage array than the application. For example, if you have an EMC Corp. environment, consider using either Symmetrix Remote Data Facility (SRDF) or MirrorView. You may want to include the database replicator because you shouldn't assume that SRDF will provide an end-to-end solution. The combined approach will give you a restartable copy that can be made "current" to the last good transaction permitted by your recovery point objective (RPO). Keep in mind though, this isn't a black-and-white solution -- the shades of grey are in how you implement the combination.
Consider interoperability. Interoperability is a key consideration when selecting technologies to help avoid finger-pointing among vendors when implementing a multivendor strategy. For example, the application clustering technology used with the data replication solution will determine if the clustering solution can effectively control the failover of the replication and start of applications at the remote site. Most clustering and application vendors now offer geographical clustering plug-ins to their cluster solutions that can be used to control data replication solutions from different vendors. Therefore, the choice of a clustering solution can't be made in a vacuum.
Cost matters
The bottom line is always price. Is the cost of implementing an elegant solution justified? Some business requirements may dictate large expenditures, but don't assume that every recovery plan has to be expensive. When you put all the options on the table, you'll be surprised how many there are. Block-level and array-to-array solutions tend to be the most expensive in terms of storage, licensing costs and the network bandwidth required to keep the two copies in sync. Application replication products are usually cheaper and have less-demanding bandwidth requirements, however they only work with the specific application.
Array-based replication solutions are application-agnostic and can be used to replicate any of the array's contents. But replicating everything on the array is an expensive proposition; if you need to trim costs, you may want to use a more selective approach.
Use tiered data recovery
You don't need 100% of your production data at the remote location for a partial or near full recovery. You need just enough to put you back in business. Therefore, you must identify components that can either be left behind or reconstructed using relational data. Databases are the most common examples here. File and print services are another. Keep in mind that we're not talking about losing this data for good; we're only deferring its recovery to a later point in time, perhaps by using tape.
Just as production storage is tiered using service-level agreements, data recovery can be offered in a tiered manner and tied into the overall storage service model. Data- supporting applications that form the backbone of your business can be replicated in a synchronous or near-synchronous manner that's capable of providing "zero transactional loss." Second-tier applications may be replicated asynchronously in an "always on" or periodic "sync-split-sync" manner. Those approaches can provide an RPO in which losing a few transactions is considered normal or not business critical. Moreover, the lost information can be reconstructed using indirect methods or a reload of data from sources outside of your company. Of course, if the application data can withstand a few days of downtime, it's a candidate for recovery by tape. An important technological innovation that has only recently been applied to data storage is quality of service (QoS). QoS allows you to choose which class of data gets preference over other classes. The array or network gear is then capable of serving as a traffic cop to ensure that the most important class of data reaches its destination first.
It's easy to assume that just because you have a data recovery solution in place it will work in the manner envisioned by your disaster recovery strategy. But the old adage of practice makes perfect is particularly appropriate for a DR plan: Put it through its paces and make it work for you.
This article originally appeared in Storage magazine.
About this author: Ashish Nadkarni is a principal consultant at GlassHouse Technologies Inc.
