Chat now with support
Chat with Support

Rapid Recovery 6.3 - User Guide

Introduction to Rapid Recovery The Core Console Repositories Core settings 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 Credentials Vault Snapshots and recovery points Replication Events Reporting VM export Restoring data Bare metal restore
About bare metal restore BMR Windows and Linux Understanding boot CD creation for Windows machines Managing a Linux boot image Performing a bare metal restore using the Restore Machine Wizard 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 Core Console references REST APIs Glossary

Deleting an orphaned recovery point chain

An orphaned recovery point is an incremental snapshot that is not associated with a base image. Subsequent snapshots continue to build onto this recovery point; however, without the base image, the resulting recovery points are incomplete and are unlikely to contain the data necessary to complete a recovery. These recovery points are considered to be part of the orphaned recovery point chain. If this situation occurs, the best solution is to delete the chain and create a new base image.

For more information about forcing a base image, see Forcing a snapshot.

  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

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 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 [Save] 
    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.

NOTE: When you replicate data for a cluster, you must replicate the entire cluster. For example, if you select a node to replicate, the cluster is automatically selected. Likewise, if you select the cluster, all nodes in that cluster are also selected.

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.

Figure 1: Point-to-point replication configuration

Figure: 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

Figure: Multi-point-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

Figure: 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

Figure: Multihop replication configuration

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating