Chat now with support
Chat with Support

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

Customizing retention policy settings for a protected machine

The retention policy for a protected machine specifies how long recovery points are stored in the repository. Typically, each protected machine uses the default retention policy established for the Core unless you specify a custom retention policy, as described in this procedure.

Starting with AppAssure version 5.4.1, Rapid Recovery includes the ability to set disparate retention policies between a protected machine on the source Core and the corresponding replicated machine on the target Core.

Use this procedure to define a custom retention policy for a protected machine, including a replicated machine.

* 
NOTE: The following applies to environments upgrading from AppAssure release 5.3.x to release 5.4.1 or any version of Rapid Recovery Core. If you want to customize a retention policy for any replicated machine, first upgrade the source and target Cores to AppAssure Core release 5.4.1, and then perform the Checking Repository job on each repository in that target Core. Completing this job is likely to take a substantial amount of time, based on the size of your repository and the underlying storage system. For background information about this job, see About checking the integrity of DVM repositories. For information on how to perform this job, see Performing an integrity check on a legacy DVM repository.
1.
From the Protected Machines menu of the Rapid Recovery Core Console, click the name of the machine that you want to modify.

The Summary page for the selection machine appears.

2.
Click the Settings menu.

The Settings page appears, showing configuration settings for the selected machine.

3.
Optionally, click the Nightly Jobs link to scroll down in the Settings page to view nightly jobs settings.
4.
Under the Nightly Jobs heading, click [Change] Change.

The Nightly Jobs dialog box appears.

5.
To specify the time intervals for retaining the backup data as needed, select Rollup and then click Settings.

The Configuration dialog box for the retention policy appears.

6.
If customizing retention policies settings for a replicated machine, and if you see a caution notifying you to perform an Integrity Check on your repository, proceed with this step. Otherwise, skip to the next step.
a.
If you are prepared to perform the job, click Check Integrity
b.
Click Yes to confirm the Integrity Check job.
* 
NOTE: Running this job could take a substantial amount of time, based on the size of your repository. During this time, you can perform no other actions (snapshots, replication, virtual export, and so on) in the repository. For information about this job, see About checking the integrity of DVM repositories.
◦
Once the Checking Repository job completes all child job successfully, return to this procedure and continue with the next step.
7.
In the Configuration dialog box, do one of the following:
◦
To use the default retention policy for this protected machine, select Use Core default retention policy, and then click Save. The default policy is applied to this agent.
◦
To define a custom retention policy for this agent, select Use custom retention policy, and then continue with the next step.
The Configuration dialog box expands to show custom retention policy information.
8.
Enter the custom schedule for retaining the recovery points as described in the following table.

Table 153. Schedule options for custom 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, and 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, and 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, and 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, and 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 and 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 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, 3 months old.

9.
If you want to retain all recovery points in your primary repository, clear the Relocate outdated recovery points to an R3 repository option and skip the next step.
10.
If you want to relocate recovery points from your primary repository to an R3 repository stored on a Quest DR series backup appliance, do the following:.
a.
Select the Relocate outdated recovery points to an R3 repository option.
b.
Specify the age at which you want to relocate recovery points from your primary repository to the R3 repository.
You can specify the age by weeks, months or years. The shortest period you can set is 1 week.
c.
From the Select a repository drop-down menu, select the R3 repository to which you want to tier the specified recovery points.
* 
NOTE: Regardless of where recovery points are located (local DVM repository or in a remote R3 repository on a DR backup appliance), they are still subject to the retention policy, and will still be rolled up. If you need to retain older recovery points, one method is to archive. The other approach is to disable rollup or extend the retention period for the relevant protected machines.
11.
Click Save.

Forcing rollup for a protected machine

You can bypass your scheduled retention policy by forcing recovery points to roll up at the protected machine level.

1.
From the Protected Machines menu of the Rapid Recovery Core Console, click the name of a specific protected machine.

The Summary page for the selection machine appears.

2.
Click the More drop-down menu at the top of the protected machine view, and then select Retention Policy.
The Retention Policy page for the specified machine appears.
3.
Click Force Rollup.
4.
In the dialog box, click Yes to confirm.
Rapid Recovery initiates rollup for this machine, regardless of the retention policy schedule.

Archiving

Understanding archives
Creating an archive
Editing a scheduled archive
Pausing or resuming a scheduled archive
Forcing an archive job
Checking an archive
Attaching an archive
Importing an archive

This section describes business cases for creating an archive, how to create an archive using Rapid Recovery, and where you can store it.

Understanding archives

Archive creation and storage options
Recovery point chain options for archives
Methods to access an archive
Uses for archives

The Rapid Recovery Core saves snapshot data to the repository. While a repository can reside on different storage technologies (such as SAN, DAS, or NAS), the most critical performance factor is speed. Repositories use short-term (fast and expensive) media. To prevent a repository from filling up quickly, the Core enforces a retention policy, which over time rolls up recovery points and eventually replaces them with newer backup data.

If you need to retain recovery points, whether for historical significance, legal compliance, to fulfill offsite data storage policies, or other reasons, you can create an archive. An archive is a copy of recovery points from your repository for the specified machines over a date range that you designate. Archiving a set of recovery points does not delete the original recovery points in your repository. Instead, the archive freezes the collection of recovery points at the point in time in which the archive was created. Unlike recovery points in your repository, the data in an archive are not subject to rollup.

You can create, import, and attach archives from the [Archive] Archive option on the button bar, or from the Archives page accessible from the [More] (More) icon on the Core Console.

Archive creation and storage options
Recovery point chain options for archives
Methods to access an archive
Uses for archives
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating