Chat now with support
Chat with Support

Rapid Recovery 6.10 - 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 update settings

Rapid Recovery includes the automatic update feature. When installing the Rapid Recovery Core , you can choose whether to automatically update the Rapid Recovery Core software when new updates are available, and how frequently the system should check for updates.

NOTE: The automatic update feature requires a license using the standard phone-home mode. If using a software license in non-phone home mode, your Core does not have permission to communicate with the Rapid Recovery License Portal and cannot update the Core or notify you of available updates. For more information, see Managing privacy.

Rapid Recovery release numbers typically include four chunks of information, separated by decimal points: the major release number, minor release number, revision, and build number. For example, the first rebranded release of Rapid Recovery was 6.0.1.609. The next release was 6.0.2.142.

The automatic update feature compares all digits in a release number. If you enable automatic update, the Core software is only updated without intervention when the major and minor release numbers are identical. For example, automatic update would occur from Core version 6.0.1.609 to 6.0.2.142 (both start with 6.0). On the same machine, the Core would not update automatically from 6.0.2.142 to 6.1.1.XXX, because the digits after the first decimal are not equal. Instead, you are notified (by a banner at the top of the Core Console) that an update to the Core software is available. This notification gives you an opportunity to review release notes, and determine if updating to the latest Core version is appropriate for your needs.

NOTE: For information on installing Rapid Recovery Core software, see the Rapid Recovery Installation and Upgrade Guide.

You can view and change the settings the system uses to check for updates at any time.

Caution: When using replication, configuring your system to install updates automatically could result in upgrading the source Core before the target Core, which may result in replication failure or the inability to set up new replication between Cores. For replication users, Quest recommends administrators apply automatic upgrades only to the target Core, and then manually upgrade the source Core, and lastly upgrade the protected machines.

Complete the steps in this procedure to configure update 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 Updates.
    • Scroll down on the right side of the Settings page until you can see the Updates 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 20: Update settings information
    Text Box Description
    Check for new updates Select how frequently Rapid Recovery checks for and installs updates. You can choose from the following options:
    • Never
    • Daily
    • Weekly
    • Monthly

      If you choose automatic updates, after the selected threshold of time passes, if an update is available, it is installed after nightly jobs have completed.

    Install updates Specify the handling of available updates by choosing one of the following options:
    • Never check for updates
    • Notify me about updates, but do not install them automatically
    • Automatically install updates
    Status The status indicates whether any new updates are available.
    Last check The Last check field indicates the date and time the system last checked for an update.

    Click Check Now to immediately verify whether a software update is available. This check occurs regardless of the frequency you have set.

  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 nightly jobs

Nightly jobs are daily automated tasks that occur at a predetermined time outside of normal business hours. These jobs are memory-intensive, and include various integrity checks and data consolidation tasks that are best conducted when the Rapid Recovery Core is less active.

All the nightly jobs, and the scope for which they can be applied, are described in the following table. Nightly jobs can be managed at the Core level (which applies to all machines protected on the Core). Those nightly jobs which can also be applied for a specific protected machine list the scope as "Protected machine."

Table 21: Nightly jobs information
Job Name Scope Description

[Change] Change

N/A

This control opens the Nightly Jobs dialog box, where you can enable, disable, or change settings for each nightly job.

Nightly jobs time

All

This setting represents the time that nightly jobs are scheduled to start running. Quest recommends configuring your Core to run nightly jobs during a time of low activity.

The default time is 12:00 AM.

Check attachability of SQL Server databases

Protected machine

Checks the integrity of recovery points containing SQL databases. For more information, see Managing Core SQL attachability settings.

Check checksum of Exchange databases

Protected machine

Checks the integrity of recovery points containing Exchange Database (EDB) files.

NOTE: This option does not appear if you are not protecting an Exchange Server in your Core.

Check integrity of Oracle databases

Core or protected machine

Checks the integrity of Oracle databases using the DBVERIFY utility.

Process:

  • Mount the latest recovery point for every protection group.
  • Enumerate the files and folders for each volume.
  • Examines the recovery points to ensure that data files are valid and data blocks are not corrupted.
  • Dismount the recovery point.

Check integrity of recovery points

Core or protected machine

Checks the integrity of recovery points for each protected machine.

NOTE: By default, the Check integrity of recovery points option is not enabled.

Process:

  • Mount the latest recovery point for every protection group.
  • Enumerate the files and folders for each volume.
  • Examines the recovery points to ensure that they are valid.
  • Dismount the recovery point.

Clean orphaned registry keys on Hyper-V agents

 

For Hyper-V hosts using Rapid Recovery release 6.1.x agentless protection, this nightly job cleans orphaned keys made in the Windows registry for each attach and detach operation. The registry entries are harmless, but over time can accumulate, leading to slower performance.

NOTE: As of Rapid Recovery release 6.2, an improved approach to obtaining storage metadata for Hyper-V agentless protection precludes creating registry entries.

Consolidate VMware snapshots for protected virtual machines

Core or protected machine

This nightly job is relevant if you use native VMware APIs to protect machines without the Rapid Recovery Agent software.

You should periodically consolidate VMware snapshots. Enabling this nightly job lets you perform these consolidations on a daily basis. This nightly job contains one parameter, Maximum simultaneous consolidations, which must be set to a number between 1 and 100.

Deferred delete

Core

This setting lets you defer removal of recovery points from the repository until the time specified in your Core to perform nightly jobs. When enabled, then after other nightly jobs run, Core processing is dedicated to running the "Deleting records previously flagged for deletion" job. That job removes marked recovery points from the repository until they are all removed, or until four hours have passed from the nightly jobs execution time. Nightly jobs then end, and other queued jobs resume. Any remaining deletions occur in the background, concurrent with other tasks, until the next day's nightly jobs run.

NOTE: By default, the Deferred Delete option is not enabled.

Quest recommends leaving this nightly job disabled unless you are encountering transfer performance issues related to backed-up recovery point deletions.

If you enable this option, Quest recommends reviewing your Core jobs to ensure most recovery points marked for deletion are removed from the repository within a one-week period. This approach helps to balance maximum transfer performance with maximum reclamation of repository space.

Delete old events and jobs

Core

Maintains the scale of the events database by removing old events. The number of days is configurable, defaulting to 30 days.

Log truncation for Exchange

Protected machine

Maintains the size of Exchange logs by truncating the exchange database transaction log to match the last recovery point.

NOTE: This option does not appear if you are not protecting an Exchange server in your Core.

Log truncation for Oracle

Protected machine

Controls truncation for Oracle logs. When enabled, truncation occurs when nightly jobs run, according to the deletion policy selected.

  • You can select the Core Automatic deletion policy. When this policy is in effect, then when nightly jobs run, all of the locally stored Oracle archivelogs included in the last recovery point are truncated. Business logic prevents archivelogs not included in a snapshot from truncation. New archive logs that are captured in a subsequent snapshot become eligible for automatic truncation when the next nightly job is run.
  • You can select a custom deletion policy for a specific protected Oracle server. The Keep newest policy lets you specify the duration of time before which Oracle logs are truncated, and the Keep specified number policy lets you keep a specified number of log files before truncating the older ones.
  • When this nightly job is disabled, substantial accumulation of log files occurs. In such cases, users can also truncate log files manually, as described in the topic Manually truncating Oracle database logs.

Log truncation for SQL Server

Protected machine

Maintains the size of SQL Server logs by truncating the database transaction log to match the last recovery point.

NOTE: This option does not appear if you are not protecting a SQL Server in your Core.

Rollup

Core or protected machine

Applies the retention policy to your backed-up data by combining or "rolling up" recovery points on the schedule dictated in the policy. You can customize the policy on the Core, which applies by default to all protected machines. By default, the rollup job is run for the whole Core; or click [Expand] [Expand] to expand the view of protected machines. You can then define the set of protected machines you want to roll up using the Core policy.

For more information about using a retention policy on a protected machine that differs from the default policy set in the Core, see Customizing retention policy settings for a protected machine.

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.
Related Documents
Rapid Recovery - 6.10
Commands and Scripting Reference Guide
Installation and Upgrade Guide
Release Notes
System Requirements Guide
User Guide
Showing 1 to 5 of 5 rows

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating