Recovery Points

Topics | How To | Related Topics

Overview

Recovery Points for ContinuousDataReplicator

Recovery Points for the Quick Recovery Agent

License Requirement

Overview

Recovery Points consist of snapshots, either of a QR Volume (when used with Quick Recovery Agent) or a Destination Path (when used with ContinuousDataReplicator.) While there are differences in how Recovery Points are used, depending on the Agent, their purpose is similar; they preserve a point-in-time on the QR Volume, the CDR Source, or the CDR 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.

This illustration provides a high-level look at how data flows when creating Recovery Points with either Agent, and backups of Recovery Points with ContinuousDataReplicator:

Recovery Points for ContinuousDataReplicator

For any replication scenario using ContinuousDataReplicator, snapshot-based Recovery Points can be created, and backed up, affording additional data protection options for recovery of your data. In addition, Recovery Points can be mounted, and for Windows can also be shared, and thus made available to users on the network.

Software and Hardware Requirements for Recovery Points with CDR

To use the Recovery Point feature, the following is required:

Recovery Point Types

There are two types of Recovery Points used with ContinuousDataReplicator:

Consistent Recovery Points for Non-Integrated Applications (CDR on Windows only)

To create a Consistent Recovery Point of application data, it is necessary to quiesce and unquiesce the application server so that the data is in a consistent state, and for supported applications (see Supported Data Types) this is handled seamlessly by CDR. For other applications, it is still possible to effect this through the use of batch files, which you provide, to quiesce and unquiesce the application server. When Consistent Recovery Point creation has been specified for a Replication Set, at the time of creation, CDR will 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. (For more information about how they are created, see Consistent Recovery Point.)

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.

Using Recovery Points with CDR

Note the following when using either type of Recovery Point with ContinuousDataReplicator:

To use Recovery Points with ContinuousDataReplicator, see the following for step-by-step procedures:

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/Post Processes.

See the following for step-by-step procedures for Pre/Post Processes with ContinuousDataReplicator:

Mounting or Sharing Recovery Point Snapshots

The snapshots that comprise a Recovery Points can each be mounted as a volume or mount point on the destination computer, and thus made available to users on the network. In addition, for 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 easily be accessed.

See the following for step-by-step procedures:

note.gif (292 bytes) For CDR on Windows
  • 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 above.
  • 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.

  • 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:

    • 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.

Backups of Recovery Points

Recovery Points can be configured to be backed up automatically when they are created; for CDR on Windows there is no need to mount the snapshots that comprise the Recovery Point in order to back them up; for CDR on UNIX, the snapshots do need to be mounted, but CDR does this automatically. In addition, you can select any existing Recovery Point and perform an immediate full backup on-demand. This backup capability is only available if the source and destination computers have the appropriate File System iDataAgent installed. For more information about installing, configuring, and using File System iDataAgents, see Windows File System or Unix File System.

The following types of backups are supported:

See the following for step-by-step procedures:

note.gif (292 bytes)
  • In the case where you have configured Recovery Points to be backed up when they are created, consider the following:
    • 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 (see Maximum Number of Recovery Points above), and it is thus possible that a Recovery Point will be pruned before the backup delay can be addressed.
    • 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 failed 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.

Deleting Recovery Points

When the maximum number of Recovery Points is reached -- based on the maximum number you specified, or based on the maximum number of recovery points allowed by the system -- they are automatically deleted by the system in the order they were created (oldest first) unless one of the Recovery Points to be deleted is in use, i.e., mounted or shared (for CDR on Windows, in which case the system will stop deleting Recovery Points until the situation is resolved) or mounted and in use (for CDR on UNIX, in which case the system will mark the Recovery Point to be deleted when it is no longer in use.)

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 Using CDR.

Recovering Data from Recovery Points and Backups of Recovery Points

For information about recovering the data that has been replicated, from the Live Copy, Recovery Points, or backups of Recovery Points, see Recover Replicated Data.

Implement Recovery Points Using CDR

The following section provides the steps required to configure and use Recovery Points with ContinuousDataReplicator, 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 using CDR:

  1. Ensure that you have a Feature License for Recovery Points.
  2. Configure CDR Recovery Points.
  3. Create a Recovery Point Using CDR.
  4. Optionally, Mount or Share a Recovery Point Using CDR.
  5. Optionally, Configure CDR for Backups of Recovery Points.
note.gif (292 bytes)

Back to Top

Recovery Points for the Quick Recovery Agent

Using QR Agent with QSnap, you can create Consistent Recovery Points to preserve the states of QR Volumes after incremental updates, providing more protection and flexibility for recovery. (See Overview - QSnap for more information about QSnap.) Without Consistent Recovery Points, recovery is limited to whatever is on your QR Volume after the last update. In addition, your QR Volume is no longer up to date with the source volume if there is a write to the QR Volume between update operations.

With the Recovery Points feature enabled in a QR Policy and with volumes updated incrementally, snapshots of the QR Volume are taken after the first full copy to it from the source and after each succeeding incremental update -- up to the number of Points you specify (maximum: 32). Each snapshot represents a Consistent Recovery Point because it is taken on the QR Volume after incremental updates are added to the volume.

Showing up as snapshots in the Browse QR Volumes window, Consistent Recovery Points can be mounted, shared on a network, or copied back. In addition, Consistent Recovery Points created with QR Agent persist through reboots. See Mount and Unmount QR Volumes and Copy Back a QR Volume for procedures relating to these topics.

Software and Hardware Requirements for Recover Points with QR

To use the Recovery Point feature, the following is required:

Implement Recovery Points Using the Quick Recovery Agent

Experienced QR Agent users: Note the following when implementing Recovery Points with QR Agent:

How to Create Consistent Recovery Points using Quick Recovery Agent

Perform the following tasks to create Consistent Recovery Points using QR Agent:

  1. Ensure that you have a Feature License for Recovery Points.
  2. Use Volume Explorer to detect available volumes, including any new volumes you created.
  3. Create a Scratch Volume Pool.
  4. Create a QR Policy. Select the Enable Recovery Points check box, and type the number of Points (up to a maximum of 32) in the Number of Recovery Points box. (See screen example below these steps.) Also, the Copy Manager must be on the same computer as the QR Volume.
  5. When you click OK in the QR Policy window after enabling Recovery Points, you will be prompted to enter a cache partition for snapshot operations (unless you had set this up when setting up the QR Volume). Note that the cache cannot be on the QR Volume because a volume that contains a live snapshot or live application cannot be locked, and the QR Volume must be locked when writing to it. See the sample QR Policy screen below.
  6. Create a New Subclient.
  7. Create a QR Volume That is Incrementally Updated.

note.gif (292 bytes)

One of the available Advanced Options when you create a QR Volume that is incrementally updated (and when the associated QR Policy has Recovery Points enabled) is the option to mount the latest Recovery Point to a specified mount point. This option, Mount Destination Snap, allows access to the destination snap during the next incremental QR Volume creation job when the destination volume is normally not accessible. This provides uninterrupted access to the destination even during the copy phase of the next incremental QR Volume creation job.

Successful completion of the above tasks causes the system to take and store snapshots of the QR Volume after the first full copy and after each incremental update — up to the number you specified (maximum: 32). These snapshots represent Consistent Recovery Points for your source data.

How to browse Quick Recovery Agent Consistent Recovery Points

Consistent Recovery Points are viewed in the Browse QR Volumes window on the source (production volume), even though the snapshots for the Consistent Recovery Points were taken on the QR Volume. You can right-click a specific Consistent Recovery Point, and choose Details to bring up the Volume Configuration window, which has General, Mount Points, and QR Volume tabs.

note.gif (292 bytes) If you mount a Recovery Point from the Browse QR Volumes window, you can view its contents in Volume Explorer.

How to delete Quick Recovery Agent Consistent Recovery Points

Consistent Recovery Points created with QR Agent are automatically deleted by the system in a FIFO order when the number of points you specified (or the maximum of 32) is reached. For example: if you specify 20 Recovery Points in the QR Policy window, when the system creates the 21st, the first Recovery Point that was created is deleted. Creation of the 22nd Recovery Point causes the second that was created to be deleted, and so on.

QR Agent Recovery Points can also be deleted manually — individually or all at once for a particular QR Volume.

note.gif (292 bytes) Mounted Recovery Points cannot be deleted. If you try to delete a mounted Point, an error message appears.

Recovery

Recovering Consistent Recovery Points Using Quick Recovery Agent

Experienced QR Agent users: Note the following when recovering data from Recovery Points using QR Agent:

Consistent Recovery Points created with the QR Agent are recovered in the Browse QR Volumes window through the Copyback feature; follow the Copy Back a QR Volume procedure. Using Copyback, you can recover both mounted and unmounted Recovery Points.

note.gif (292 bytes) It is possible to copy back to the source volume.

Other Quick Recovery Agent Recovery Options

You can also recover data by manually copying and pasting data from mounted Recovery Points to other volumes.

note.gif (292 bytes) Volume Explorer filters out QR Agent Recovery Points. But if a QR Agent Recovery Point is mounted to a drive letter, a detect operation in Volume Explorer will change the Recovery Point's associated QR volume entry so that both the QR volume's drive letter and the drive letter of the mount point are displayed. For example, if a QR volume is mounted to the J: drive and its associated Recovery Point is mounted to the P: drive, re-detecting volumes in Volume Explorer will show J:;P:; in the mount column.

Best Practices

Keep in mind the following considerations when using the Recovery Points feature with the Quick Recovery Agent:

Back to Top

License Requirements

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.

Back to Top