This section describes how to work with repositories. It discusses the features and attributes of the repository technology supported by Rapid Recovery release 6.9, 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:
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.
There are two types of repositories you can use for storing Rapid Recovery recovery points. Deduplication Volume Manager (DVM) is a Rapid Recovery technology and can be installed on the Rapid Recovery Core using the Core Console, the Command Line utility, or PowerShell. You can use it to store original recovery points or recovery points replicated from another Core. Azure repositories originate from Microsoft Azure. You can connect one Azure repository at a time to a single Rapid Recovery Core and use it to store replicated recovery points.
|
|
NOTE: Quest discourages using an Azure repository for storing original recovery points and recommends using it only for storing replicated recovery points. For more information, see Replication with Rapid Recovery. |
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.
DVM repositories
A Rapid Recovery administrator can create a DVM 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.
If installing on a NAS, Quest recommends limiting the repository size to 6TB when using the CIFS protocol, since CIFS is not designed as a high-I/O storage protocol. Any storage device must meet the minimum input/output requirements. For these requirements, and for additional guidance for sizing your hardware, software, memory, storage, and network requirements, see the Rapid Recovery Sizing Guide. |
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 for each host
- No additional services required; DVM repository uses system-provided 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.
Azure repositories
A Rapid Recovery administrator can add one Azure repository to each Rapid Recovery Core. This repository best serves as a secondary destination on a replication target core. The contents of the repository can come only from another source Core, not the same Core to which it is attached.
|
|
NOTE: Currently, the Rapid Recovery Core Console lets you connect to an Azure repository only from the source Core that replicates to it, and does not support the Connect to Existing feature. For more information, see https://support.quest.com/kb/332647. |
Azure stores this type of repository under Blob Containers. The contents of the Azure repository are only accessible from a Rapid Recovery Core. While the files may be visible from the Azure user interface, only Rapid Recovery can open them.
The following list describes features of an Azure repository:
- Used as secondary storage on a replication target Core
- Azure repositories are created and managed from the Rapid Recovery Core Console
- You can specify the size of an Azure repository, and then reduce and extend the size of the repository at any time
- You can create an Azure repository on a machine with Windows operating systems only
- Requires 8GB RAM, preferably Error Checking and Correction (ECC) memory Rapid Recovery Core requirement)
- Requires quad core processor on Core machine
- Supports one Azure repository for each Core
- No additional services required; an Azure repository uses system-provided Core services for communication with Core and for tracking events
- 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 deduplication cache, with a configurable storage location in Core settings
- Cannot be renamed after creation
As with DVM, the recovery points in the Azure repository are compressed and deduplicated. For Azure, this process requires a location for deduplication cache and a location for metadata cache. You have the option to store the cache locally or in Azure, but you must store the metadata on your local machine.
Unlike with DVM, which has pre-allocated storage space that you can increase but not decrease, you can change the size of an Azure repository to be larger or smaller at any time. When you configure the Azure repository in Rapid Recovery, you set a space limitation that tells Rapid Recovery not to send more data after the contents exceed that amount, but you can reduce or increase the limitation at any time. For example, in Repository Settings, if you set the Azure repository to store no more than 1TB of data but you discover you need less than half that amount, you can reduce the maximum size of the Azure repository to 500GB.
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 repository optimization. For more information about performing this task, see Optimizing a 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 involves the following operations:
- Creating a DVM repository. Before creating a repository, consider the appropriate technology type.
- Connecting to a repository. For more information about connecting to an existing repository currently managed by another Core, see Connecting to an existing repository.
- Checking a repository. For more information about checking a DVM repository, see Checking a repository.
- Modifying repository details. For more information about viewing repository details or modifying the details that display, see Viewing or modifying repository details.
- Changing repository settings. For more information about changing the settings for a DVM repository, see Changing DVM repository settings.
- Performing DVM repository optimization. For more information about the repository optimization job, see About repository optimization. For steps to optimize an existing DVM repository, see Optimizing a repository.
- Deleting a repository. For more information about deleting a repository, see Deleting a repository.
