Evaluating continuous data protection (CDP)

Posted on October 01, 2005

RssImageAltText

An analysis of continuous data protection explains what it is, how it works, why you need it, and what’s available.

By Dianne McAdam

ontinuous data protection (CDP) is the next evolutionary step in data protection. Traditionally, data-protection schemes have been designed to back up data at specific intervals. CDP, as its name implies, continuously backs up the data, giving users more granular recovery points.

While all vendors’ implementations differ, they all address the age-old problem of protecting and, more importantly, restoring data as quickly as possible.

What is CDP?

CDP solutions are designed to continuously record any changes to application data. This data can be in block- or file-system format.

Block-based approaches work at the logical volume level. Initially, the logical volume is copied to a second disk storage system. After the initial setup is completed, all writes, or updates, to the primary logical volume are also copied to the second disk array.

File-based CDP solutions are similar to block-based solutions, but they work at the file-system level. Again, any changes to the file system, such as its creation, deletion, or modification, are recorded on a second disk system.

When data is corrupted or accidentally deleted, CDP solutions allow the volume or file system to be restored to the latest update or to any previous update point. This choice of many different recovery points is a significant benefit over traditional data-protection methods.

Traditional data protection

To understand the advantages that CDP offers over more-traditional methods of data protection, let’s compare CDP to disk copy block-based approaches.

One commonly used method of data protection creates disk copies, or snapshots, of the volumes. The administrator has to determine ahead of time when the copies will be taken-once a day, or more often for highly active critical data. In contrast, with CDP there is no need to plan for this, since updates are continuously recorded.

A second difference involves the commonly used metric, recovery point objective (RPO), which measures the age of the data used for the restore operation. If snapshots are invoked every four hours, then the RPO can be as much as four hours. With CDP, the RPO need be no longer than the time since the last update was recorded. (You may not want to use such “fresh” data, but you always can.)

In short, the appeal of CDP is that recovery points do not have to be determined in advance and IT administrators can choose to restore from a large number of recovery points-the last update recorded or an update that was recorded hours or days before or anything in between.

How does it work?

Although vendors’ CDP solutions can differ widely, most operate in a similar fashion. Take the example of block-based CDP. Usually, agents must be installed on the host or CDP appliances must be installed in the data path. Some solutions integrate with intelligent switches in the SAN. These agents, appliances, or switches examine every write designated for CDP-protected volumes.

Data from the application server is captured write-by-write and is sent to secondary disk storage. This storage is managed by a CDP recovery engine, which time-stamps each block of data, allowing the engine to later create an image of the data from any point in time. This image can then be presented to the original server or to any other servers that are connected to the secondary storage.

All CDP solutions continuously capture updates, so protected applications never need to be interrupted for backup operations. Thus, there is no backup window. Furthermore, CDP allows administrators, when restoring data, to request an image of the data seconds before corruption occurred. Recovery time objective (RTO) is reduced to the time required to create the image and restart the application. RPO, or age of the restored data, is reduced to the last updates recorded seconds before the corruption entered the system.

CDP should not be considered a replacement for existing data-protection techniques, but rather as an enhancement to them. The CDP engine can create an image that can be used as the source for existing backup processes. The backup process can be started without requiring that the application ever be brought down. CDP is best-suited for protecting mission-critical applications where restore time must be measured in seconds or minutes. It is also well-suited to data that is updated frequently. Less-critical or infrequently updated applications can continue to be protected by other backup/restore techniques.

One caveat: While CDP technology can improve recovery times, it does not protect against corruption. Corruption that enters the primary copy of the database will also be quickly spread to the CDP copy. Recovering a corrupted database may require the IT administrator to restore the database to a point in time prior to the corruption entering the system. CDP is appealing to IT administrators since they can easily re-create any view of the data. Yet not all CDP solutions integrate with the specific application that is being protected, which can result in images that do not have transactional consistency with that application.

For example, block-based CDP captures each write, but transactions for databases consist of multiple writes. When all writes for a transaction have been received by the database, the transaction is marked as “committed” or complete. If the database must be restored, choosing the last recovery point can result in recovering the database with incomplete transactions. This situation is similar to that of a data center that loses electrical power in the middle of processing a database transaction. So an extra step is required. After the image of the database volume is created and mounted on the server, the database must read its log file to determine which transactions are incomplete (not committed) and back out those incomplete transactions.

Some vendors have developed block-based or file-based CDP solutions that integrate with common applications. Some are specifically designed to work with one application, such as Microsoft Exchange, while others support numerous applications. These solutions detect application events, such as checkpoints or committed transactions, and note those events on the secondary storage.

In addition, some solutions provide support through APIs (i.e., an API that allows IT administrators to mark significant events, such as the end of a financial close). Now administrators can choose to create an image from any previous recovery point, or choose designated recovery points that provide transactional consistency with the application.

Given the many CDP products that are available today (see above), it can be difficult to determine which is right for a particular environment. The following questions may help to narrow the choices.

Architecture

  • Is the solution host-based? That is, are the data collection agent and recovery engine resident on the same server as the protected application? This approach is appropriate for a small business with few servers, but it cannot easily scale to support a large-enterprise environment with applications spread across numerous servers.
  • Is the solution network-based? With network-based approaches, the recovery engine resides on its own dedicated server with its own attached secondary storage. Here, there are two choices: The recovery engine is in the data path or outside the data path. Both solutions have merit. Appliances that are directly in the data path do not require host collection agents since they examine each I/O as it passes through the appliance to determine if the I/O is a write operation for a protected application. Solutions where the recovery engine is outside the data path eliminate the appliance as a bottleneck or point of failure in the data path, but generally require host agents to determine which I/Os must be shipped to secondary storage. Another approach uses an intelligent switch (and not host agents) to direct write I/Os to the out-of-band appliance on a SAN.

Performance, scalability, availability

  • What is the CDP solution’s impact on the protected application’s performance?
  • How many write operations can the recovery engine sustain? If write activity increases, can the server and recovery engine adequately support the growth? What is the upgrade plan?
  • How many protected servers can be supported by each recovery engine? How much storage can be supported?
  • Is the recovery engine on a clustered server? If the recovery engine fails and it is not clustered, what is the impact on the protected application? Can the protected application continue processing? How do you recover operations when the failed recovery engine is replaced or repaired?

Hardware

  • Does the recovery engine server use industry-standard hardware? Has it been built to the CDP vendor’s specifications? What is the cost of this server? If the hardware fails, can it be quickly and easily replaced?

Operating systems software

  • What operating systems are supported? Is the solution certified by the operating system vendors?
  • If agents are required, are the agents available for each operating system in your environment? Are they available for all versions and fix levels of the operating system, or do they only support some of the versions? If not, what are the vendor’s plans to support additional operating systems? Is there a charge?
  • Can the CDP solution protect system volumes and file systems?

Replication to remote locations

  • Some CDP implementations can replicate the images stored on secondary storage to a remote location to provide disaster-recovery services. Does the solution support remote replication? If not, can it be integrated with the remote replication products you are using?
  • Is there a need to replicate the CDP storage, or will the current processes that store backups off-site meet D/R goals in place today?
  • What is the additional cost to replicate the CDP storage and recovery engine?
  • What are the distance limitations?
  • Will replication impact performance?

Pricing

  • How is the product priced? By number of agents? Amount of protected storage?

Operations and support

  • CDP does not replace existing backup-and-archiving processes, but should integrate with those functions. Does this product do so?
  • How long will it take to implement it? Can the solution be installed non-disruptively? Is it user-installable? If not, are there additional charges for installation?
  • Is training required or recommended? What is the cost of that training?
  • What support is available from the vendor? Are support costs included in the purchase price?

Market acceptance

  • Is the product a recent addition to the market, or has it been available for months or years?
  • How many of the products have been sold?
  • How many products are installed in production environments?
  • Which applications are being protected by CDP?

Application-aware software

  • What applications are supported? Does the CDP solution support specific applications? Have the application vendors certified the CDP product?
  • Which application events are recorded by the CDP engine? Are application checkpoints recorded? Is each committed transaction recorded?
  • If the application data spans multiple volumes, can these volumes be logically grouped together to create, in effect, consistency groups for each protected application?
  • What applications not currently supported will be supported in future?
  • Can user-defined events, such as the end of a fiscal close, be recorded?

There are numerous CDP solutions available today from both large and small vendors, and you can expect to see other large storage vendors develop their own CDP solutions or partner with small vendors that have already delivered the technology.

Dianne McAdam is a senior analyst and partner at the Data Mobility Group (www.datamobilitygroup.com) in Nashua, NH.


Representative CDP Vendors

File-based CDP:

  • IBM (IBM Tivoli Continuous Data Protection for Files)
  • Lasso Logic (Lasso CDP)
  • Mimosa Systems (NearPoint for Microsoft Exchange Server)
  • StoneFly Networks (Replicator CDP)
  • Storactive (LiveServ)
  • TimeSpring (TimeData)
  • XOsoft (Enterprise Rewinder)

Block-based CDP:

  • FalconStor (IPStor Continuous Data Replication)
  • InMage (DR-Scout VX)
  • Kashya (Data Protection Appliance)
  • LiveVault (InSync)
  • Mendocino (RecoveryONE)
  • Revivio (Continuous Protection System)
  • Symantec (“Panther”)

For more information on continuous data protection (CDP), see the following articles that have appeared in InfoStor:

“Continuous data protection: Is it about time?”, p. 28, in this issue.

“CDP: What it is, and why you need it,” September 2005, p. 42

“Microsoft enters D2D backup market,” August 2005, p. 1

“Early adopters praise CDP,” May 2005, p. 10

Originally published on .

Comment and Contribute
(Maximum characters: 1200). You have
characters left.

InfoStor Article Categories:

SAN - Storage Area Network   Disk Arrays
NAS - Network Attached Storage   Storage Blogs
Storage Management   Archived Issues
Backup and Recovery   Data Storage Archives