Repositories
This section describes how to work with repositories. It discusses the features and attributes of the repository technology supported by Rapid Recovery release 6.5, called Deduplication Volume Manager (DVM). It briefly describes deduplication used in Rapid Recovery. Then this section describes how to manage DVM repositories, including creating a repository, viewing and editing its details, and deleting a repository. You can learn how to open a repository from one Core on another Core.
Topics include:
Understanding repositories
A repository is a data structure used to store and manage Rapid Recovery data. Backup snapshots are saved to a repository in the form of recovery points. Before you can protect machines, replicate, or restore data in Rapid Recovery, you need at least one repository.
Deduplication Volume Manager (DVM) is native to Rapid Recovery and can be installed on the Rapid Recovery Core using the Core Console, the Command Line utility, or PowerShell.
On the Repositories page, you can create a new repository, or connect your Core to an existing repository (currently used by another Core). In general, you can view details for a repository, view repository settings, check a repository, or delete a repository, as well as add a storage location or optimize a repository. For more information about managing a repository, including how to create one, see Managing a DVM repository.
A Rapid Recovery administrator explicitly creates a DVM repository within a storage location (a disk volume) associated with a specific Core. You can create a repository from the UI, or from the command line. From the Rapid Recovery Core Console, you can create a new repository of either type. When protecting a machine, you can also define a DVM repository as an advanced step in the wizard workflow.
A repository can reside on different storage technologies, including Direct Attached Storage (DAS), Storage Area Network (SAN), or Network Attached Storage (NAS).
|
|
NOTE: When designating a location for a Rapid Recovery repository, speed for the storage volume is the most critical factor. Archival storage devices such as Data Domain are not supported due to performance limitations. Do not store repositories on NAS filers that tier to the cloud, as these devices tend to have performance limitations. DAS offers the highest data bandwidth and fastest access rate, and is easy to implement. For optimum results, use DAS with Redundant Array of Independent Disks (RAID) 6 storage. |
The storage location for a DVM repository should always be in a subdirectory that you specify (for example, E:\Repository), never in the root of a volume (for example, E:\).
The following list describes the features of the DVM repository type:
- DVM repositories are created and managed from the Rapid Recovery Core Console.
- DVM repositories support multiple volumes, up to 255 repositories on a single Core.
- You can specify the size of a DVM repository upon creation, and can add extents later.
- Once you specify the size of a repository, its size cannot be reduced later.
- You can create DVM repositories on machines with Windows operating systems only.
- DVM repository volume can be local (on storage attached to the Core server), or on a storage location on a Common Internet File System (CIFS) shared location.
- You can use this repository type when upgrading existing AppAssure installations, and when using new Rapid Recovery installations.
- DVM repositories can span across different storage technologies.
- Supported storage types include Storage Area Network (SAN), Direct Attached Storage (DAS), or Network Attached Storage (NAS)
- Requires 8GB RAM, preferably Error Checking and Correction (ECC) memory Rapid Recovery Core requirement)
- Requires quad core processor on Core machine
- Supports multiple DVM repositories per host
- No additional services required; DVM repository uses native Core services for communication with Core and for tracking events
- Each DVM repository supports up to 4096 repository extents (also called storage locations)
- Fixed size; DVM repository requires you to specify the repository size on a volume. The size that you specify cannot exceed the size of the volume. Each volume you define as a storage location must have a minimum of 1GB of free space available on it.
- Repository storage location can be a simple or dynamic disk, with speed the most important factor
- Can use standard encryption keys created and managed in the Core Console (Core-based encryption)
- Deduplicates data across the entire repository (or across encryption domains within each repository, if encryption keys are used)
- Uses a dedicated, resizeable DVM deduplication cache, with a configurable storage location in Core settings
- Optimized for writing data, storing snapshot data in a repository local to the Core, with all data processed through the Core
- Cannot be renamed after creation
- New repositories of this type can be created using REST APIs, the Rapid Recovery Command Line Management Utility (cmdutil.exe), or Windows PowerShell cmdlet
When you create a DVM repository, the Rapid Recovery Core pre-allocates the storage space required for the data and metadata in the specified location. The minimum DVM repository size is 1GB, which for practical purposes is too small except for testing.
Since DVM deduplication requires a primary and secondary cache, ensure the storage space you reserve is twice the size of your deduplication cache. For example, if you have 1.5GB reserved in the DVM deduplication cache settings on the Core, reserve 3GB on the cache volume. The default installation path for the cache is on the C drive. For more information, see Understanding deduplication cache and storage locations.
Deduplication in Rapid Recovery
Deduplication is a data compression technique that reduces both storage requirements and network load. The process involves physically storing unique blocks of data only once on disk. In Rapid Recovery, when any unique data block occurs a second time within a repository, instead of storing the data again, the Core stores a reference to the first occurrence of the data in the repository. When the information is needed (for example, when restoring), the Core retrieves the data by following the references and reconstructing the original data stream.
Deduplication occurs in backup snapshots captured by Rapid Recovery Core.
- Backup information is deduplicated within a single repository. It cannot be deduplicated across multiple repositories.
- DVM repositories use target-based encryption, in which deduplication is further limited to the data protected with a single encryption key. For security purposes, each key serves as a separate encryption domain.
For maximum gains, Rapid Recovery uses different types of deduplication, as described in the following sections.
When deduplication occurs
DVM technology uses target-based deduplication.
Target-based deduplication can take place inline (during the transfer of backup information), or as post-processing (occurring on the repository). Post-processing is sometimes called pass-through deduplication.
As for when deduplication occurs, standard deduplication occurs inline.
Rapid Recovery also uses post-processing in one instance: when performing a repository optimization job. This feature is also called duplicate block reclamation.
For more information about the repository optimization job, see About DVM repository optimization. For more information about performing this task, see Optimizing a DVM repository.
Thus, Rapid Recovery takes advantage of target-based deduplication, inline deduplication, and post-processing deduplication.
For more information about where the references to unique blocks are stored for DVM repositories, see Understanding deduplication cache and storage locations. For information about adjusting DVM deduplication cache settings, see Configuring DVM deduplication cache settings.
Managing a DVM repository
Managing a DVM repository involves the following operations:
- Creating a DVM repository. Before creating a repository, consider the appropriate technology type.
For information about the different repository types, see Understanding repositories.
For information about creating a DVM repository, see Creating a DVM repository.
- Connecting to a repository. For more information about connecting to an existing repository currently managed by another Core, see Connecting to an existing repository.
- Adding a new storage location. For more information on adding a new storage location to a DVM repository, see Adding a storage location to an existing DVM repository.
- Checking a repository. For more information about checking a DVM repository, see Checking a repository.
- Modifying repository settings. For more information about viewing repository details or modifying settings for a repository, see Viewing or modifying repository details.
- Performing DVM repository optimization. For more information about the repository optimization job, see About DVM repository optimization. For steps to optimize an existing DVM repository, see Optimizing a DVM repository.
- Deleting a repository. For more information about deleting a repository, see Deleting a repository.