Quest has been named as an ASP "Ten Best Web Support Sites" award winner. Learn more.

Rapid Recovery 6.0.2 - User Guide

*** Legend Introduction to Dell Data Protection | Rapid Recovery Understanding the Rapid Recovery Core Console Working with repositories Managing Rapid Recovery Core settings Using custom groups Working with encryption keys Protecting machines using the Rapid Recovery Core Working with Microsoft Exchange and SQL Servers Protecting server clusters Exporting protected data to virtual machines Managing protected machines Understanding replication Managing events Generating and viewing reports Restoring data Understanding bare metal restore for Windows machines Retention and archiving Managing cloud accounts Working with Linux machines Understanding the Local Mount Utility Central Management Console Understanding the Rapid Recovery Command Line Management utility Understanding the Rapid Recovery PowerShell module
Prerequisites for using PowerShell Working with commands and cmdlets Rapid Recovery PowerShell module cmdlets Localization Qualifiers
Extending Rapid Recovery jobs using scripting Rapid Recovery APIs Glossary

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


Was this topic helpful?

[Select Rating]



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 selected 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, attachability check, and the nightly jobs. 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.
    Note: In this scenario, customers only have access to their own data.

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 Dell Data Protection backup appliances such as the DL1x00 or DL4x00 series, 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.software.dell.com/licensing-assistance or email license@software.dell.com.


Was this topic helpful?

[Select Rating]



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.


Was this topic helpful?

[Select Rating]



When replication begins

By default, replication transfer jobs are automatically queued by the Core immediately after each regularly scheduled backup transfer completes. Thus, unless the replication schedule for a protected machine is customized, its replication schedule is based on its standard backup snapshot schedule.

When you first set up replication, if one or more recovery points exist on the source Core, the replication process begins immediately, unless:

  • You select the option to initially pause replication, or
  • You select the option to use a seed drive to perform the initial transfer.

If you pause replication initially, replication begins when you explicitly resume replication.

If you set up replication and specify the use of a seed drive, replication to the target Core begins with the next regularly scheduled backup snapshot.

Note: You can also force a backup of the protected machine after establishing replication. This causes replication to begin immediately after the protected machine snapshot completes.

If you specify a seed drive when you set up replication, only future backup transfers are replicated. If you want existing recovery points from the original protected machine to exist on the target Core, you must seed data from the protected machine. To seed data, create a seed drive from the source Core, and then consume the seed drive on the target Core.

You can also customize the replication schedule for a protected machine. For example, if you use the default protection schedule of one backup per hour, you can specify that the source Core replicate to the target Core at a different schedule (for example, once daily at 2AM).


Was this topic helpful?

[Select Rating]



Related Documents