Chat now with support
Chat with Support

Rapid Recovery 6.2 - User Guide

Introduction to Rapid Recovery Core Console Core settings
Core settings key functions Rapid Recovery Core settings Core-level tools
Repositories Managing privacy Encryption Protecting machines
About protecting machines with Rapid Recovery Understanding the Rapid Recovery Agent software installer Deploying Agent to multiple machines simultaneously from the Core Console Using the Deploy Agent Software Wizard to deploy to one or more machines Modifying deploy settings Understanding protection schedules Protecting a machine About protecting multiple machines Enabling application support Settings and functions for protected Exchange servers Settings and functions for protected SQL servers
Managing protected machines Snapshots and recovery points Replication Events Reporting VM export Restoring data Bare metal restore
Bare metal restore for Windows machines Understanding boot CD creation for Windows machines Using the Universal Recovery Console for a BMR Performing a bare metal restore for Linux machines Verifying a bare metal restore
Managing aging data Archiving Cloud accounts The Local Mount Utility Core Console references REST APIs About us Glossary

Downloading and viewing the Core log file

If you encounter any errors or issues with the Core, you can download the Core logs to view them or to share them with your Quest Support representative.

2.
On the Download Core Log page, click [Download]Click here to begin the download.
3.
If prompted to open or save the Core AppRecovery.log file, click Save.
4.
If you see the Opening Core AppRecovery.log dialog box, do one of the following:
To open the log file, select Open with, then select an application (such as Notepad) for viewing the text-based log file, and finally click OK.

The Core AppRecovery.log file opens in the selected application.

To save the file locally, select Save File and click OK.

The Core AppRecovery.log file saves to your Downloads folder. It can be opened using any text editor.

Repositories

This section describes how to work with repositories supported by Rapid Recovery. It discusses the features and attributes of the primary repository type (Deduplication Volume Manager or DVM ), and the secondary type (a tiering repository). It describes types of deduplication used in Rapid Recovery, and how deduplication is used throughout the application. Then this section describes how to manage DVM and tiering repositories, including creating a repository, viewing and editing its details, and deleting a repository. You also 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.

A Rapid Recovery administrator explicitly creates a 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 primary DVM repository, or a secondary tiering repository. When protecting a machine, you can also define a DVM repository as an advanced step in the wizard workflow.

From the Repositories page of the Rapid Recovery Core Console, 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. DVM repositories let you add a storage location or optimize a repository. Tiering repositories let you disconnect from the machine hosting the repository. For more information about managing a specific repository type, see Managing a DVM repository or Managing a tiering repository, respectively.

A repository can reside on different storage technologies, including Direct Attached Storage (DAS), Storage Area Network (SAN), or Network Attached Storage (NAS).

NOTE: Store Rapid Recovery repositories on primary storage devices. Speed for the storage volume is the most critical factor. Archival storage devices such as Data Domain are not supported due to performance limitations. Similarly, do not store repositories on NAS filers that tier to the cloud, as these devices tend to have performance limitations when used as primary storage.

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. For more information, see Quest Knowledge Base article 118153, Repository Options: Direct Attached Storage, Storage Area Network or Network Attached Storage.

The storage location for a primary 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:\). When creating a tiering repository, you cannot specify a directory, but you can specify a container. You can select the default container or create a new one.

DVM repositories are used for primary storage, in which recovery points are saved by the Core directly to the specified storage devices.

Tiering repositories are used for secondary storage. In this model, recovery points are relocated from a primary DVM repository into a secondary storage volume that you specify. Once copied and verified, the recovery points are removed from the primary repository, making room for more backup data.

NOTE: For release 6.2, tiering repositories are only supported on Quest DR series backup and deduplication appliances.

You can have any combination of DVM and tiering repositories defined for a single Core. If both repository types have been added to your Core, the Repositories page shows a separate pane listing each type separately. Primary repositories are listed first, followed by tiering (secondary) repositories.

The following section describes the features of each repository type supported by Rapid Recovery.

DVM repository. This repository format uses Deduplication Volume Manager (DVM).

You can use this repository type when upgrading existing AppAssure installations, and when using new Rapid Recovery installations.
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.

Tiering repository. The tiering repository was introduced in Rapid Recovery release 6.1.

Existing recovery points (aged 1 week or older) that are not yet designated for archiving can be relocated from your primary Rapid Recovery DVM repository. This feature is enabled through the retention period.
Currently, tiering repositories are only supported on the Quest DR series backup and deduplication appliance version 4.0.

Regarding interoperability, recovery points saved in primary DVM repositories can be tiered to a secondary repository. Since the DR appliances that support tiering use a CentOS operating system, DVM repositories are not supported on those appliances.

Using physical or virtual appliances for repository storage

If using Rapid Recovery on a Quest DL4300 backup and recovery appliance, you can create DVM and tiering repositories. In release 6.2, the tiering repository must be stored on a DR backup and deduplication appliance running operating system 4.0.

Tiering repositories managed on the DL use capacity licenses. Therefore, while it is possible to tier recovery points from your DVM repository associated with a DL appliance to secondary storage on a DR appliance, the space consumed for those recovery points counts against your DL capacity. It is therefore more cost-effective to archive recovery points from a DL appliance, and store the archives on the DR.

No other storage, backup, recovery, or deduplication appliances are explicitly tested for use with Rapid Recovery. Proceed at your own risk.

The Virtual DR2000v can be used for a tiering repository, providing it has the correct RDS services installed and runs operating system 4.0. Other virtual appliances are not yet supported in Rapid Recovery Core release 6.2.

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 primary repository, instead of storing the data again, the Core stores a virtual reference to the data in the repository.

Deduplication occurs in backup snapshots captured by Rapid Recovery Core .

If the deduplication cache becomes full, deduplication becomes suboptimal. In this case, deduplication can be run as a post-process (also known as block reclamation). After increasing the size fo the deduplication cache, run the repository optimization job. Thereafter, the Core will reclaim blocks, providing more space in your repository.

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 all types of deduplication described here: 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.

Related Documents