Chat now with support
Chat with Support

Rapid Recovery 6.1.2 - User Guide

Introduction to Rapid Recovery Core Console Core settings Repositories Encryption keys Protecting machines
About protecting machines with Rapid Recovery Support for dynamic and basic volumes 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 Settings and functions for protected Exchange servers Settings and functions for protected SQL servers
Managing protected machines Snapshots and recovery points Replication Events Reporting VM export Restoring data Bare metal restore
Bare metal restore for Windows machines Understanding boot CD creation for Windows machines Using the Universal Recovery Console for a BMR Performing a bare metal restore for Linux machines Viewing the recovery progress Starting a restored target server Troubleshooting connections to the Universal Recovery Console Repairing boot problems Performing a file system check on the restored volume
Managing aging data Archiving Cloud storage accounts The Local Mount Utility The Central Management Console Core Console references Command Line Management utility PowerShell module
Prerequisites for using PowerShell Working with commands and cmdlets Rapid Recovery PowerShell module cmdlets Localization Qualifiers
Scripting REST APIs About us Glossary

Managing aging data

This section describes how to manage aging snapshot data saved to your repository. It includes information about retaining recovery points in your repository, retention policies, and the resulting process of rolling up recovery points to conserve space. It describes the new ability to relocate recovery points from your repository to a Quest DR backup and deduplication appliance.

This section also describes how to archive data for long-term storage that is not subject to rollup, and how to access recovery points that have been archived.

Data retention, tiering to secondary storage, and archiving

Each time your Core captures a snapshot, the data is saved as a recovery point to your repository. Recovery points naturally accumulate over time. The Core uses a retention policy to determine how long snapshot data is retained in the repository. When nightly jobs run (specifically, during the rollup process), the Core enforces the retention policy to reduce the amount of storage space consumed. The date of each recovery point is compared to the date of the most recent recovery point. The Core then rolls up (combines) older recovery points. Over time, older recovery points in the repository are continually replaced with newer ones as the oldest recovery points eventually reach the oldest age defined in the retention period.

As of Rapid Recovery release 6.1.1, you can also relocate recovery points from your primary repository to an R3 repository on a Quest DR backup and deduplication appliance. This frees up storage in your primary repository.

To tier recovery points to secondary storage using this method, you must first add the DR appliance as a repository on your Rapid Recovery Core. For more information on creating a new R3 repository on a DR, see Creating an R3 repository.

To keep recovery points that would otherwise be combined and eventually deleted, you can create an archive from the Core Console. An archive is a file containing a copy of the full set of recovery points for machines protected on your Core at the point in time in which it was created. You can later access archived information from the Core Console. In contrast with recovery points in the repository, recovery points in an archive do not get rolled up.

Archives are useful for maintaining compliance data; backing up your Core; seeding replication data to a remote replica Core; and for saving space in your Core for retaining recent business-critical transaction while maintaining backups for a longer period of time.

Managing retention policies

A retention policy is a set of rules that dictates the length of time for the Core to retain recovery points before starting to roll them up. Retention policies can be set to roll up based on hours, days, weeks, months and years. You can set up to six rules (the default policy sets five rules).

Since you can back up as frequently as every 5 minutes, the first rule in the retention policy typically sets how long to retain all recovery points. For example, if you back up a machine every quarter hour, 96 recovery points are saved to the repository for that machine per day, until rollup begins. Without managing your retention policy, that amount of data can quickly fill a repository.

The Core comes preset with a default retention policy. The default policy retains:

Following this default policy, the oldest recovery point is typically 92 days old. Data past that origination date for a default policy is deleted.

Setting the retention policy at the Core level applies automatically to all machines that the Core protects. You can change the default policy to suit your needs.

For any machine, you can also create a custom retention policy. Setting the policy at the machine level lets you specify a different retention policy than the default Core policy. For more information about configuring retention policies, see Configuring Core default retention policy settings and Customizing retention policy settings for a protected machine.

Configuring Core default retention policy settings

The retention policy for the Core specifies how long the recovery points for a protected machine are stored in the repository.

The Core retention policy is enforced by a rollup process which is performed as one component of running nightly jobs. Then, recovery points beyond the age specified in the retention policy are “rolled up” (combined) into fewer recovery points that cover a less granular period of time. Applying the retention policy on a nightly basis results in the ongoing rollup of aging backups. This eventually results in the deletion of the oldest recovery points, based on the requirements specified in that retention policy.

Different retention settings can be configured for source and target Cores.

NOTE: This topic is specific to customizing retention policy settings on the Rapid Recovery Core. When you save customized retention policy settings on the Core, you establish the default retention policy settings which can be applied to all machines protected by this Core. For more information on customizing retention policy settings for individual protected machines, see Customizing retention policy settings for a protected machine.

If you have access to a Quest DR series backup appliance, can also choose to relocate recovery points from your local repository to an R3 repository stored on the DR appliance.

NOTE: You must first associate the DR backup appliance with your Rapid Recovery Core. For more information, see XX.
1.
Navigate to the Rapid Recovery Core Console.

The Nightly Jobs core settings appear.

3.
Under Nightly Jobs, click [Change] Change.

The Nightly Jobs dialog box appears.

The Configuration dialog box for the Core default retention policy appears.

All settings are restored to the default values described in the table in Step 6.

The retention policy options are described in the following table.

Table 152. Schedule options for default retention policy

Text Box

Description

Keep all recovery points for n [retention time period]

Specifies the retention period for the recovery points.

Enter a number to represent the retention period and then select the time period. The default is 3 days.

You can choose from: Days, Weeks, Months, or Years

…and then keep one recovery point per hour for n [retention time period]

Provides a more granular level of retention. It is used as a building block with the primary setting to further define how long recovery points are maintained.

Enter a number to represent the retention period and then select the time period. The default is 2 days.

You can choose from: Days, Weeks, Months, or Years

…and then keep one recovery point per day for n [retention time period]

Provides a more granular level of retention. It is used as a building block to further define how long recovery points are maintained.

Enter a number to represent the retention period and then select the time period. The default is 4 days.

You can choose from: Days, Weeks, Months, or Years

…and then keep one recovery point per week for n [retention time period]

Provides a more granular level of retention. It is used as a building block to further define how long recovery points are maintained.

Enter a number to represent the retention period and then select the time period. The default is 3 weeks.

You can choose from: Weeks, Months, or Years

…and then keep one recovery point per month for n [retention time period]

Provides a more granular level of retention. It is used as a building block to further define how long recovery points are maintained.

Enter a number to represent the retention period and then select the time period. The default is 2 months.

You can choose from: Months or Years

…and then keep one recovery point per year for n [retention time period]

Enter a number to represent the retention period and then select the time period.

You can choose from: Years

The oldest recovery point is determined by the retention policy settings.

The following is an example of how the retention period is calculated.

Keep all recovery points for three days.

…and then keep one recovery point per hour for three days

…and then keep one recovery point per day for four days

…and then keep one recovery point per week for three weeks

…and then keep one recovery point per month for two months

…and then keep one recovery point per month for one year

In this example, the oldest recovery point would be one year and three months old.

7.
If you want to retain all recovery points in your primary repository, select the Relocate outdated recovery points to an R3 repository option and skip the next step.
a.
Select the Relocate outdated recovery points to an R3 repository option.
c.
From the Select a repository drop-down menu, select the R3 repository to which you want to tier the specified recovery points.

The Configuration dialog box closes.

10.
In the Nightly Jobs dialog box, click OK.

The Nightly Jobs dialog box closes. The retention policy you defined is applied during the nightly rollup.

You can also to apply these settings when specifying the retention policy for any individual protected machine. For more information about setting retention policies for a protected machine, see Customizing retention policy settings for a protected machine.

Related Documents