Rapid Recovery 6.3 - User Guide

Deleting an orphaned recovery point chain

1. In the Rapid Recovery Core Console, navigate to the protected machine for which you want to delete the orphaned recovery point chain.
2. From the menu at the top of the page, click Recovery Points.
3. In the Recovery Points pane, expand the orphaned recovery point.

   This recovery point is labeled in the Type column as “Incremental, Orphaned.”

4. Next to Actions, click Delete.

   The Delete Recovery Points window appears.

5. In the Delete Recovery Points window, click Yes.

   Caution: Deleting this recovery point deletes the entire chain of recovery points, including any incremental recovery points that occur before or after it, until the next base image. This operation cannot be undone.

   The orphaned recovery point chain is deleted.

Migrating recovery points manually to a different repository

1. In the Rapid Recovery Core Console, pause protection for any protected machines that have recovery points you want to migrate. For more information, see Pausing and resuming protection.
2. Cancel all current operations for any protected machines that have recovery points you want to migrate, or wait for them all to complete.
3. Archive the recovery points for the machine or machines you paused. For more information, see Creating an archive.
4. After archiving and verifying the archive, remove the existing recovery points for the protected machine you want to migrate. For more information, see Removing recovery points.

   NOTE: Without removing existing recovery points, you cannot change repositories for a protected machine.

5. Create a new repository for the migrated recovery points, or ensure a new destination repository exists. For more information, see Creating a DVM repository.
   If you want to use an existing repository, continue to step 6.
6. Change the repository for each machine that you paused by completing the following steps:
   1. On the Core Console, click the protected machine in the navigation tree.
   2. On the Summary page of the protected machine, click Settings.
   3. On the Settings page, in the General pane, click the Repository drop-down list, and then select the name of the repository you created in step 4.

      If you want to use an existing repository, select the name of an existing repository.

      NOTE: When migrating recovery points to an existing repository, ensure that the existing repository has enough free space to contain the migrated recovery points.

   4. Click to save the change to settings.
7. Resume protection for the machine or machines that you paused. For more information, see Pausing and resuming protection.
8. Take a new base image for each of the protected machines you moved. For more information, see Forcing a snapshot and use the Force Base Image option.
9. Import the archived data for the machines you want to migrate. For more information, see Importing an archive.

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.

Topics include:

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, 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. This scenario is also called cross replication.
• 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.

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

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

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