SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Storage and Data Replication › Disaster Recovery with Rear (Relax-and-Recover)
ContentsContents
Administration Guide
  1. About This Guide
  2. I Installation and Setup
    1. 1 Product Overview
    2. 2 System Requirements and Recommendations
    3. 3 Installation and Basic Setup
  3. II Configuration and Administration
    1. 4 Configuration and Administration Basics
    2. 5 Configuring and Managing Cluster Resources (Web Interface)
    3. 6 Configuring and Managing Cluster Resources (Command Line)
    4. 7 Adding or Modifying Resource Agents
    5. 8 Fencing and STONITH
    6. 9 Access Control Lists
    7. 10 Network Device Bonding
    8. 11 Load Balancing
    9. 12 GEO Clusters (Multi-Site Clusters)
  4. III Storage and Data Replication
    1. 13 OCFS2
    2. 14 GFS2
    3. 15 DRBD
    4. 16 Cluster Logical Volume Manager (cLVM)
    5. 17 Storage Protection
    6. 18 Samba Clustering
    7. 19 Disaster Recovery with Rear (Relax-and-Recover)
  5. IV Appendix
    1. A Troubleshooting
    2. B Naming Conventions
    3. C Cluster Management Tools
    4. D Upgrading Your Cluster and Updating Software Packages
    5. E Documentation Updates
  6. Terminology
  7. F GNU Licenses
Navigation←→
SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Storage and Data Replication › Disaster Recovery with Rear (Relax-and-Recover)
Top
←→
Applies to SUSE Linux Enterprise High Availability Extension 12

19 Disaster Recovery with Rear (Relax-and-Recover)

19.1 Conceptual Overview
19.2 Preparing for the Worst Scenarios: Disaster Recovery Plans
19.3 Setting Up Rear
19.4 Storing your Backup on a NFS Server
19.5 Using the YaST Rear Module
19.6 For More Information

Relax-and-Recover (formerly “ReaR”, in this chapter abbreviated as Rear) is an administrator tool-set for creating disaster recovery images. The disaster recovery information can either be stored via the network or locally on hard disks, USB devices, DVD/CD-R, tape or similar media. The backup data is stored on a network file system (NFS).

Keep in mind, Rear needs to be configured and tested before any disaster happens. Rear will not save you, if a disaster has already taken place.

Warning
Warning: Extensive Testing Required

It is essential, whenever you create a disaster recovery media, to always test the disaster recovery with an identical test machine. Only if this procedure works satisfactorily is your disaster recovery system correctly and reliably set up.

19.1 Conceptual Overview

Rear supports several backup tools (Tivoli Storage Manager, QNetix Galaxy, Symantec NetBackup, EMC NetWorker, HP DataProtector) and can output its recovery medium to a CD or PXE environment. The restore step is possible through NFS, CIFS, or other network file systems.

To use Rear you need at least two identical systems: the main machine where your production environment is stored and the test machine. “Identical” in this context means, for example, you can replace a network card with another one using the same Kernel driver. If a hardware component does not use the same driver, it is not considered identical by Rear.

SUSE Linux Enterprise Server ships a disaster recovery system in the rearVERSION package.

Rear is used in the following way:

  1. Preparation.  Make a bootable CD, backup system.

  2. Testing.  Test the recovery process thoroughly and the backup on the same hardware as your main system before any disaster happens!

  3. Recovery.  Boot from the recovery medium and restore your system from your backup.

To prepare the rescue media, the following steps are performed by Rear:

Preparation of Recovery Media by Rear

  1. Gather system information from the target system.

  2. Store disk layout (partitioning, filesystems, LVM, RAID, and boot loader).

  3. Clone the system (Kernel drivers and modules, device driver configuration, network configuration, system software and tools).

  4. Backup system and user data.

  5. Create bootable recovery medium with system configuration.

When a disaster occurrs, the recovery process consists of these actions:

Recovery Process

  1. Boot from the recovery medium.

  2. Restore the disk layout (partitions, RAID configurations, LVM, file systems).

  3. Restore system and user data.

  4. Restore boot loader.

  5. Reboot system.

Note
Note: Rear with Subvolumes and Snapshots in btrfs Filesystems

Due to technical and conceptual issues, Rear and the btrfs tools has some limitations you should be aware of:

  • btrfs with subvolumes, but no snapshots. at least Rear version 1.15 is required as this version supports restoring the btrfs subvolume structure. The backup and restore of the data should work.

  • btrfs with subvolumes that contain snapshots. The usual backup and restore cannot work for the data in the snapshot. Ordinary backup tools (for example, tar) cannot distinguish between data and btrfs snapshot structure. One workaround is to exclude the data in the btrfs snapshot and store this data and the normal data separately.

19.2 Preparing for the Worst Scenarios: Disaster Recovery Plans

Before the worst scenario happens, take actions to prepare with a disaster recovery plan. A disaster recovery plan is a document where all risks, infrastructure, and the budget is being collected. Maybe you have already some plan in place, but here is the general overview:

  • Risk Analysis.  Conduct a solid risk analysis of your infrastructure. List all the possible threats and evaluate how serious they are. Determine how likely these threats are and prioritize them. It is recommended to use a simple categorization: probability and impact.

  • Budget Planing.  The outcome of the analysis is an overview, which risks can be tolerated and which are critical for your business. Ask yourself, how can you minimize risks and how much will it cost. Depending on how big your company is, spend two to fifteen percent of the overall IT budget on disaster recovery.

  • Disaster Recovery Plan Development.  Make checklists, test procedures, establish and assign priorities, and inventory your IT infrastructure. Define how to deal with a problem when some services in your infrastructure fail.

  • Test.  After defining an elaborate plan, test it. Test it at least once a year. Use the same testing hardware as your main IT infrastructure.

19.3 Setting Up Rear

To configure Rear, add your options into the configuration file /etc/rear/local.conf. The former file /etc/rear/sites.conf has been removed from the package. If you have such a file from your last setup, Rear will still use it.

Define your output method by using the OUTPUT variable. For example, to output your recovery medium as ISO image, use: 

OUTPUT=ISO

After you have changed your configuration file, make sure everything is correct by running the following command:

rear dump

Examine the output and look for any errors.

Find more information in the man page of Rear (man rear).

19.4 Storing your Backup on a NFS Server

Rear can be used in different scenarios. The following example uses a NFS server as backup storage:

Procedure 19.1: Storing Your Backup on a NFS Server

  1. Set up a NFS server with YaST as described in Sharing File Systems with NFS from http://www.suse.com/doc/sles11/book_sle_admin/data/cha_nfs.html.

  2. Make sure you NFS server has the appropriate configuration in the /etc/exports file:

    /srv/nfs    *(fsid=0,crossmnt,rw,no_root_squash,sync,no_subtree_check)

  3. Adapt the configuration file /etc/rear/local.conf. Replace the NETFS_URL with your own values.

    If your NFS host is not an IP address but a hostname, DNS must work when the backup is restored. Further options are listed in the Various Settings section of the documentation at http://rear.github.com/documentation/. 

    # Create rear rescue media as ISO image:
OUTPUT=ISO
# Store the backup file via NFS on a NFS server:
BACKUP=NETFS
# BACKUP_OPTIONS variable contains the NFS mount options and
# with 'mount -o nolock' no rpc.statd (plus rpcbind) are needed:
BACKUP_OPTIONS="nfsvers=3,nolock"
# If the NFS server is not an IP address but a hostname,
# DNS must work in the rear recovery system when the backup is restored.
BACKUP_URL=nfs://192.168.1.1/nfs/rear/
# Keep an older copy of the backup in a HOSTNAME.old directory
# provided there is no '.lockfile' in the HOSTNAME directory:
NETFS_KEEP_OLD_BACKUP_COPY=yes
# Files in btrfs subvolumes are excluded by 'tar --one-file-system'
# so that such files must be explictly included to be in the backup.
# Files in the following SLE12 default btrfs subvolumes are
# in the below example not included to be in the backup
#   /.snapshots/*  /var/tmp/*  /tmp/*  /var/crash/*
# but files in /home/* are included to be in the backup
# (one line!):
BACKUP_PROG_INCLUDE=( '/home/*' '/var/spool/*' '/var/opt/*' '/var/log/*' 
  '/var/lib/pgsql/*' '/var/lib/mailman/*' '/var/lib/named/*' '/usr/local/*' 
  '/srv/*' '/boot/grub2/x86_64-efi/*' '/opt/*' '/boot/grub2/i386-pc/*' )
# Avoid that "rear recover" is 'Creating btrfs-filesystem' by default
# also for every mounted btrfs subvolume by excluding the mountpoints
# of the mounted btrfs subvolumes from component recreation
# see /usr/share/doc/packages/rear/user-guide/06-layout-configuration.txt
# and /usr/share/rear/conf/default.conf
# When /home is a separated filesystem remove "fs:/home" from the list below
# (one line!):
EXCLUDE_RECREATE=( "${EXCLUDE_RECREATE[@]}" "fs:/home" "fs:/.snapshots" 
   "fs:/var/tmp" "fs:/var/spool" "fs:/var/opt" "fs:/var/log" 
   "fs:/var/lib/pgsql" "fs:/var/lib/mailman" "fs:/var/lib/named" 
   "fs:/usr/local" "fs:/tmp" "fs:/srv" "fs:/var/crash" 
   "fs:/boot/grub2/x86_64-efi" "fs:/opt" "fs:/boot/grub2/i386-pc" )
# This option defines a root password to allow SSH connection
# whithout a public/private key pair
#SSH_ROOT_PASSWORD="password_on_the_rear_recovery_system"

  4. Prepare the backup by running: 

    rear -v mkbackup

To perform a disaster recovery on your test machine, proceed as follows:

Procedure 19.2: Perform Disaster Recovery on Test Machine

  1. Locate the recovery ISO image stored as /var/lib/rear/output/rear-HOSTNAME.iso and burn it on CD.

  2. Boot your test machine with the recovery CD.

  3. Select Recover NAME from the menu selection and press Enter.

  4. Log in as root (no password needed).

  5. Enter rear recover to start the recovery process. The recovery process installs and configures the machine and retrieves the backup data from your NFS server.

After this procedure, make sure the test machine is correctly set up and can serve as a replacement for your main machine. Test this procedure on a regular basis to ensure everything works as expected. Keep copies of the recovery CD, in case the media is damaged.

To use EMC Networker as backup tool, use the following configuration file (change the BACKUP_URL accordingly):

BACKUP=NSR
OUTPUT=ISO
BACKUP_URL=nfs://dd990.example.com/data/col1/rear/backup
OUTPUT_URL=nfs://dd990.example.com/data/col1/rear/output
NSRSERVER=backupserver.example.com
RETENTION_TIME="Month"

19.5 Using the YaST Rear Module

The YaST Rear module can be used to start with a basic setup. Rear saves the recovery image and data on an NFS backend or a USB stick. However, the YaST Rear module does not support recovery from a disaster. This requires some expertise and has to be done manually by the administrator.

To start with a basic setup, proceed as follows:

  1. Decide how to start your recovery system. Choose USB if you want to boot from a USB stick or ISO for CD-ROM respectively.

  2. Decide where the backup should be stored. Either select NFS or USB:

    • Select NFS if you have to use a server that offers Network File System. Specify the location as nfs://hostname/directory.

    • Select USB if you want to store your data on a USB stick. If no USB devices are shown, attach a USB stick or a USB disk and click Rescan USB Devices.

  3. If you want a previous backup copy to be saved, check Keep old backup.

  4. If you want to add additional directories that should also be included in your backup, use the Advanced menu and select Additional Directories in Backup.

  5. In case your rescue system does not boot due to missing Kernel modules, use the Advanced menu, select Additional Kernel Modules in Rescue System, and add the respective Kernel modules into the list of added modules for your rescue system.

  6. Click the Save and run rear now button to start the backup process.

After the YaST Rear module is finished with the backup, test your backup to make sure it works as expected.

19.6 For More Information

→Part IV Appendix←Chapter 18 Samba Clustering
Print this page

© 2017 SUSE