Chat now with support
Chat with Support

Rapid Recovery 6.1.2 - User Guide

Introduction to Rapid Recovery Core Console Core settings Repositories Encryption keys Protecting machines
About protecting machines with Rapid Recovery Support for dynamic and basic volumes 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 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 Viewing the recovery progress Starting a restored target server Troubleshooting connections to the Universal Recovery Console Repairing boot problems Performing a file system check on the restored volume
Managing aging data Archiving Cloud storage accounts The Local Mount Utility The Central Management Console Core Console references Command Line Management utility PowerShell module
Prerequisites for using PowerShell Working with commands and cmdlets Rapid Recovery PowerShell module cmdlets Localization Qualifiers
Scripting 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.

From the Rapid Recovery Core Console, on the icon bar, click [More] (More) and then click [Log] Core Log.
On the Download Core Log page, click [Download]Click here to begin the download.
If prompted to open or save the CoreAppRecovery.log file, click Save.
If you see the Opening CoreAppRecovery.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 CoreAppRecovery.log file opens in the selected application.

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

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


This section describes how to work with repositories. It discusses the deduplication volume manager repository and describes its features and attributes. 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 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. Finally, this section describes how to migrate recovery points manually from one repository to another.

Understanding repositories

A repository is a central location in which backup snapshot data captured from your protected workstations and server is stored and managed. Data is saved to a repository in the form of recovery points.

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

NOTE: Store repositories for Rapid Recovery Core 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:\).

Rapid Recovery supports the following primary and secondary repositories:

DVM Repository. The AppAssure legacy repository format uses Deduplication Volume Manager (DVM) and is the primary repository technology used for storing recovery points. DVM repositories support multiple volumes, up to 255 repositories on a single Core, and the use of extents. You can create DVM repositories on machines with Windows operating systems only. You can use this repository type when upgrading existing AppAssure installations, and when using new Rapid Recovery installations. You can specify the size of a DVM repository upon creation, and can add extents later. Repositories can span across different storage technologies.
Rapid Recovery Repository (R3). This technology is featured in the Quest DR series backup and deduplication appliance. It serves as a secondary storage location for aged recovery points that are not yet designated for archiving. Beginning with Rapid Recovery version 6.1, you can relocate existing recovery points from your primary Rapid Recovery DVM repository to an R3 repository on a Quest DR series backup appliance. Using this second tier of storage for recovery points lets you distribute processing more efficiently and reduce load on your Core machines. Recovery points tiered to the R3 repository continue to be secured with encryption and are subject to rollup.

You can have both DVM and R3 repositories defined for a single Core. If you add one or more R3 repositories to your Core, you see an R3 Repositories pane on the Repositories page.

DVM repository features and attributes include:

Supports recovery from legacy AppAssure 5.x and new Rapid Recovery 6.x archives and recovery points
New repositories of this type can be created using REST APIs, the Rapid Recovery Command Line Management Utility (cmdutil.exe), or Windows PowerShell® cmdlet

R3 repository features and attributes include:

R3 repositories are currently only supported on a Quest DR series backup and deduplication appliance.

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 are 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.

For more information on working with DVM repositories, see Managing a DVM repository.

Deduplication in Rapid Recovery

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, a virtual reference to the data is stored.

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.

Rapid Recovery release 6.1.1 uses target-based deduplication for all DVM repositories. In this model, information is transferred to the DVM repository (the target), and is then deduplicated from the repository.

For the most part, deduplication takes place inline (during the transfer of backup information).

For maximum gains, Rapid Recovery now also offers deduplication that occurs as post-processing. Post-processing is sometimes called pass-through deduplication. Using this model, data in the repository are compared to references in the DVM data cache. If a block of data in the repository has already been saved, then each additional occurrence of that data is replaced with a pointer or reference to the data.

This post-processing can save space on your repository storage volume, particularly if the deduplication cache was filled and then the cache was subsequently increased to take advantage of additional deduplication. This type of deduplication takes place when performing a repository optimization job. This feature is unique to DVM repositories, and is also called duplicate block reclamation.

For more information about the repository optimization job, see About the Repository Optimization Job. For more information on 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 on where the references to unique blocks are stored for DVM repositories, see Understanding deduplication cache and storage locations.

Related Documents