Topics | How To | Support | Related Topics
| This feature/product/platform is on Extended Support in this release. See Deprecated Features, Products, and Platforms for more information. |
QR Volume with Incremental Updates
QR Volume Creation Considerations
QR Volumes may be created immediately from the CommCell Console, or the QR Volume creation job may be scheduled to run at a later time. It is also possible to define a schedule that creates new QR Volumes on a recurring basis, in which case the Quick Recovery Agent will automatically select the destination volumes from the Scratch Volume Pool.
QR Volume creation is not managed on a per-volume basis. Instead, you must create subclients. The volumes contained in the subclient definition will be synchronized and copied at the same point in time, to ensure the consistency of any application data sets that may span multiple volumes (for example, an Exchange 2000 Storage Group.)
When using the LAN copy manager, only the used blocks of the source disk will be copied to the QR Volumes. For the QR Agent on Unix, this functionality can be turned off, so that even the empty blocks are backed up, by configuring the dDisableDataBlock registry key.
Destination volumes are analogous to the backup media of other agents. For any QR Volume creation job, a destination volume (from the Scratch Volume Pool) may be optionally selected for each of the primary volumes in the subclient. The destination should be at least slightly larger than the source volume. If you do not select a destination volume, the Quick Recovery Agent will do so automatically. Likewise, a destination mount point may be specified for each QR Volume. If mount points are not specified, the newly created QR Volumes will remain unmounted until you request otherwise.
For SnapVault, if a destination volume is not selected, the system will choose one from the scratch volume pool according to the following criteria:
If more than one destination meets these criteria, then the smallest destination is chosen. This does not ensure that the destination volume will not run out of space. If a destination has multiple replicas, the space used by each can grow over time. Note that you can change the default behavior for choosing destination volumes for SnapVault by changing the sFindTargetVolUsingFreeSpace value in the registry.
Normally, each volume in a subclient is automatically assigned to its own destination volume; however for SnapVault, there is not a one to one relationship between source and destination volumes. If you create a SnapVault subclient that contains multiple volumes, and do not specify destination volumes, the snapshots for all of the volumes could reside on one destination volume (provided there is sufficient space).
When creating QR Volumes that take advantage of the agent's application intelligence, subclients must be configured correctly to successfully recover an application volume. See the following for more information on setting up a subclient for QR Volume Creation:
A full QR Volume creation operation creates a QR Volume that contains all the data associated with a subclient. QR Volumes for any subclient start with a full QR Volume Creation (i.e., all of the data is copied to the QR Volume). If you select Incremental Update as your QR Volume creation option, the first operation will be a full QR Volume creation, which becomes the baseline to which subsequent Incremental Updates are applied; in this scenario, once the Full QR Volume creation has completed, the next operation will be an incremental update.
The purpose and process of creating a QR Volume with incremental updates are very similar to those of an ordinary QR Volume. However, certain restrictions apply to incremental update jobs:
Software compression is available for QR Volumes created over a LAN copy manager and is enabled or disabled at the subclient level. The data is compressed on the source client before it is copied to the destination volume. Enabling compression typically reduces the amount of network bandwidth required to copy the data; however, it introduces a computational load on the source client. Before the data is written to the destination volume, it is decompressed.
In some cases it is possible to create only a snapshot, without creating a QR Volume. See Support Information - QR Volume Creation Options for information on supported configurations. Snapshots are not backups of the data, and have unique functionality and requirements. See Snapshots for more information on the behavior of snapshots.
The process of creating a new QR Volume consists of seven phases:
Note that when using snapshot engines other than QSnap for Windows, the phases for QR Volume creation may vary. The phases for creating a QR Volume with QSnap for Windows are described below.
In the Snapshot phase, the agent synchronizes with the applications and the operating system to ensure that all data is flushed to disk. Furthermore, it ensures that the source or primary disk image is not modified for the duration of the volume copy phase, so that the destination disk (i.e. the QR Volume) contains a consistent image.
The QR Agent will check the Scratch Volume Pool for eligible destination volumes before creating the snapshot. Ensuring that there is an eligible destination volume prevents unnecessary snapshots.
To dismount or lock the primary volume throughout the copy would require an unacceptable period of downtime for the application. Instead, the QR Agent invokes an external snapshot mechanism to create a frozen, point-in-time image of the primary volume. Once the snapshot image has been created, the application may be resumed immediately and continue to update the primary volume while the copy operation is in progress. The data is copied out of a snapshot cache. The QR Agent no longer needs to freeze the snapshot cache during the QR Volume Creation phase (see below). This reduces job failures caused by the QR Agent waiting to freeze the cache.
The use of a volume snapshot ensures that file system and application metadata remain unchanged, and therefore consistent, during the copy operation. Before creating the snapshot, the agent ensures that any supported applications have been ordered to flush buffered data and to suspend I/O to the disk (if necessary). Once the snapshot has been created, the agent signals to the application that it may resume operations. The Quick Recovery Agent is designed to accommodate a variety of external snapshot engines, including both hardware and software implementations.
The Quick Recovery Agent provides for optional PreSnap and PostSnap phases. In these phases, the agent can run a user-supplied command line or script to perform any additional processing that is required - for example, to synchronize with an application that is not yet directly supported by the agent.
In the QR Volume Creation phase, the Quick Recovery Agent will perform a block level copy of the data from the source disk to the destination disk (which will become the QR Volume). Depending on the QR Policy that you have selected, the copy phases will use a LAN Copy Manager to effect the data transfer.On the Windows platform, the QR Agent now zeroes out the boot sector of the destination volume so when the computer is brought back on-line, no changes will be made to the volume (keeping it consistent with the QR Volume).
The Quick Recovery Agent allows for optional PreCopy and PostCopy phases. In these phases, you may supply custom command lines or scripts, which the agent will invoke before and after the QR Volume Creation phase.
In the final phase, the Quick Recovery Agent deletes the snapshot that was created during the Snap phase, so that the resources are available for future QR Volume operations.
Before performing any QR Volume procedures for this agent, review the following information:
| If you create a QR Volume with a Recovery Point and mount it to a drive letter, and then try to run expandfs.exe on the QR Volume, you may get a General Protection Fault error. |
Restartability is supported for QR Volume creation on Windows platforms. See QR Volume Creation Restartability for more information.
If a replica for the same source volume is attempted to the same destination volume having one of these replicas, the transfer will fail because the replica is already there. If this is the case, you must manually delete the SnapVault relationship or create the registry string value sUseExistingReplica in the ReplicationIDAAgent key and set it to y, causing the software to consider the error that the replica is already there as a successful full transfer. The replica is not updated in this case so it is not in sync with any other replicas; therefore, an incremental transfer should be run after the job completes. This registry key should be removed after the job completes to insure proper error checking.
When Exchange is added to the contents of a subclient, all volumes associated with the application are added to the subclient. These Exchange volumes can be recovered at the storage group level. In order to recover at the storage group level, consider the following:
It is recommended that each database instance volume be associated with its own subclient. When you add the application to the subclient, all volumes will added to the subclient content. The volumes for the other instances should be deleted from subclient contents. See the help for instructions on modifying subclient content. This configuration has several advantages:
| If you have added or removed any data files or log files to an Oracle database, the changes need to be detected by re-adding the application to subclient contents or by creating a new subclient for the instance. |
Configurations with data files, archive logs and control files from multiple instances on the same volume are not supported by the QR Agent.
Password and initialization (initsid.ora, orapwsid) files are not copied by the QR Agent to the QR Volume. If they are required for a particular recovery scenario, create this files prior to recovery.
If you plan to configure Oracle database destination volumes as unmounted, see this Note regarding recovery.
When SQL is added to the contents of a subclient, all volumes associated with the application are added to the subclient. This includes all user-defined databases and resources. System databases are filtered out of the subclient contents by the QR Agent and should not be subclient contents.
These SQL volumes can be recovered at both the instance and database level. In order to recover SQL at the database level, consider the following:
If application data is moved, the subclient contents must be redefined (i.e., the application volumes must be redetected and added to the subclient contents) and a QR Volume creation operation performed.
Once application data or resources have moved, the QR Agent cannot automatically recover the existing QR Volumes. If a QR Volume creation operation cannot be run after application data or resources have been moved, the existing QR Volumes can be mounted manually. This is not recommended; applications will not be quiesced by the QR Agent, and integrity of the recovered data cannot be guaranteed.
The QR Volume Creation Job Summary Report provides a summary of QR volume creation operations for each client.