Rapid Recovery 6.2 - User Guide

Introduction to Rapid Recovery Core Console Core settings
Core settings key functions Rapid Recovery Core settings Core-level tools
Repositories Managing privacy Encryption 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 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 Verifying a bare metal restore
Managing aging data Archiving Cloud accounts The Local Mount Utility Core Console references REST APIs About us Glossary

Using the command line to make a restored Linux machine bootable

Once you complete a clean file system check on the restored volume, you must create bootable partitions.

GNU Grand Unified Bootloader (GRUB) is a boot loader that allows administrators to configure which operating system or specific kernel configuration is used to start the system. After a BMR, the configuration file for GRUB must be modified so that the machine uses the appropriate universally unique identifier (UUID) for the root volume. Before this step you must mount the root and boot volumes, and check the UUIDs for each. This ensures that you can boot from the partition.

GRUB or GRUB2 is typically installed with Linux operating systems. You can perform this procedure using the version that comes with your Linux distribution. If a version of GRUB is not installed, you will have to re-install the default version appropriate for your Linux distribution.

CAUTION: When you boot a restored Linux machine for the first time after a BMR, Rapid Recovery takes a base image of the restored machine. Depending on the amount of data on the machine, this process takes more time than taking an incremental snapshot. For more information about base images and incremental snapshots, see Understanding protection schedules.

This task is a step in Performing a bare metal restore for Linux machines. It is part of the process for Verifying the bare metal restore from the command line.

Perform the task below to create bootable partitions using the command line.

For example, if /dev/sda2 is the root volume, then type mount /dev/sda2 /mnt and then press Enter.

For example, if /dev/sda1 is the boot volume, then type mount /dev/sda1 /mnt/boot and then press Enter.

3.
Obtain the Universally Unique Identifier (UUID) of the new volumes by using the blkid command. Type the following and then press Enter:
NOTE: You can also use the ls -l /dev/disk/by-uuid command.
7.
Obtain the old UUID of the partition or partitions from the mounted recovery points /etc/fstab file and compare it to the UUIDs for the root (for Ubuntu and CentOS), boot (for CentOS and RHEL), or data partitions by typing the following command and then press Enter:
8.
Obtain the old UUID of the partition or partitions from the mounted recovery points /etc/mtab file and compare it to the UUIDs for the root (for Ubuntu and CentOS), boot (for CentOS and RHEL), and data partitions by typing the following command and then press Enter:
NOTE: If the update-grub command does not exist on your Linux distribution, omit this option.
NOTE: If the update-grub command does not exist on your Linux distribution, omit this option.

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 ability to relocate recovery points from your repository to a Quest DR backup and deduplication appliance.

This section also describes how to manage retention policies that control rollup, and how to force rollup on demand.

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 DVM repository to a tiering 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 secondary tiering repository on a DR, see Creating a tiering repository. Then, at the protected machine level, specify in the retention policy the age at which you want recovery points to relocate from your primary to your secondary repository. For more information, see Customizing retention policy settings for a protected machine (especially steps 7 and 10).

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.

For more information about archives, see Archiving.

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 (as frequently as once per hour for the DL1000), 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.

Related Documents