This process describes how to create a repository on your Core using the Deduplication Volume Manager (DVM) repository technology.
Complete the following steps to create a DVM repository.
The Repositories page displays.
The Create Repository Wizard appears.
Text Box | Description |
---|---|
Name | Enter the display name of the repository.
By default, this text box consists of the word Repository and a number, which corresponds to the number of repositories for this Core. For example, if this is the first repository, the default name is Repository 1. Change the name as needed. Repository names must contain between 1 and 40 alphanumeric characters, including spaces. Do not use prohibited charactersor prohibited phrases. |
Concurrent operations |
Define the number of concurrent requests you want the repository to support. By default the value is 64. |
Comments |
Optionally, enter a descriptive note about this repository. You can enter up to 254 characters. Examples might include a message such as DVM Repository 2 or This repository contains protected SQL Server data only. |
The Storage Location page displays.
NOTE: Rapid Recovery employs space-saving deduplication functionality that can conflict with anti-virus software, resulting in repositories with inaccessible data. For more information, refer to Quest Knowledge Base article 117506, "Software conflicts wtih AppAssure and Rapid Recovery." |
Quest strongly recommends specifying a dedicated folder within the storage drive or volume to store data files. For example, to store your repository data on the E drive, specify E:\Repository\Data. To store your repository data on a CIFS drive, specify \\servername\repository\data.
Caution: If you define the location for your repository data at the root of the selected volume (for example, E:\ or \\servername) instead of in a dedicated folder, then if you subsequently remove the repository, other files and data stored in that root folder are deleted, which could result in catastrophic data loss. |
When specifying the path, use only alphanumeric characters, the hyphen, and the period (only to separate host names and domains). You can use the backslash character only to define levels in the path. Do not use spaces. No other symbols or punctuation characters are permitted.
If you specified a path for a local storage location, skip to step d.
Optionally, to save your credentials to Credentials Vault, click the plus sign next to the text box. For more information, see Credentials Vault.
For example, type X:\Repository\Metadata.
When specifying the path, use only alphanumeric characters, the hyphen, and the period (only to separate host names and domains). The letters a to z are case-insensitive. Do not use spaces. No other symbols or punctuation characters are permitted.
Text Box | Description | ||
---|---|---|---|
Bytes per sector |
Specify the number of bytes you want each sector to include. The default value is 512.
| ||
Average bytes per record |
Specify the average number of bytes per record. The default value is 8192. | ||
Write caching policy |
The write caching policy controls how the Windows Cache Manager is used in the repository and helps to tune the repository for optimal performance on different configurations. Set the value to one of the following:
|
The Space Allocation page displays.
The Create Repository Wizard closes, and Rapid Recovery applies the settings to your Core. If Toast alerts are enabled, you see messages indicating that repository creation has started, and the repository is mounted. Alternatively, you can monitor the progress of the repository creation by viewing alerts on the Events page.
A DVM repository must exist in your repository to perform this procedure.
Adding a storage location to a DVM repository lets you define where you want the repository or volume to be stored.
Complete the steps in the following procedure to specify the storage location for the repository or volume.
The Repositories page appears.
The DVM Repositories pane appears.
The Add Storage Location dialog box displays.
Text Box | Description |
---|---|
Data path | Enter the location for storing the protected data.
For example, type The same limitations to the path apply; use only alphanumeric characters, hyphen, or period, with no spaces or special characters. |
Metadata path | Enter the location for storing the protected metadata.
For example, type When specifying the path, use only alphanumeric characters, the hyphen, and the period (only to separate host names and domains). The letters a to z are case-insensitive. Do not use spaces. No other symbols or punctuation characters are permitted. |
Text Box | Description |
---|---|
UNC Path |
Enter the path for the network share location. If this location is at the root, define a dedicated folder name (for example, The path must begin with \\. When specifying the path, use only alphanumeric characters, the hyphen, and the period (only to separate host names and domains). The letters a to z are case-insensitive. Do not use spaces. No other symbols or punctuation characters are permitted. |
User Name |
Specify a user name for accessing the network share location. |
Password |
Specify a password for accessing the network share location. |
Text Box | Description | ||||
---|---|---|---|---|---|
Size |
Set the size or capacity for the storage location. The default size is 250 GB. You can choose from the following:
| ||||
Write caching policy |
The write caching policy controls how the Windows Cache Manager is used in the repository and helps to tune the repository for optimal performance on different configurations.
Set the value to one of the following:
| ||||
Bytes per sector |
Specify the number of bytes you want each sector to include. The default value is 512.
| ||||
Average bytes per record |
Specify the average number of bytes per record. The default value is 8192. |
|
Caution: Performing a Repository Optimization Job could take a substantial amount of time and bandwidth in your environment, based on factors such as the size of your repository, amount of data in your repository, available network bandwidth, and existing load on the input and output of your system. The only suggested use case for running this job is if your DVM deduplication cache was full and you subsequently increased the cache size. |
For more information about the repository optimization job, see About DVM repository optimization.
The dialog box closes and the storage location is saved. In the repositories summary table, the storage location you created is visible if you expand the repository details.
This procedure assumes that your Core is already using at least one DVM repository.
In the settings for a DVM repository, you can change such settings as number of concurrent operations, and enabling or disabling deduplication or compression.
Complete the following task to change the available settings for a DVM repository.
The Repository Settings dialog displays.
Option | Description |
---|---|
Maximum concurrent operations | The number of jobs that the repository can perform at one time. The default is 64. |
Description | Can contain and display notes or a description that you want to associate with this repository. |
Enable deduplication |
When this option is selected, Rapid Recovery Core deduplicates data so that only unique blocks are saved to the repository. This setting is enabled by default. Clear this option and save to disable deduplication. |
Enable compression |
When this option is selected, Rapid Recovery Core compresses data to reduce space used. This setting is enabled by default. Clear this option and save to disable compression. |
The changes are applied to the repository.
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:
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 |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center