Chat now with support
Chat mit Support

Rapid Recovery 6.4 - User Guide

Introduction to Rapid Recovery The Core Console Repositories Core settings 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 Credentials Vault Snapshots and recovery points 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

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.

NOTE: This procedure applies to Linux machines that use GRUB1 or GRUB2. When using this procedure, ensure that the boot partition is healthy and protected.

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. This process typically takes longer 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.

  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.

NOTE: Administrators should note that frequent backups can have an impact on network traffic. Other factors affecting network traffic include other transfers (such as replication), the change rate of your data, and your network hardware, cables and switches.

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.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen