Relax-and-Recover boots a rescue image on replacement hardware and restores into it

ReaR restores a machine, it does not restore files

Relax-and-Recover, abbreviated ReaR, is described as the de facto standard disaster recovery framework on Linux, in particular used on enterprise distributions like Red Hat Enterprise Linux and SUSE Linux Enterprise Server.

The distinction the README makes is the important one. ReaR is a system administrator tool and framework to create a bootable disaster recovery system image for bare metal disaster recovery with data backup restore on physical or virtual replacement hardware. It is not backup management software. ReaR complements backup and restore of data with bare metal disaster recovery, and in many enterprise environments the data backup and restore happens via dedicated backup software which is integrated by ReaR and used to restore the data onto a replacement system as part of the automated disaster recovery procedure.

So the unit of work is a machine, not a file. The recovery system is booted on pristine replacement hardware. On that hardware the storage setup and layout is recreated, meaning disk partitioning, filesystems and mount points, then a backup restore program is called to restore the data into the recreated storage, and finally a boot loader is installed.

That sequence is the whole architecture. The rescue system exists so that the recreated machine has enough of an operating system to receive a backup stream and to install a bootloader, because the original machine's disk layout and bootloader are exactly what was lost.

The project is GPL-3.0 licensed, the last push was on 2026-10-15, and the release history shows a snapshot build from the same day alongside the release/2.9 branch from 2025-01-31.

Twenty-five BACKUP values, and most of them are other people's products

The BACKUP=... value is the heart of the configuration, and the list of supported values is the clearest statement of what ReaR is: a restore orchestrator that drives whichever backup system you already run.

The list includes AVA for Dell EMC Avamar, BACULA for Bacula, BAREOS for Bareos, BLOCKCLONE for block device cloning via dd, BORG for Borg Backup, CDM for Rubrik Cloud Data Management, COH for Cohesity DataProtect, DP for OpenText Data Protector, DUPLICITY for Duplicity, EXTERNAL for a custom restore method, FDRUPSTREAM for FDR/Upstream, GALAXY11 for Commvault, NBKDC for NovaStor DataCenter, NBU for Veritas NetBackup, NETFS for ReaR built-in backup and restore via rsync or tar to a network file system or to a locally attached backup disk, NFS4SERVER to push data to the rescue system, NSR for Dell EMC NetWorker, OBDR for One Button Disaster Recovery via tape, PPDM for Dell PowerProtect Data Manager, RBME for Rsync Backup Made Easy, REQUESTRESTORE to request a restore from a human operator, RSYNC for ReaR built-in backup using rsync over rsync or ssh protocol, SESAM for SEP Sesam, TSM for IBM Storage Protect, and VEEAM for Veeam Backup.

Two entries in that list are unusual. REQUESTRESTORE is a mode where a human operator performs the restore, which is a real workflow in enterprises where the person restoring needs to make judgement calls about what to bring back. OBDR is the one-button tape recovery that large sites use for physical machine replacement.

NETFS, RSYNC and BOREOS are the built-in paths. The project also has built-in backup methods using tar and rsync, and the NETFS description is the one to read carefully because it is the default in the quick start: rsync or tar to a network file system or to a locally attached backup disk, which can be USB or eSATA.

Bash only, and dependencies are declared when you need them

The requirements section makes a claim that is unusual for a tool of this age: Relax-and-Recover is written entirely in Bash and does not require any external programs. It utilizes the standard tools on your Linux system to create the rescue system, and works out of the box on most systems.

The subtlety is in the packaging rather than the code. Because ReaR supports many use cases and many third-party backup tools, the packages have only the dependencies for the ReaR core functionality, and not for all the tools required for all the ReaR features. The stated reason is to keep the install size small when you do not need all the features. When you use it, ReaR will let you know if your specific use case or workflow requires additional tools and ask you to install them.

That is a deliberate design: the core is a small set of shell scripts plus standard utilities, and the integration with each backup product pulls in that product's own client tools at the point where you configure that workflow. The alternative, shipping every client in every package, would make the install size follow the union of all possible deployments rather than the actual one.

The repository layout is consistent with that. usr/ holds the executable code, etc/ holds the configuration templates and defaults, doc/ the documentation, tests/ the test suite, tools/ helper scripts, and packaging/ holds the distribution packaging, with a .fmf/ directory for the metadata used by the packaging pipeline.

The Makefile is where the packaging details live, and it shows the multi-distribution support. It sets SHELL = bash explicitly, with the comment explaining that in some distributions such as Ubuntu bash is not the default shell and the statements assume bash. It also derives the version from the usr/sbin/rear script itself, reading a readonly VERSION= line with awk, and for non-official builds it assembles a version stamp from the git commit count, the short commit hash and the branch name, appending .changed when the working tree is dirty.

The quick start is format, configure, mkrescue, mkbackup, recover

The quick start guide shows how to run ReaR from a git checkout and create a bootable USB backup and rescue medium. You can skip the clone entirely and download a snapshot build from the GitHub Releases page and continue from rear format.

The first step is to prepare the USB medium. Change /dev/sdX to the correct device in your environment, and note that Relax-and-Recover will own the whole device, and that this will destroy all data on that device:

sudo usr/sbin/rear format /dev/sdX

You confirm the format, and the device gets labeled REAR-000 by the rear format workflow.

The second step is the configuration file, etc/rear/local.conf, and the three variables that matter are OUTPUT, BACKUP and BACKUP_URL:

### write the rescue initramfs to USB and update the USB bootloader
OUTPUT=USB

### create a backup using the internal NETFS method, using 'tar'
BACKUP=NETFS

### write both rescue image and backup to the device labeled REAR-000
BACKUP_URL=usb:///dev/disk/by-label/REAR-000

The third step creates the rescue image on the USB device, and you want verbose output with the -v option:

sudo usr/sbin/rear -v mkrescue

The output shows the disk layout being created, the root filesystem layout, files and directories and binaries and libraries copied, kernel modules copied, an initramfs created, an MBR written to the device, and the resulting files copied to the USB location. The log file is at /var/log/rear/rear-<hostname>.log.

The final step is the actual backup, on the normal system with the USB device connected:

sudo usr/sbin/rear -v mkbackup

And if the system is destroyed, you boot from the USB rescue medium, log in as root with no password, and call rear -v recover.

The rescue environment is a root shell with no password, by design

Two details in the quick start are easy to skim and important to understand.

The first is that the rescue environment logs you in as root with no password. That is not an oversight, it is the design of a rescue system: it is a minimal environment whose only job is to run the restore, and an authentication prompt on a machine you are standing in front of during a hardware failure adds nothing.

The second is the test procedure the README recommends. After creating the rescue image, you reboot and verify that you can boot the ReaR rescue environment from the USB device as a test, log in as root and directly shut it down, since it was only a test, then boot your normal system again.

That advice is the most useful line in the guide for anyone adopting ReaR. A rescue image that has never been booted is an untested artefact, and the failure you discover during an actual outage is the worst possible time to discover it. The mkbackup step is equally not a proof, because a successful backup says the data was written, not that the data can be restored onto a machine with a different disk layout.

The step that actually proves the procedure is a recover onto replacement hardware, and the README does not include it in the quick start for the obvious reason that it is destructive and slow. Any team adopting ReaR should schedule that test with a spare machine rather than waiting for the incident.

ReaR needs a DR procedure, not just a backup

The README's framing of the role is worth repeating because it draws a line that teams often get wrong. System administrators use the ReaR framework to set up a disaster recovery procedure as part of their disaster recovery policy, which complements their existing backup policy.

The distinction is between a mechanism and a policy. ReaR gives you the mechanism, the bootable image and the orchestration of the restore. The policy is the part where an organisation decides what gets restored, how fast, in what order, and who authorises it, and that is the part no tool can supply.

The REQUESTRESTORE backup method is the clearest expression of the point. In that mode the restore is performed by a human operator, because the decision about what to bring back is a business decision rather than a technical one. A framework that only supported automated restore would be assuming away the part of the problem that is actually hard.

There is also the central management angle. ReaR integrates well with Disaster Recovery Linux Manager, DRLM, at drlm.org, which can act as a central management tool for ReaR deployments. That is the piece that turns a per-host tool into something an organisation can run across a fleet, with the operational questions of who recovers what, and when, answered in one place rather than in a runbook per host.

Professional services and support are offered separately, which is a reasonable signal about the audience. The tool is free and open, and the organisations using it are the ones with compliance obligations around disaster recovery, which is where a support contract is a normal purchase.

Where Relax-and-Recover is the wrong tool

The first wrong-tool case is a file-level backup need. If what you want is to restore a user's home directory or a database dump onto a running system, ReaR is the wrong shape of tool. It builds a rescue system and restores a whole machine onto replacement hardware, and that is a heavier operation than a file restore by a wide margin.

The second is a non-Linux platform. ReaR is a Bash framework that creates a bootable rescue image and installs a boot loader, and its assumptions are about Linux storage layouts, initramfs and enterprise distributions. The project name makes the scope clear, and the comparisons in the repository description point at mksysb and ignite, which are the same category of tool on the same platform.

The third is a virtualised fleet where the platform restores machines itself. If the hypervisor or the cloud provider can rebuild a host from an image and reattach a disk, then the part ReaR provides, recreating the storage layout and installing a bootloader, is work the platform already does. ReaR earns its keep where the replacement hardware is genuinely bare metal and someone has to rebuild the boot stack by hand.

The fourth is the operational weight. A rescue system that runs as root with no password, a restore that has to be rehearsed on spare hardware, and a configuration file where the wrong BACKUP value produces a rescue image that restores nothing, all of that is real work to own. The tool is free, but the procedure around it is not.

Editorial conclusion

ReaR fits a Linux system administrator who has to rebuild a failed physical or virtual host from a backup onto replacement hardware, particularly on RHEL or SLES, and it does not fit a team that only needs to restore files or that runs a non-Linux platform. Before running it, read the BACKUP value for your actual backup system in the list, since the built-in tar and rsync methods are not the same thing as integrating your existing backup software, and test a full recover onto a spare machine rather than trusting a successful mkbackup.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. rear/rear on GitHub
5. Releases