Chatee ahora con Soporte
Chat con el soporte

Rapid Recovery 6.8 - 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

Configuring nightly jobs for the Core

When any nightly job option is enabled on the Rapid Recovery Core, the selected job executes once daily at the time specified for all machines that are protected by the Core. Conversely, if you disable any nightly job at the Core level, the specified job no longer executes for all machines protected by the Core.

NOTE: If the scope of a nightly job, as described in the topic Understanding nightly jobs, includes protected machines, you can configure that nightly job to apply only for one or more specific protected machines individually. For more information about applying nightly job settings specific to a protected machine, see Customizing nightly jobs for a protected machine.

Because nightly jobs are memory-intensive, Quest recommends configuring your Core to execute them during a time of low activity. The default schedule to run nightly jobs is 12:00 am. If another time is more suitable, change this setting in the Nightly Jobs Time field using this procedure.

  1. Navigate to the Rapid Recovery Core Console.
  2. On the icon bar, click [Settings] (Settings), and then do one of the following:
    • From the list of Core settings on the left side of the Settings page, click Nightly Jobs.
    • Scroll down on the right side of the Settings page until you can see the Nightly Jobs heading.
  3. To change any nightly job, or to change the time that nightly jobs begin to execute, click [Change] Change.

    The Nightly Jobs dialog box displays.

  4. If you want to change the time nightly jobs execute, enter a new time in the Nightly job times text box.
  5. In the first column, click to select each nightly jobs option you want to set for the Core. Click any selected option to clear it.
  6. Click OK.
    The Nightly Jobs dialog box closes and your nightly jobs settings for the Core are saved.

Modifying transfer queue settings

Transfer queue settings are Core-level settings that establish the maximum number of concurrent transfers and the maximum number of retries for transferring data.

Complete the steps in this procedure to modify transfer queue settings.

  1. Navigate to the Rapid Recovery Core Console.
  2. On the icon bar, click [Settings] (Settings), and then do one of the following:
    • From the list of Core settings on the left side of the Settings page, click Transfer Queue.
    • Scroll down on the right side of the Settings page until you can see the Transfer Queue heading.
  3. Click on the setting you want to change.

    The setting you selected becomes editable.

  4. Enter the configuration information as described in the following table.
    Table 22: Transfer queue settings information
    Text Box Description
    Maximum concurrent transfers Enter a value to update the number of concurrent transfers.

    Set a number from 1 to 60. The smaller the number, the lesser the load on network and other system resources. As the number of agents that are processed increases, so does the load on the system.

    Maximum retries Enter a value to set the maximum number of attempts before canceling the transfer operation.

    Set a number from 1 to 60.

  5. For each setting, when satisfied with your changes, click [Save] to save the change and exit edit mode, or click [Cancel] to exit edit mode without saving.

Adjusting client timeout settings

Client timeout settings control the length of time that various operations are attempted before the operation times out.

NOTE: Quest recommends leaving default timeout settings unless you experience specific issues in your environment, and you are advised by a Quest Data Protection Support representative to modify the settings.

Complete the steps in this procedure to adjust client timeout settings.

  1. Navigate to the Rapid Recovery Core Console.
  2. On the icon bar, click [Settings] (Settings), and then do one of the following:
    • From the list of Core settings on the left side of the Settings page, click Client Timeout.
    • Scroll down on the right side of the Settings page until you can see the Client Timeout heading.
  3. Click on the setting you want to change.

    The setting you selected becomes editable.

  4. Enter the configuration information as described in the following table.
    Table 23: Client timeout settings information
    Setting Description

    Connection timeout

    Controls the timeout for the connection between the Core and protected machines when sending data across the hypertext transfer protocol (http).

    Enter the amount of time you want to lapse before a connection timeout occurs. Uses HH:MM:SS format.

    NOTE: The default setting is 0:05:00 or five minutes.

    Read/Write timeout

    Controls the timeout for the connection between the Core and protected machines when reading or writing stream data across http. An example is receiving changed data blocks from a protected machine to the Core for an incremental snapshot.

    Enter the amount of time you want to lapse before a timeout occurs during a read/write event. Uses HH:MM:SS format.

    NOTE: The default setting is 0:05:00 or five minutes.

    Connection UI timeout

    Controls the timeout for the connection between the graphic user interface and the Rapid Recovery Core service across http.

    Enter the amount of time you want to lapse before a connection UI timeout occurs. Uses HH:MM:SS format.

    NOTE: The default setting is 0:05:00 or five minutes.

    Read/Write UI timeout

    Controls the timeout for the connection for reading and writing data streams between the graphic user interface and the Rapid Recovery Core service across http.

    Enter the amount of time you want to lapse before a timeout occurs during read or write events. Uses HH:MM:SS format.

    NOTE: The default setting is 0:05:00 or five minutes.

  5. For each setting, when satisfied with your changes, click [Save] to save the change and exit edit mode, or click [Cancel] to exit edit mode without saving.

Understanding deduplication cache or dictionary size and storage locations

Global deduplication reduces the amount of disk storage space required for data your Core backs up. Each repository is deduplicated, storing each unique block once physically on disk, and using virtual references or pointers to those blocks in subsequent backups. To identify duplicate blocks, Rapid Recovery includes a deduplication cache for deduplication volume manager (DVM) repositories. The cache holds references to unique blocks.

By default, for DVM repositories, this deduplication cache is 1.5GB. This size is sufficient for many repositories. Until this cache is exceeded, your data is deduplicated across the repository. Once the amount of redundant information is so great that the deduplication cache is full, your repository can no longer take full advantage of further deduplication for newly added data. The amount of data saved in your repository before the deduplication cache fills varies by the type of data being backed up, and is different for every user.

You can increase or decrease the size of the deduplication cache by adjusting the Deduplication cache size value in the DVM Deduplication Cache Core settings. For more information on how to increase the cache size, see the topic Configuring DVM deduplication cache settings.

When you increase the DVM deduplication cache size, there are two factors to consider: disk space and RAM usage.

Disk space. Two copies of the DVM deduplication cache are stored on disk: a primary cache, and a secondary cache which is a parallel copy. Thus, if using the default cache size of 1.5GB for a DVM repository, 3GB of disk storage is used in your system. As you increase the cache size, the amount of disk space used remains proportionally twice the size of the cache. To ensure proper and fault-resistant performance, the Core dynamically changes the priority of these caches. Both are required, the only difference being that the cache designated as primary is saved first.

RAM usage. When the Rapid Recovery Core starts, it loads the deduplication cache to RAM. The size of the cache therefore affects memory usage for your system. The total amount of RAM the Core uses depends on many factors. These factors include which operations are running, the number of users, the number of protected machines, and the size of the deduplication cache. Each operation the Core performs (transfer, replication, rollup, and so on) consumes more RAM. Once an operation is finished, memory consumption decreases accordingly. However, administrators should consider the highest RAM load requirement for efficient operations.

Default settings for the Rapid Recovery Core place the primary cache, secondary cache, and the metadata cache for DVM repositories in the AppRecovery directory. This folder is installed on the Core machine.

NOTE: Depending on your settings, the AppRecovery directory may not be visible on the Rapid Recovery Core. To see this directory, you may need to change the Folder Options control panel to show hidden files, folders, and drives.

Assuming the Rapid Recovery Core is installed on the C drive, these locations are typically as follows:

Table 24: Default storage locations for DVM deduplication cache settings
Setting Default Storage Location

Primary cache location

C:\ProgramData\AppRecovery\RepositoryMetaData\PrimaryCache

Secondary cache location

C:\ProgramData\AppRecovery\RepositoryMetaData\SecondaryCache

Metadata cache location

C:\ProgramData\AppRecovery\RepositoryMetaData\CacheMetadata

Optimizing deduplication

When you install Rapid Recovery Core, the installer defaults to the C:\ drive of the Core machine to store the deduplication cache used for DVM repositories.

To optimize deduplication performance, Quest recommends installing the deduplication cache to a separate fast physical storage location. For maximum performance, install the deduplication cache on a solid-state drive (SSD).

You can change the storage location of these caches. For example, for increased fault tolerance, you can change location of your secondary cache to a different physical drive than the primary cache, assuming the Rapid Recovery Core has access to the location.

For more information on how to change storage locations for any of these settings, see the topic Configuring DVM deduplication cache settings.

For conceptual information about deduplication, see Deduplication in Rapid Recovery.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación