3 Managing Backups With ReaR

ReaR is a disaster recovery tool that you can use on Oracle Linux systems in the local data center. ReaR automatically generates a bootable recovery environment and external file backups.

You can schedule the creation of ReaR rescue systems by using, for example, a systemd timer, or the Crontab utility. You can use ReaR to restore lost user and system files to the original directory locations.

To find out more about ReaR, see https://relax-and-recover.org/, and the rear(8) manual page that's available after you have installed ReaR.

Installing ReaR

Install the rear package from the Oracle Linux yum server.

sudo dnf install rear

Creating a ReaR Rescue System

Use ReaR to create a bootable device that can be used to restore the underlying system and copy data from an external source.

Prerequisites

Before proceeding, you need to install the packages required to create a bootable recovery environment as an ISO image file as described in the following tabbed sections:

Install the xorriso and syslinux packages by running the following command:

sudo dnf install xorriso syslinux

Install the xorriso and syslinux packages by running the following command:

sudo dnf install xorriso syslinux

Install the genisoimage and syslinux packages by running the following command:

sudo dnf install genisoimage syslinux

Configuring a ReaR Rescue System

The rescue system configuration is stored in the /etc/rear/local.conf file.

Note:

For a guide to standard configuration of all available parameters that can be used in /etc/rear/local.conf, see the /usr/share/rear/conf/default.conf file.

Define the storage medium by setting the OUTPUT parameter and the ISO image file location, which is specified by the OUTPUT_URL parameter:

OUTPUT=ISO
OUTPUT_URL=file:///mnt/rescue_system/

This configuration generates an ISO image file in the /var/lib/rear/output/ directory as /mnt/rescue_system/host_name/rear-localhost.iso. You can also replace file:/// with nfs:// for network storage mounts.

If disk space is limited, optionally configure ReaR to omit /var/lib/rear/output/ to only generate a single ISO image file in the /mnt/rescue_system directory:

OUTPUT=ISO
BACKUP=NETFS
OUTPUT_URL=null
BACKUP_URL=iso:///backup
ISO_DIR=/mnt/rescue_system

To automatically generate a file backup each time the recovery system is generated, see Using ReaR to Back Up Files.

Generating a ReaR Rescue System

After you have configured the base settings for a rescue system, generate an ISO image file by using the mkrescue command:

sudo rear mkrescue

For information about how to create USB installation media from an ISO file by using the dd command, you can visit one of the following links:

Scheduling the Creation of ReaR Rescue Systems

Use a systemd timer to schedule the creation of a ReaR rescues system.

What Do You Need?

The following procedure assumes you have configured and tested the creation of the ReaR rescue system you intend to schedule. For more information about configuring and generating a ReaR rescue system see Configuring a ReaR Rescue System and Generating a ReaR Rescue System

For the purposes of the example, the steps in the following procedure show how you would use a systemd timer, with a corresponding systemd service unit, to automatically generate a new rescue system every weekday at 22:00 hrs.

To schedule the creation of the of a Rear rescue system, perform the following steps:

Steps

  1. Create a systemd service file that runs the rear mkrescue command used to create ReaR rescue systems.

    For example, create a file named rear-mkrescue.service in the /usr/lib/systemd/system directory with the following content:

    [Unit]
    Description=Service unit that creates ReaR rescue system using the rear mkrescue command. 
    
    [Service]
    Type=oneshot
    ExecStart=/usr/sbin/rear mkrescue
  2. Create a corresponding systemd timer file named rear-mkrescue.timer to schedule the activation of the rear-mkrescue.service file created in the preceding step.

    For example, to trigger the service every weekday at 22:00 hrs, create file /usr/lib/systemd/system/rear-mkrescue.timer with the following content:

    [Unit]
    Description=Timer to activate the service unit according to schedule defined in this file. 
    
    [Timer]
    OnCalendar=Mon..Fri 22:00:00
    
    [Install]
    WantedBy=timers.target

    Note:

    By default, the systemd timer activates a systemd service with a matching name (excluding the suffix). Hence the file names used in this example: rear-mkrescue.timer and rear-mkrescue.service. For more information see systemd.timer(5).

  3. To enable and start the timer, run the following commands:
    sudo systemctl enable rear-mkrescue.timer
    sudo systemctl start rear-mkrescue.timer
  4. Use the systemctl list-timers command to check that the timer has been scheduled as expected:
    sudo systemctl list-timers

    The preceding command outputs information on timer units in ascending order of scheduled time. In the following sample output, the rear-mkrescue.timer is next scheduled to activate the service at Fri 2025-06-06 22:00 GMT:

    NEXT                            LEFT LAST                              PASSED UNIT                         ACTIVATES                     
    ...
    Fri 2025-06-06 21:00 GMT        ...         
    Fri 2025-06-06 22:00 GMT      13h Thu 2025-06-05 22:00 GMT 11h ago rear-mkrescue.timer          rear-mkrescue.service
    Fri 2025-06-06 22:30 GMT..      ...
    ...
For more information on using systemd timers see the manual page systemd.timer(5). You can also visit the following links:

Using ReaR to Back Up Files

In addition to creating a rescue system, you can optionally configure ReaR to generate a full file backup at the same time.

Creating Tarball Backups

To create a full file backup and store the results as a tarball, edit the /etc/rear/local.conf file. The following list describes selected parameters that you can define:

  • BACKUP and BACKUP_URL settings would generate output tar files in the /srv/backup directory, for example:

    OUTPUT=ISO
    OUTPUT_URL=file:///mnt/rescue_system/
    BACKUP=NETFS
    BACKUP_URL=file:///srv/backup/
  • The NETFS_KEEP_OLD_BACKUP_COPY setting can be used to keep the previous backup by renaming it before creating the new one, for example:

    NETFS_KEEP_OLD_BACKUP_COPY=y
  • To create a full ISO image file, change the BACKUP_URL as follows:

    BACKUP_URL=iso:///backup/
  • When BACKUP_URL points to an NFS share, and settings BACKUP=NETFS, and BACKUP_PROG=tar (the default) are being used, the following properties can be configured:

    • The BACKUP_TYPE setting conserves disk space by making backups incremental, for example:

      BACKUP_TYPE=incremental
    • The FULLBACKUPDAY is used to ensure a full backup is made on certain days of the week, irrespective of the BACKUP_TYPE setting. For example:

      FULLBACKUPDAY=(Sun)

Generating Backups With ReaR

To verify whether the file system has changed from the last time you generated a backup, type:

sudo rear checklayout

If the BACKUP setting in /etc/rear/local.conf is NETFS, you can create three different kinds of backup with ReaR:

  • Create a rescue system without a file backup:

    sudo rear mkrescue
  • Create a file backup without a rescue system:

    sudo rear mkbackuponly
  • Create a rescue system and a file backup:

    sudo rear mkbackup

Testing the ReaR Rescue System

You must periodically test that you can restore from backups to be confident that system recovery is possible. Provision a test system on which you can perform a recovery without losing important data, and then follow these steps:

  1. Boot the test system from recovery media for the rescue system that you generated in Creating a ReaR Rescue System.

  2. Follow the instructions in Recovering a System With ReaR on the test system. For more diagnostic information, add the -v parameter to the recovery command, for example:

    rear -v recover
  3. If the recovery doesn't run correctly on the test system, revise the ReaR configuration and regenerate the rescue system.

  4. Repeat these steps on the test system until the recovery process succeeds.

Recovering a System With ReaR

If an Oracle Linux installation has been rendered unbootable, you can use ReaR to recover the system and restore data. You would run this utility on a dedicated rescue environment that was generated for that device.

  1. Boot the device with the rescue system that you generated in Creating a ReaR Rescue System.

  2. Select the Recover localhost option from the boot loader menu.

  3. Log in to the rescue system as the root user.

    The shell environment uses the credentials that are stored in the /root/.ssh/authorized_keys file, if available. Or, you can manually set the SSH_ROOT_PASSWORD environment variable.

  4. Start the automated recovery process.

    rear recover

    The system's file structure is replicated in the /mnt/local directory. You can optionally use that directory as the output directory for file recovery from an external source.

  5. Extract the tarball contents to /mnt/local:

    tar -xf backup.tar.gz -C /mnt/local

    Note:

    This step assumes that the backup tarball is on the same system that you want to recover. If the tarball is stored remotely, you would need to bring it to the system first.

    For example, to transfer the tarball over an SSH connection, and assuming that the remote tarball is in /mnt/backups/, you would type:

    scp root@example.com:/mnt/backups/backup.tar.gz backup.tar.gz

    To transfer the tarball from a network share, you would type:

    rsync -avzh root@example.com:/mnt/backups/backup.tar.gz .
  6. Set SELinux to relabel on the next boot by creating a blank file called .autorelabel in the /mnt/local directory:

    touch /mnt/local/.autorelabel
  7. Exit the recovery environment by rebooting the system:

    reboot

    When SELinux has relabeled the entire file system, the recovered host system is bootable.

Creating Multiple Backups With ReaR

You can use different rear commands to create a rescue system with files from the underlying system, then back up the data from both the /home and /opt directories.

Common settings for rear are defined in the /etc/rear/local.conf file, but you can override individual values with separate configuration files for each scenario, for example:

  • /etc/rear/basic_system.conf

  • /etc/rear/home_backup.conf

  • /etc/rear/opt_backup.conf

In these configuration files, select which folders to include in the backup and define the output tarball name. To include wider matches, you can provide wildcards (*) in path names that you specify.

For more information and sample configurations, see https://relax-and-recover.org/documentation/.

To create backups with rear, do the following.

  1. Configure the appropriate files that specifies how the backup would run.

    For example, to specify that only the /home directory is included in the /etc/rear/home_backup.conf file, you would add the following configuration definitions:

    BACKUP_ONLY_INCLUDE="yes"
    BACKUP_PROG_INCLUDE=( '/home/*' )
    BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}"
  2. Generate each backup.

    The -C option specifies what configuration file to use.

    sudo rear -C basic_system mkbackup
    sudo rear -C home_backup mkbackuponly
    sudo rear -C opt_backup mkbackuponly
  3. From within the rescue environment, use the same labels to recover the system, for example:

    rear -C basic_system recover
    rear -C home_backup restoreonly
    rear -C opt_backup restoreonly

    To find out more about rear command parameters and recovery options, see the rear(8) manual page.