Continuous Data Protection (CDP)

In this topic:

About CDP

Continuous Data Protection (CDP) is a disaster recovery solution for virtual disks. This feature is used to protect and recover corrupted data when disruptive events occur.

Continuous Data Protection is a licensed option.

The difference between CDP and the Snapshot feature is that a snapshot preserves the contents of the virtual disk at a point in time and can be created when data is known to be in a good state. With CDP, a virtual disk is protected for a period of time. Rollbacks—created from the CDP-enabled virtual disk—can be created at any point in time during the valid time period, regardless of the state.

History Log

When the feature is enabled for a virtual disk, a history log is automatically created on a DataCore Server for that virtual disk. In the case of mirrored virtual disks, one server is selected to keep the history log, which is created from a pool on that server. All data changes occurring on the CDP-enabled virtual disk are time-stamped and saved in the history log. The history log is used to create rollbacks—logical copies of the CDP-enabled virtual disk at a valid point-in-time) saved in the history log.

Data changes in the history log are preserved based on the licensed retention time and the maximum history log size:

The licensed retention time is displayed in the Server Group Details page>License tab (see Retention time).
The maximum retention time is governed by the CDP license. Long retention times require additional system resources, such as main memory and storage space.
The default history log size is 10TB. The minimum it can be set to is 8GB.
A desired maximum history log size is defined as a virtual disk setting. Changing this affects the retention time for the specific virtual disk.
The desired maximum history log size setting for a virtual disk is a soft limit, where an intention is defined and the driver will try to keep the history log size within the specified size by increasing the rate of destaging and/or throttling client writes. The history log size can grow beyond the desired size. To monitor this, Maximum History Log Warning Thresholds can be set for data protected virtual disks. See System Health Thresholds.

There is a maximum history log size setting for the server group that can be changed to allow for history logs greater than 10TB. This system wide setting controls how large any history log is allowed to be. The maximum history log size setting for the server group is a hard limit.

There is some memory overhead associated with setting a higher history log size limit even if the history log sizes of individual virtual disks are smaller than the value for the server group. The maximum history log size for a server group should only be increased above 10TB if the default setting is not enough to meet the retention time objectives for a specific virtual disk.

Changing the Maximum History Log Size for a Server Group

To change the maximum history log size for a server group:

Navigate to Server Group > Settings.
Change the Maximum CDP history log size value.
Perform a Stop Server followed by a Start Server command for each server that has CDP-enabled virtual disks.

The retention period in the history log is defined by the licensed retention time and maximum history log size for the CDP-enabled virtual disk, whichever is reached first. The number of write I/Os to the virtual disk will determine how fast the history log will reach maximum size. The retention period will fluctuate based on the amount of I/Os written to the virtual disk. When the maximum size of the history log is encroached, the oldest data changes in the history log will be destaged to make room for new data changes, so the times preserved in the history log are dynamic and continue to change.

The retention period and actual storage allocation for the history log is provided in the Virtual Disk Details page>Info Tab (see Retention period and History log fields).

Data is recorded in the history log in UTC (Coordinated Universal Time)
The history log retention period will fluctuate based on the amount of I/Os written to the virtual disk, so the retention period displayed in the console is an estimate.
The history log associated with a CDP-enabled virtual disk is implemented using an internal virtual disk. The history log will have the same storage profile (performance class) as the CDP-enabled virtual disk, so the tier affinity of the log will be created accordingly based on the particular pool selected for the log. Take this into account when enabling CDP on virtual disks so that history log storage does not impact storage or performance needed for other virtual disks using the same pool.
Under some circumstances writes with zero data can be stored to the history log without an associated storage allocation. The management console displays the actual disk space allocated to the history log which may occasionally be lower than the amount of data contained within the log. This discrepancy is harmless and merely reflects optimizations that have been possible given the specific workload on the virtual disk. It has no functional impact on the behavior of the virtual disk, but can create the impression that destaging has started earlier than would otherwise have been expected.
System health thresholds for history log size and retention period can be set. See System Health Thresholds.

Rollbacks

A rollback is a type of virtual disk. It is a logical copy of the CDP-enabled virtual disk at a point-in-time that is stored in the history log. When a rollback is created, the point-in-time (restore point) is selected. The oldest available restore point will continue to change as data is destaged from the history log to accommodate more recent data changes.

When an event occurs that requires data recovery, one or more rollbacks can be created at various restore points and served to hosts to determine the validity of the data. Rollbacks are read/writable, so they can be examined and used by the host. The rollback containing the optimal image of data can be used to either "revert" the data on the rollback to the CDP-enabled virtual disk or the rollback can be "split" to become a fully usable single virtual disk.

Rollback Types

When a rollback is created, the user must select whether to allow the rollback to expire automatically or keep the rollback persistent.

This setting should be carefully considered because it can not be changed after the rollback is created.

Expire rollback: Rollback will expire automatically and become inaccessible when the restore point is destaged from the history log. The rollback will be permanently unusable and should be deleted.
Persistent rollback: Rollback will remain accessible until the rollback is manually deleted or split. Keeping a rollback persistent can have ramifications. In order to keep the rollback accessible, when the restore point reaches the end of the history log it will not be destaged and therefore cause the history log to grow and consume unexpected amounts of pool resources. When the restore point reaches the end of the history log, a mirrored virtual disk will have compromised mirror redundancy and a single virtual disk will become inaccessible. In this case, the rollback will have to be manually deleted or split to resume writes to the virtual disk on the server with the history log.
To avoid this situation, stop the host I/O to the CDP-enabled virtual disk until the rollback is deleted or split.

CDP must be enabled on the virtual disk in order to create rollbacks from the virtual disk.
Persistent rollbacks will prevent destaging of the history log past the restore point and therefore cause the history log to grow and consume unexpected amounts of pool resources. To prevent this, stop the host I/O to the CDP-enabled virtual disk until the rollback is deleted or split.
If CDP is disabled on a virtual disk, all rollbacks created from the virtual disk will be deleted and space allocated to the history log will be reclaimed. (Allocated disk space is not reclaimed until CDP is disabled.)

Replacing the storage source of a CDP-enabled virtual disk will disable the CDP feature if the side which has the history log is replaced.

After the virtual disk has recovered and data is up-to-date, the feature can be enabled again. Replacing the side which does not also have the history log will not affect the feature for the virtual disk.
Restore points in the console are displayed according to the system time zone of the computer running the console.
The timestamp in the default rollback name is the creation time displayed in UTC (Coordinated Universal Time).

See Continuous Data Protection Operations for specific information and instructions for operations. CDP operations can also be performed on virtual disk groups, see Virtual Disk Groups for more information.

Best Practices

Continuous Data Protection requires adequate resources (memory, CPU, disk pool storage performance and disk capacity) and should not be enabled on DataCore Servers with limited resources.
Use dedicated pools for Continuous Data Protection-enabled virtual disks and the history logs for those virtual disks. Disk pools used should have sufficient free space at all times. System Health thresholds and email notification via tasks should be configured for notification when disk pool free space reaches the attention threshold to ensure sufficient free space.
Enabling Continuous Data Protection for a virtual disk increases the amount of write I/O to that virtual disk. This may increase I/O latency to the disk pools used by the virtual disk and the history log and decrease host I/O performance to virtual disks using these disk pools. Continuous Data Protection should be used with caution to protect mission critical data only.
The default history log size may not be adequate for all virtual disks. The history log size should be set according to I/O load and retention time requirements. Once set, the retention period can be monitored and the history log size can be increased if necessary. The current actual retention period for the history log is provided in the Virtual Disk Details>Info Tab (see Retention period).
When copying large amounts of data at one time to newly created virtual disks, enable the feature after copying the data to avoid a significant I/O load.
After an event that requires restoration of data, I/O to the affected virtual disk should be immediately suspended and then rollbacks should be created. Follow this practice to keep older data changes from being destaged, which in turn will keep the rollback from expiring or I/O to the virtual disk from failing. Keep I/O suspended until virtual disk recovery is complete.
Rollbacks should only be created for the purpose of finding a consistent condition prior to a disruptive event and restoring the virtual disk data using the best rollback.
Delete rollbacks if they are no longer needed.