Chatee ahora con Soporte
Chat con el soporte

Rapid Recovery 6.7 - User Guide

Introduction to Rapid Recovery The Core Console Repositories Core settings 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 Managing privacy Encryption Authentication Replication Events Reporting VM export Restoring data Bare metal restore
About bare metal restore Differences in bare metal restore for Windows and Linux machines 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

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

Determining your seeding needs and strategy

The following topics discuss restoring from replicated data and whether you need to seed recovery point data from the source Core.

When seeding data is required

When you first establish replication, unless you specify the use a seed drive, the source Core begins transmitting all of the recovery points for the selected machines to the target Core. Transmitting your data over the network can take a good deal of time. Factors involved include the speed of your network, the robustness of your network architecture, and the amount of data to be transmitted to the target Core. For example, if the backup data on the source Core measures 10GB and the WAN link transfers 24Mbps, the transfer could take approximately one hour to complete.

Based on the amount of information you want to copy to the target Core, the seed drive can add up to hundreds or thousands of gigabytes of data. Many organizations choose not to consume the network bandwidth required, and instead opt to define and consume a seed drive. For more information, see Performance considerations for replicated data transfer.

If you specify the use of a seed drive when defining replication, then only recovery points saved to the source Core after you establish replication are replicated to the target Core. Backups saved on the source Core before replication was established will not be present on the target Core until you explicitly seed the data, using the following process.

To avoid slowing down your network with an intensive transfer of historical data, seed your prior backup data to the target Core using a seed drive. A seed drive is an archive file that copies a set of deduplicated base images and incremental snapshots from the source Core. The seed drive file contains the full set of previous recovery points for the protected machines you want to replicate from the source Core to the target Core.

Move the seed drive file to a storage volume which you then make available to the target Core. Then you consume the information from the seed drive. This involves attaching the volume with the seed drive image to the target Core and importing the data to the repository from the Core Console. This process repairs orphans, uniting incremental snapshots replicated to the target Core with their base images, to form one or more complete recovery point chains. This process is sometimes called copy-consume.

Seeding data from your source Core is not always required. For example:

  • If you are setting up replication for a new Rapid Recovery Core, seeding is not required.
  • If the data from previous snapshots are not critical for your replicated data, and you only need to recover data saved after replication is set up, seeding is not required.

    NOTE: In this case, Quest recommends capturing a new base image immediately before or immediately after setting up replication. This step ensures a full recovery point chain exists on the target Core from which to restore data in the future.

  • If you captured a base image immediately before setting up replication, and only have a need to restore from data captured after that date, seeding is not required.
  • If you set up replication without specifying a seed drive, then the snapshot data transmits over the network from the source Core to the target Core.

If one of these situations applies to you, you do not need to seed data. In such cases, replication can be completed entirely from the source Core.

If you set up replication for a Core with existing recovery points and may need to restore at the volume level, want to perform a BMR, or want to restore data from an earlier base image or incremental snapshot, seeding is required. In these situations, consider your seeding needs and strategy. Review the information in this topic and decide whether you will seed to your target Core, and which approach you will use.

Approaches to seeding data

If you want your replicated machines on a target Core to have access to data saved previously on the original source Core, seed your target Core using one of the following approaches:

  1. Seed to the target Core over a network connection. Specify the use of a seed drive when you define replication. You can then share the folder containing the seed drive with the target Core, and consume the seed drive file over the network. For large data or slow connections, seeding by this method can take a substantial amount of time and consume substantial network bandwidth.

    NOTE: Quest does not recommend seeding large amounts of data over a network connection. Initial seeding potentially involves very large amounts of data, which could overwhelm a typical WAN connection.

  2. Transfer backup data from the source Core using physical storage media. Transfer the seed drive file to a portable external removable storage device. This approach is typically useful for large sets of data or sites with slow network connections. Seeding using this method requires you to perform the following steps:
    1. Create a seed archive from the source Core, saving it to removable media.
    2. Transport the seed drive to the physical location of the target Core.
    3. Attach the drive to the target Core.
    4. Consume the data from the seed drive to the repository of the target Core.

    If replicating to a third-party Core, once your media is received by the MSP, a data center representative typically attaches the media and notifies you when it is ready for you to consume (or import) the seed data into the Core.

    NOTE: Because large amounts of data need to be copied to the storage device, an eSATA, USB 3.0, or other high-speed connection is recommended. If the total size of the seed data archive is larger than the space available on the removable media, the archive can span across multiple devices.

  3. For source and target Cores stored on virtual hosts, transfer backup data using a virtual hard disk. If your source Core and target Core are both on a virtual host, you can define and consume a seed drive on virtual storage media. Seeding using this method requires you to perform the following steps:
    1. Create a seed drive file from the source Core, saving it to a virtual storage volume.
    2. Detach the volume from the source Core and attach it to the target Core.
    3. Consume the data from the seed drive to the repository of the target Core.

NOTE: While replication of incremental snapshots can occur between the source and target Cores before seeding is complete, the replicated snapshots transmitted from the source to the target remain orphaned until the initial data is consumed, and they are combined with the replicated base images.

Related links

Performance considerations for replicated data transfer

If the bandwidth between the source and target Cores cannot accommodate the transfer of stored recovery points, set up replication and specify the use of a seed drive. This process seeds the target Core with base images and recovery points from the selected servers protected on the source Core. The seeding process can be performed at any time. Seeding can be performed as part of the initial transfer of data, which serves as the foundation for regularly scheduled replication. You can also seed data for a previously replicated machine if replication has been paused or deleted. In this case, the "Build recovery point chains" option lets you copy not-yet replicated recovery points to a seed drive.

When preparing for replication, consider the following factors:

  • Change rate. The change rate is the rate at which the amount of protected data is accumulated. The rate depends on the amount of data that changes on protected volumes and the protection interval of the volumes. Some machine types typically have a higher change rate, such as an Exchange email server. One way to reduce the change rate is to reduce the protection interval.
  • Bandwidth. The bandwidth is the available transfer speed between the source Core and the target Core. It is crucial that the bandwidth be greater than the change rate for replication to keep up with the recovery points snapshots create. For very large data transfers from Core to Core, multiple parallel streams may be required to perform at wire speeds up to the speed of a 1GB Ethernet connection.

    NOTE: Bandwidth that ISPs specify is typically the total available bandwidth. All devices on the network share the outgoing bandwidth. Make sure that there is enough free bandwidth for replication to accommodate the change rate.

  • Number of protected machines. It is important to consider the number of machines protected per source Core and how many you plan to replicate to the target. You are not required to replicate every machine protected on the source Core; Rapid Recovery lets you replicate on a per-protected machine basis, so you can choose to replicate only certain machines, if you want. If all protected machines on a source Core must be replicated, the change rate is typically higher. This factor is relevant if the bandwidth between the source and target Cores is insufficient for the amount and size of the recovery points being replicated.

The maximum change rate for WAN connection types is shown in the following table, with examples of the necessary bandwidth per gigabyte for a reasonable change rate.

Table 85: Examples of bandwidth per gigabyte
Broadband Bandwidth Max Change Rate
DSL 768 Kbps and up 330MB per hour
Cable 1 Mbps and up 429MB per hour
T1 1.5 Mbps and up 644MB per hour
Fiber 20 Mbps and up 8.38GB per hour

NOTE: For optimum results, adhere to the recommendations listed in the preceding table.

If a link fails during data transfer, replication resumes from the previous failure point of the transfer (once link functionality is restored).

Depending on your network configuration, replication can be a time-consuming process. Ensure that you account for enough bandwidth to accommodate replication, other Rapid Recovery transfers such as backups, and any other critical applications you must run.

If you experience issues successfully transferring data over the network, especially for certain protected or replicated machines, considering adjusting the rate of data transfer for those machines. For more information, see About modifying transfer settings and Throttling transfer speed.

About replication and encrypted recovery points

While the seed drive does not contain backups of the source Core registry and certificates, the seed drive does contain encryption keys from the source Core if the recovery points being replicated from source to target are encrypted. The replicated recovery points remain encrypted after they are transmitted to the target Core. The owners or administrators of the target Core need the passphrase to recover the encrypted data.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación