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.
The
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:
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.
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:
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 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.
The destination computer must meet the
System Requirements for ContinuousDataReplicator.
If you are using destination for Recovery Point creation, the destination computer
must also meet the requirements for VSS or ONTAP.
CDR software must be installed on the destination computer. If you are using
QSnap for Recovery Point creation (Unix) or planning to create Consistent Recovery
Points with Exchange Mining option enabled (Windows), QSnap software must also
be installed on the destination computer as well.
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
To use VSS writers for online quiesce of the Exchange Server or SQL Server
on the source during the creation of Consistent Recovery Points, the VSS
Provider for CDR must be installed on the source computer.
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:
If you wish to configure Consistent Recovery Points, you must first configure
CDR to replicate data.
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.
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.
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, 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.
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.
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:
Maximum Number of 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.
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
Linux with QSnap: 32
Solaris with QSnap: 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.
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.
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.
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.
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.
The
illustration on the right provides a high-level look at how data flows when
creating Recovery Points and backup of Recovery Points.