Rapid Recovery 6.4 - User Guide

Using the command line to make a restored Linux machine bootable

1. You must mount the root volume first and then the boot volume. Mount each restored volume by using the following commands:
   1. To mount the root volume, type the following command and then press Enter:

          mount /<restored volume[root]> /mnt

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

   2. To mount the boot volume, type the following command and then press Enter:

          mount /<restored volume[boot]> /mnt/boot

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

      NOTE: Some system configurations may include the boot directory as part of the root volume.

2. If the volume size is increasing — that is, if the destination volume on the new Linux machine is larger than the volume was in the recovery point — then you must delete any existing bitmap data files.
3. Obtain the Universally Unique Identifier (UUID) of the new volumes by using the blkid command. Type the following and then press Enter:

       blkid [volume]

   NOTE: You can also use the ls -l /dev/disk/by-uuid command.

4. If performing a BMR on a brand new disk on the destination machine, comment out the swap partition in fstab in your root volume.
5. Modifying fstab and mtab paths should occur on the restored volume, not the Live DVD. There is no need to modify paths on the Live DVD. Prepare for the installation of Grand Unified Bootloader (GRUB) by typing the following commands. Following each command, press Enter:

        mount --bind /dev /mnt/dev

        mount --bind /proc /mnt/proc

        mount --bind /sys /mnt/sys

6. Change root directory by typing the following command and then press Enter:

        chroot /mnt /bin/bash

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:

        less /mnt/etc/fstab

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:

        less /mnt/etc/mtab

9. If using SLES 11, install GRUB by typing the following commands, pressing Enter after each:

        grub-install --recheck /dev/sda

        grub-install /dev/sda

10. If using Ubuntu, CentOS 6.x, RHEL 6.x, or Oracle Linux 6.x, install GRUB by typing the following command, and then press Enter:

         grub-install /dev/sda

11. If using SLES 12, CentOS 7, RHEL 7, or Oracle 7, install GRUB2 by typing the following command, and then press Enter:

           grub2-install /dev/sda

12. After you complete installation, run one of the following updates:
    For SLES:

         grub-install.unsupported --recheck /dev/sda 
         grub-install.unsupported /dev/sda
         update-grub

    NOTE: If the update-grub command does not exist on your Linux distribution, omit this option.

    For other distributions:

         grub-install /dev/sda 
         update-grub

    NOTE: If the update-grub command does not exist on your Linux distribution, omit this option.

13. Remove the Live DVD disk from the CD-ROM or DVD drive and restart the Linux machine.

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.

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

Topics include:

Data retention 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.

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, 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:

• All recovery points for three days
• One recovery point per hour for two days
• One recovery point per day for four days
• One recovery point per week for three weeks
• One recovery point per month for two months
• One recovery point per year for X years (disabled in default policy).

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.