About checking the integrity of DVM repositories
In AppAssure release 5.3.6 and earlier releases, replication included the process of copying recovery points from the source Core to the target Core regularly. Rollup of aging recovery points occurred only at the source Core. Combined older recovery points were synchronized daily when running the nightly job.
Starting with AppAssure version 5.4.1 and in current releases of Rapid Recovery Core, users can to set disparate retention policies between source and target Cores. For replication to work properly with different retention policies, the target Core must have the same software version (or newer) than the source Core.
Administrators can now configure rollup on a target Core at a different rate than on the source Core. Similarly, you can now define a custom retention policy for any replicated machine. For example, you can roll up recovery points in the target Core at a faster rate and with less granularity than on the source Core, saving space. Or you can roll up recovery points for any selected replicated machine at a slower rate in the target Core, maintaining more granularity, which may be useful for compliance purposes. For more information on using a retention policy that differs from the default in the Core, see Customizing retention policy settings for a protected machine.
Some customers experienced inconsistencies in recovery points that were replicated to a target Core prior to AppAssure release 5.3.6. To address this issue, AppAssure release 5.4.1 and later include a Core job to run on each DVM repository. Quest recommends performing the Integrity Check job a single time on each DVM repository on a replicated target Core if the repository was created prior to release 5.4.x (if it was created in release 5.3.x or earlier).
For instructions on how to perform this check, see the procedure Performing an integrity check on a DVM repository.
The Integrity Check job will not be available:
- On a new DVM repository on a target Core created in AppAssure release 5.4.1 or later or created in Rapid Recovery.
- On a source Core.
- If you have already run the Integrity Check Job (or Check Repository Job) on this repository.
- If you have not used replication.
If your Core has been upgraded at any point from AppAssure 5.3.x and you used replication, you must run this job before you can configure dissimilar retention policies between the source Core and a target Core, or configure a custom retention policy on a replicated machine.
You will not see or be able to run this job unless you have one or more eligible repositories (created prior to 5.4.x and not yet performed).
Running this job verifies the integrity of all data stored in the specified repository, ensuring you can recover data from each snapshot or base image. If the integrity check discovers any issue with data in your repository, the job ceases immediately. The event details for that job on the Core prompt you to contact Quest Data Protection Support, so you can schedule time to work with a Support representative to perform additional procedures to identify and remediate data inconsistencies.
|
|
Caution: Running this job is expected to take an extended period of time. The amount of time differs based on the amount and type of data in your repository, and on the underlying storage system. While the job is running, no other transactions can be performed in that repository, including transfers (snapshot and base image backups, and replication), nightly jobs, and so on. |
You can perform other operations in other repositories while this job is running.
|
|
NOTE: This job checks the integrity of all of the contents within a repository. For information about the |
Performing an integrity check on a DVM repository
An integrity check is available for DVM repositories. The purpose of this procedure is to check the integrity of an entire DVM repository. During the execution of the integrity check, which can be lengthy, no other actions can be performed in the repository.
If you have multiple DVM repositories for a target Core, perform this process once for each repository.
|
|
NOTE: If you have another DVM repository on the target Core for which the Checking Repository job has already been completed, or if you create a new additional repository for this target Core, you can perform operations in that secondary repository while the Checking Repository job is running on the DVM repository you specified. |
- Navigate to the Rapid Recovery Core Console.
- On the icon bar, click
(More), and then select
Repositories.
The Repositories page displays.
- In the DVM Repositories summary table, from the row representing the DVM repository that you want to check, click
(More options) and from the drop-down menu, select Check Repository.
A confirmation message appears.
Caution: Before you confirm that you want to perform the job, you should carefully consider the duration of time required. While the job is running, no other transactions can be performed in that repository, including transfers (snapshot and base image backups, and replication), nightly jobs, and so on.
- From the Check Repository dialog box, to perform the integrity check, click Yes.
The dialog box closes. Any jobs that were queued or that are in progress are canceled, and the integrity check job begins.
- To monitor the progress of the Integrity Check job for a repository, including a determination of whether additional steps are required after the check, from the icon bar, click
(Events).
- From the Tasks page, click
Job Details for the job to view more information about the job status.
- If you see an error in any child tasks for this job, note the error and provide the information to a Quest technical support representative.
- If the Integrity Check job completes all child tasks successfully, you can then establish a custom retention policy for this repository.
About DVM repository optimization
When using a DVM repository, the data you capture in each snapshot is deduplicated. This deduplication occurs incrementally, as snapshots are saved to the repository. One occurrence of each string of information is saved to the repository. When an information string is duplicated, a reference to the original string in the deduplication cache is used, saving storage space in the repository.
If the DVM deduplication cache is filled, only snapshot data that is already referenced in the cache is deduplicated. As deduplication occurs, the cache continues to update with new unique values, overwriting the oldest values in the cache. This results in less than optimal deduplication.
For more information about deduplication, see Understanding deduplication cache and storage locations.
You can choose to increase your DVM duplication cache before it is full, which ensures continued optimal deduplication of your data in that repository. For more information, see Configuring DVM deduplication cache settings.
You can also increase your deduplication cache after it is full. If you want to reclaim space in the repository after increasing your cache, you can optimize the repository. This action forces a comparison of the data in your snapshots to the information in the deduplication cache. If any repeated strings are found in the repository, that data is replaced with references to the data, which saves storage space in the repository. This is sometimes referred to as off-line deduplication, since this deduplication process occurs upon your request, instead of incrementally as snapshot data is transferred.
The optimization process is processor-intensive. The amount of time it takes to run this job depends on several factors. These factors include the size of your repository; the amount of data in your repository; available network bandwidth; and existing load on the input and output of your system. The more data in your repository, the longer this job runs.
The following actions are superseded or canceled when the Repository Optimization Job is occurring.
- Delete All Recovery Points Job
- Delete Recovery Points Chain Job
- Maintain Repository Job
- Delete Recovery Points Job Base
- Optimize Repository Job
For steps on optimizing an existing DVM repository, see Optimizing a DVM repository.
You can interrupt the Optimize Repository job for a limited time if required. For more information, see Interrupting or resuming DVM repository optimization.
Optimizing a DVM repository
You must have a DVM repostiory in your Core to perform this procedure.
You can perform offline deduplication of data saved to an existing DVM repository. This is accomplished by launching the Repository Optimization Job.
|
|
NOTE: Quest recommends performing the Optimize Repository job only after increasing your deduplication cache size. This action lets you reclaim repository space and more effectively use the DVM deduplication cache. |
Complete the steps in this procedure to optimize a DVM repository.
- Navigate to the Rapid Recovery Core Console.
- On the icon bar, click
The Repositories page appears.
- In the DVM Repositories pane, from the row representing the repository you want to optimize, click
(More options) and then select Optimize.
A warning prompt appears asking you to confirm the optimization.
- To confirm the optimization, click Yes.
The optimization job takes precedence over most other jobs. If necessary, you can interrupt an optimization job in progress. For more information on interrupting or resuming this job, see Interrupting or resuming DVM repository optimization.