Topics | How To | Related Topics
Recovery Point Types
How to Set Up Recovery Points
Manage Recovery Points
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.
illustration on the right provides a high-level look at how data flows when
creating Recovery Points and backup of Recovery Points.
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:
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.
Three types of Recovery Points can be used with ContinuousDataReplicator (CDR). They are:
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.
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:
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.
<software installation path>\<Replication Set Name</>_Quiesce.bat
<software installation path>\<Replication Set Name</>_Unquiesce.bat
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:
The following are the prerequisites for implementing Recovery Points.
To perform backups of Recovery Points, the appropriate File System iDataAgent must be installed on both the source and destination computers.
Refer to the following pages for more information on installing the software
This feature requires a Feature License to be available in the CommServe® Server.
Review general license requirements included in License Administration. Also, View All Licenses provides step-by-step instructions on how to view the license information.
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:
See Configure CDR to Replicate Application Data for step-by-step instructions.
See Configure Recovery Points for step-by-step instructions.
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:
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/Post Processes.
See the following for step-by-step procedures for Pre/Post Processes with ContinuousDataReplicator:
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.
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 Maximum Number of Recovery Points.
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.
All Recovery Points can either be scheduled or created on-demand. Consider the following sections for managing Recovery Points.
See the following for step-by-step procedures:
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.
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.
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.
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.
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:
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 step-by-step procedures, see Delete a Recovery Point.
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.
Consider the following when using either type of Recovery Point with CDR.
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.
If Replications Pairs for Oracle log and database replication are configured to use the same destination volume, the actual number of Recovery Points retained will be the number specified in Maximum Number of Recovery Points divided by two, because separate snapshots will be created for the logs and the database. For example, if you have specified 10 as the maximum number of Recovery Points, but use the same destination volume for the logs and database, only 5 Recovery Points will be retained, with 2 snapshots in each.
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.
Back to Top