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

Migrating recovery points manually to a different repository

If you want to remove the recovery points of a protected machine from a repository without deleting them, you can migrate them to a different repository manually by using this procedure. This process involves archiving recovery points from the source repository, and then importing the archive into the target repository.

For example, you can perform this procedure if your existing repository is full, or if your needs change and you want to protect a machine using a different Core and repository.

CAUTION: If your repository was upgraded previously from AppAssure 5.3 or 5.4 and used replication, Quest recommends performing the Check Repository Job on each repository in that target Core before migration. Performing this job will preclude copying any data irregularities to the new destination repository. The Check Repository Job is only available in the UI if it is applicable to your Core, and could take a substantial amount of time to run. For information about this job, see About checking the integrity of DVM repositories. For information on performing this job, see Performing an integrity check on a DVM repository.
1.
In the Rapid Recovery Core Console, pause protection for the protected machine or machines whose recovery points you want to migrate. For more information, see Pausing and resuming protection.
b.
On the Summary page of the protected machine, click Settings.
c.
On the Settings page, in the General pane, click the Repository drop-down list, and then select in the name of the repository you created in Step 4.
d.
Click OK.

Replication

This section describes how to configure and manage the replication of protected data from a Rapid Recovery source Core to a Rapid Recovery target Core for disaster recovery.

Replication with Rapid Recovery

This section provides conceptual and procedural information to help you understand and configure replication in Rapid Recovery.

Replication is the process of copying recovery points from one Rapid Recovery Core and transmitting them to another Rapid Recovery Core for disaster recovery purposes. The process requires a paired source-target relationship between two or more Cores.

The source Core copies the recovery points of designated protected machines, and then asynchronously and continually transmits that snapshot data to the target Core.

Unless you change the default behavior by setting a replication schedule, the Core starts a replication job immediately after completion of every backup snapshot, checksum check, mountability check, and attachability check. Log truncation of any type also triggers a replication job, as does checking the integrity of recovery points or of an Oracle database. If any of these actions are included in nightly jobs, then completion of nightly jobs also triggers a replication job. For more information, see Scheduling replication.

For optimum data security, administrators usually use a target Core at a remote disaster recovery site. You can configure outbound replication to a company-owned data center or remote disaster recovery site (that is, a “self-managed” target Core). Or, you can configure outbound replication to a third-party managed service provider (MSP) or cloud provider that hosts off-site backup and disaster recovery services. When replicating to a third-party target Core, you can use built-in work flows that let you request connections and receive automatic feedback notifications.

Replication is managed on a per-protected-machine basis. Any machine (or all machines) protected or replicated on a source Core can be configured to replicate to a target Core.

Possible scenarios for replication include:

Replication to a local location. The target Core is located in a local data center or on-site location, and replication is maintained at all times. In this configuration, the loss of the Core would not prevent a recovery.
Replication to an off-site location. The target Core is located at an off-site disaster recovery facility for recovery in the event of a loss.
Mutual replication. Two data centers in two different locations each contain a Core and are protecting machines and serving as the off-site disaster recovery backup for each other. In this scenario, each Core replicates the protected machines to the Core that is located in the other data center.
Hosted and cloud replication. Rapid Recovery MSP partners maintain multiple target Cores in a data center or a public cloud. On each of these Cores, the MSP partner lets one or more of their customers replicate recovery points from a source Core on the customer’s site to the MSP’s target Core for a fee.

Possible replication configurations include:

Point-to-point replication. Replicates one or more protected machines from a single source Core to a single target Core.

Figure 1. Point-to-point replication configuration

Multipoint-to-point replication. Replicates protected machines from multiple source Cores to a single target Core.

Figure 2. Multipoint-to-point replication configuration

Point-to-multipoint replication. Replicates one or more protected machines from a single source Core to more than one target Core.

Figure 3. Point-to-multipoint replication configuration

Multi-hop replication. Replicates one or more protected machines from one target Core to another target Core, producing additional failover or recovery options on the replicated Core.

Figure 4. Multi-hop replication configuration

If using DL series backup appliances, the target Core to which you replicate must have a valid software license configured. These hardware appliances include a replication target license with purchase. Check for your license key in the welcome email message you received when purchased the appliance. For assistance, visit the Licensing Assistance website at https://support.quest.com/contact-us/licensing or email license@quest.com.

Recovery point chains and orphans

Rapid Recovery captures snapshots of a protected machine, and saves the data to a repository as a recovery point. The first recovery point saved to the Core is called a base image. The base image includes the operating system, applications, and settings for each volume you choose to protect, as well as all data on those volumes. Successive backups are incremental snapshots, which consist only of data changed on the protected volumes since the last backup. The base image plus all incremental snapshots together form a complete recovery point chain.

From a complete recovery point chain, you can restore data with ease and confidence, using the full range of recovery options available to Rapid Recovery. These options include file-level restore, volume-level restore, and bare metal restore.

Since logically you cannot restore from data that does not exist, in the case of an incomplete recovery point chain, you cannot restore data at the volume level or perform a bare metal restore. In such cases, you can still restore any data that does exist in a recovery point at the file level.

If the information you want to restore from a recovery point is in a previous backup that is not available to the Core (an earlier incremental snapshot or the base image), the recovery point is said to be orphaned. Orphaned recovery points are typical in some replication scenarios.

For example, when you first establish replication, your options for restoring data from the replicated recovery points are limited. Until all backup data from the source Core is transmitted to the target Core, creating full recovery point chains from the orphans, you can only perform file-level restore.

Related Documents