> Documentation > Backup and Restore Agents > Replication > ContinuousDataReplicator Overview > Operations > Recovery Points

Recovery Points - Topics

Overview

Recovery Point is set of snapshots of the data to preserve a point-in-time on the Destination. This not only affords an extra measure of protection for your data, it also expands the number of options you have when recovering your data.

For any supported configurations snapshot-based Recovery Points can be created and backed up. In addition, Recovery Points can be mounted, and for Windows can also be shared, to make it available to users on the network.

A Recovery Point is created at the Replication Set level. It will consist of a snapshot of every destination volume used by all the Replication Pairs that comprise the Replication Set.

Here is an example:

repset1 is comprised of the following Replication Pairs:

  • reppair1: destination is F:\repset1_data\reppair1\

  • reppair2: destination is F:\repset1_data\reppair2\

  • reppair3: destination is G:\repset1_data\reppair3\

  • reppair4: destination is H:\repset1_data\reppair4\

Since the destinations used for all of the Replication Pairs in this Replication Set involve three volumes, namely F:, G:, and H:, on the destination computer, each Recovery Point for this Replication Set would contain three snapshots.

The following image shows data flows during creation of Recovery Points and backup of Recovery Points:

cdr_08

Recovery Point Types

Three types of Recovery Points can be used with ContinuousDataReplicator (CDR). They are:

Recovery Points

Recovery Points consist of snapshots created on the destination computer by the specified snapshot engine, without any reference to the state of the source computer. It simply represents a point-in-time on the destination computer, and is thus more useful for file system data than for application data.

Consistent Recovery Points

A Consistent Recovery Point defines a point-in-time in which data is in a consistent state on the source computer. This ensures the data can be restored to that point-in-time. Hence it is more useful for application data than for file system data. Consistent Recovery Points are created as follows:

  • On the source computer, the application server software is briefly quiesced and a marker is placed in the log file that is maintained on the source and transferred periodically to the destination computer.

  • On the destination computer, when that marker is reached during replay of the log, a snapshot will be taken on the destination by the specified snapshot engine, which preserves a Consistent Recovery Point, and represents exactly the point-in-time on the source computer when the application was quiesced and the marker placed.

This process ensures the application can be restored to the exact point-in-time when the marker was placed on the source. Note that for non-integrated applications, CDR will not automatically quiesce the application server, but you can configure this behavior through the use of a quiesce and unquiesce script. When Consistent Recovery Point creation has been specified for a Replication Set, CDR will automatically check for the existence of quiesce/unquiesce batch files. If they are found, the script-based quiescing and unquiescing will be executed in conjunction with the placing of a marker in the Replication Log file on the source. Also, read Application Integration to understand how CDR replicates application.

You can create appropriate batch files using the name and location on the source computer given below. Note that you must use the Replication Set name to uniquely differentiate quiesce/unquiesce batch files from each other, since you may use such batch files for multiple Replication Sets.

  • Quiesce batch file location and name on the source computer:

    <software installation path>\<Replication Set Name</>_Quiesce.bat

  • Unquiesce batch file location and name on the source computer:

    <software installation path>\<Replication Set Name</>_Unquiesce.bat

Recovery Points for Fan-In Configuration

Recovery Points created for a Fan-In configuration use VSS or ONTAP as the snap engine for creating snapshots. The use of snap engine is based on the destination being used. When the destination is a fixed volume then VSS is used and when the destination is a filer or iSCSI device then ONTAP is used for the creating snapshots. When destination volume is ONTAP LUN, Use ONTAP snapshot for ONTAP LUN destination option should be selected for creating snapshots with ONTAP snapshot engine. In case if option is not selected, VSS snapshot engine will be used.

Consider the following for ONTAP snapshots:

  • Specify the user authentication details to be used for creating ONTAP snapshots. The user information must be specified both in the General tab of the replication set properties on the source and in the General tab of the agent properties on the destination.

  • Manual mounting of ONTAP snapshots is not supported in a Fan-In configuration. If Auto-mount option is selected, ONTAP snapshots will be automatically shared.

Prerequisites

The following are the prerequisites for implementing Recovery Points.

Install Requirements
License Requirements

How to Set Up Recovery Points

The following section provides the steps required to configure and use Recovery Points with CDR, based on a single source and single destination. If your environment uses a different scenario, adjust your steps accordingly.

Perform the following tasks to create Recovery Points:

  1. If you wish to configure Consistent Recovery Points, you must first configure CDR to replicate data.

    See Configure CDR to Replicate Application Data for step-by-step instructions.

  2. For both Recovery Points or Consistent Recovery Points, you must then configure the recovery points.

    See Configure Recovery Points for step-by-step instructions.

  3. Next you must create the Recovery Points.

    For Direct Replication and Fan-Out Configurations, see Create a Recovery Point for step-by-step instructions.

    For Fan-in Configuration, see Create a Recovery Points in a Fan-in Configurations for step-by-step instructions.

You can also optionally perform the following operations:

  • Pre/Post Commands for Recovery Points

    You can specify commands to run either before a Recovery Point is created and/or after a Recovery Point is created. For general information about Pre/Post commands, see Pre-processes and Post-processes.

    See the following for step-by-step procedures for Pre-processes and Post-processes with ContinuousDataReplicator:

  • Mount or Share Recovery Point Snapshots

    The snapshots that comprise a Recovery Points can each be mounted/shared as a volume or mount point on the destination computer, and thus made available to users on the network.

    • On Windows, mounted volumes can also be shared on the network from the destination computer. These capabilities allow data to be copied from them by users with permissions to these volumes or shares, providing another means through which replicated data can be accessed easily.

      Mounting of Recovery Point snapshots can be configured to happen automatically whenever a Recovery Point is created, or you can select any existing Recovery Point and mount the snapshots on-demand. Snapshots can be mounted to a drive letter (e.g., G:) or a mount point (e.g., G:\mountpoint1) but note that the path for the mount point must exist already in order for the mount to be successful. In addition, you can also create a share on-demand from any mounted snapshot.

      When mounting a snapshot to a drive letter, you must ensure that it is an unused drive letter; attempting to mount a snapshot to a drive letter already in use by a local resources will fail. However, if the drive letter is already in use for a mapped network drive, the mount attempt will actually succeed, but produce unwanted results. As a result, for Windows 2003, the snapshot will be mounted, but not at the specified drive letter, and thus you will not be able to access it using Windows Explorer. The existing mapped network drive will continue to be accessible at that drive letter using Windows Explorer.

      The snapshots that comprise a Recovery Point can be shared, but they must be mounted first; conversely, they must be unshared before they can be unmounted. The snapshots of a Replication Set configured for Fan-in cannot be shared.

      To mount or share Recovery Points, see Mount or Share a Recovery Point for step-by-step instructions.

      To unmount or unshare a Recovery Points, see Unmount or Unshare a Recovery Point for step-by-step instructions.

      A Recovery Point cannot be deleted by the system if you have manually mounted or shared the snapshots that comprise it. For more information about why the system needs to delete Recovery Points, see Delete Recovery Points.

    • On UNIX, mount points are automatically created for all Recovery Point snapshots, and they are also automatically mounted; you have the option of creating a symbolic link to that mount path.

      On UNIX, CDR software automatically recognizes the File Systems configured on the destination computer and detects the appropriate snap engine. For more information on supported snap engines, see Snapshot Engines - Support.

Manage Recovery Points

All Recovery Points can either be scheduled or created on-demand. Consider the following sections for managing Recovery Points.

Backup Recovery Points

  • Recovery Points can be configured to be automatically backed up when they are created by creating the necessary schedules. Also, you can select any existing Recovery Point and perform an immediate full backup on-demand. To perform a Backup of Recovery Points both the source and destination computers must have the appropriate File System iDataAgent installed.

    • On Windows there is no need to mount the snapshots that comprise the Recovery Point in order to back them up.

    • On UNIX, the snapshots do need to be mounted, but CDR does this automatically.

  • The following types of backups are supported:

    • Full

    • Differential

    • Incremental

    See the following for step-by-step procedures:

  • Consider the following if you have configured Recovery Points to be backed up when they are created:

    • The creation of a new Recovery Point is not dependant on the successful completion of the backup of the previous Recovery Point. Therefore, if for some reason a backup job in this schedule is delayed/failed/pending/suspended, etc., Recovery Point creation will continue unaffected. When the Maximum Number of Recovery Points specified in the Replication Set Properties (Replication Options) tab is reached, CDR will begin deleting the oldest ones and it is thus possible that a Recovery Point will be pruned before the backup delay can be addressed. See also Delete Recovery Points.

    • When a backup job in this schedule is delayed/failed/pending/suspended, etc., it may be confusing as to which data has actually been backed up when the delayed backup job finally runs. It will back up the Recovery Point data as it existed when the backup initially started, even though the time of backup reflected by the backup history is later. Consider the following example:

      6:00a.m. - Recovery Point 1 is created, but backup fails.

      7:00a.m. - Recovery Point 2 is created, and backup completes successfully.

      8:00a.m. - Recovery Point 3 is created, and backup completes successfully.

      8:30a.m. - Administrator restarts the backup job that is in pending at 6:00a.m; job completes successfully, but job history shows a time of 8:30a.m., even though this is a backup of the point-in-time data from 6:00a.m.

  • When backing up a Recovery Point on demand, ensure that you are aware of the age of the data that you are backing up. Each Recovery Point represents a specific point-in-time on the Destination computer, and each Consistent Recovery Point represents a specific point-in-time on the Source computer, but you can choose to back up any of them at any time. The time stamp on the backup will not match the point-in-time represented by the Recovery Point. As an example, let's look at a case where you have 12 Recovery Points, each created an hour apart starting with RP1 at 1:00 a.m., RP2 created at 2:00 a.m., and so on, and you create the following backups on-demand:

    • At 10:00 a.m. you back up RP9 (which was created at 9:00 a.m.) and label it "backup10am".

    • At 11:00 a.m. you back up RP2 (which was created at 2:00 a.m.) and label it "backup11am".

    Several days later you browse these two backups, and note the time of each backup as 10:00 a.m. and 11:00 a.m., but might not realize that the data in "backup11am" is actually older than the data in "backup10am", based upon when each Recovery Point was created. Thus, for on-demand backups of Recovery Points, you should be careful that you know the relative age of the data in each backup, not merely the time stamp of the backup itself, so that the correct data is selected for a restore operation.

Restore Recovery Points

The backup of Recovery Points or Consistent Recovery Points is performed using the Windows File System iDataAgent, which is also used to perform restore operations. For more information about restoring from a backup, see Restore Data - Windows File Systems.

Delete Recovery Points

When the maximum number of Recovery Points is reached, they are automatically deleted by the system in the order in which it was created, starting with the oldest first. If one of the Recovery Points to be deleted is mounted, shared or in use, the following actions will be performed.

  • On Windows, the system will delete next available for deletion Recovery Point. If there are no available Recovery Points for deletion the system will stop deleting Recovery Points until the situation is resolved.

  • On UNIX, the system will mark the Recovery Point to be deleted when it is no longer in use.

The maximum number is either the maximum number you specified in the Replication Set Properties, or you can configure the maximum number of Recovery Points that exist at any one time (per Replication Set for Windows, or per Replication Pair for UNIX) up to the following system limits:

  • AIX with LVM: 15

  • Linux with LVM: 32

  • Windows with VSS: 32 (256 for Fan-In configurations)

  • Windows with ONTAP: 32 (256 for Fan-In configurations)

Obviously, the higher the limit you set, the greater will be the need for hard disk space.

Recovery Points can also be deleted manually, as long as they are unmounted, and for Windows, unshared. The system behavior is slightly different depending on the operating system:

  • For Windows, Recovery Points created by VSS or ONTAP can be deleted in any order.

  • For AIX, Recovery Points can be deleted in any order, but when deleted out-of-order, even though they will no longer appear when you browse in the CommCell Console, the snapshots that comprise a deleted Recovery Point that was not the oldest one will actually continue to exist until all older Recovery Points have been deleted.

  • For Linux, Recovery Points can be deleted in any order, and the snapshots are deleted immediately.

For step-by-step procedures, see Delete a Recovery Point.

Recovering Data from Recovery Points and Backups of Recovery Points

Recovering data from Recovery Points or backups of Recovery Points is similar to Recovery Replicated Data. No additional or special steps are required. For more information on recovering data, see Recover Replicated Data.

Important Considerations

Consider the following when using either type of Recovery Point with CDR.

General

  • For Windows, Recovery Points will only be created for a Replication Set when all its Replication Pairs are in the "Replicating" Job State. If any Replication Pair is not in the "Replicating" state, no Recovery Point snapshots will be created for that Replication Set.

    For Fan-In, Recovery Points can be created for replication pair being in any Job State.

    For UNIX, any Replication Pair not in the "Replicating" state will be ignored and Recovery Point snapshots will be created for all Replication Pairs that are in the "Replicating" state.

  • Persistence, the ability for the snapshot's integrity to be maintained, no matter the type of shutdown or reboot, is always enabled for Recovery Points.

  • If cluster is used for Recovery Points creation, cluster resources should have persistent binding on.

Consistent Recovery Point for Exchange Data
  • A Consistent Recovery Point can be successfully created for Exchange data, even if the Exchanges Stores are dismounted. If the Stores have been dismounted by the Exchange Server because of corruption, the Consistent Recovery Point will be created anyway, and will contain the corrupt data. Thus, it is essential to be aware of the state of any Stores that have been dismounted at the time a Consistent Recovery Point is created.
Snapshot Space Requirements

It is essential to ensure that the destination volume specified for each Replication Pair has sufficient space for the maximum number of snapshots that will be created and retained.

For VSS, the cache can be configured using the vssadmin add shadowstorage command from a command line prompt. Refer to Microsoft documentation for details. Note that if the specified volume runs out of space, VSS will delete existing snapshots to make room for the new snapshots, even if your specified maximum number of Recovery Points has not been reached.

Loading...