ReaR Bare Metal Recovery on Linux [Guide]

Most backup guides skip the part that actually matters: the restore. They show you how to tar your files, maybe rsync them somewhere, and call it disaster recovery. But when a server’s boot disk dies, none of that helps unless you can rebuild the entire system from scratch. Partitions, filesystems, bootloader, kernel, configs, data. All of it.

Original content from computingforgeeks.com - post 165103

ReaR (Relax-and-Recover) handles exactly this scenario. It creates a bootable rescue ISO containing a minimal Linux environment with your hardware drivers, disk layout, and network configuration. Pair that with a full system backup archive, and you can rebuild a dead server on completely new hardware. The recovered system is identical to the original, down to the partition table and bootloader. This guide walks through installation, configuration, creating the rescue media and backup, and documents every error encountered during testing. If you’ve used tools like BorgBackup or Restic for file-level backups, ReaR fills the gap they leave: full bare metal recovery.

The process boils down to two artifacts. A bootable ISO that knows your hardware, and a compressed archive of your entire filesystem. When disaster strikes, boot from the ISO, run one command, and ReaR recreates your disk layout and restores everything. No manual partitioning, no reinstalling the OS, no chasing down packages.

What ReaR Does

ReaR produces two things when it runs:

A bootable rescue system (ISO) containing a minimal Linux environment with your exact kernel, hardware drivers, disk layout map, and network configuration
A system backup archive (tar.gz) with every file on your server

During recovery, you boot from the ISO on new or repaired hardware. ReaR reads the saved disk layout and recreates your exact partition table, filesystems, and swap space. It then extracts the backup archive onto the new disks and reinstalls the bootloader. The result is a fully functional server identical to the original. No manual intervention beyond typing rear recover at the prompt.

This is fundamentally different from file-level backup tools. A tar or rsync backup gives you your data back, but you still need a working OS to restore it onto. ReaR gives you the OS too.

Prerequisites

Rocky Linux 10 or Ubuntu 24.04 LTS server
Separate storage for backups: a USB drive, NFS share, or dedicated partition (the backup destination cannot be on the root filesystem)
At least 5 GB free space on the backup storage
Root access or a user with sudo privileges
Tested on: Rocky Linux 10.1 (kernel 6.12.0-124.8.1.el10_1.x86_64), Ubuntu 24.04.4 LTS (kernel 6.8)

Install ReaR

ReaR is available in the default repositories on both Rocky Linux and Ubuntu. The package dependencies differ slightly between the two.

Rocky Linux 10:

sudo dnf install -y rear xorriso syslinux-nonlinux

Note that genisoimage is not available on Rocky 10. The xorriso package handles ISO creation instead. The syslinux-nonlinux package provides the bootloader files needed for the rescue ISO.

Confirm the installed version:

rear --version

Rocky 10 ships ReaR 2.9:

Relax-and-Recover 2.9 / 2025-01-31

Ubuntu 24.04:

sudo apt install -y rear genisoimage

Check the version:

rear --version

Ubuntu 24.04 includes ReaR 2.7:

Relax-and-Recover 2.7 / Git

The version difference matters. ReaR 2.9 on Rocky has newer features but also introduces the GRUB2-BLS detection issue covered in the troubleshooting section below.

OS Differences at a Glance

Before configuring ReaR, here is a quick reference of how the two distributions differ:

Item	Rocky Linux 10	Ubuntu 24.04
ReaR version	2.9	2.7
Package name	rear	rear
ISO creation tool	xorriso	genisoimage
GRUB2-BLS fix needed	Yes	No
Kernel	6.12	6.8
SELinux/AppArmor	SELinux enforcing	AppArmor

Configure ReaR

The main configuration file is /etc/rear/local.conf. The defaults in /etc/rear/default.conf are sane, but you need to tell ReaR where to store backups and what output format to use.

Open the configuration file:

sudo vi /etc/rear/local.conf

Add the following configuration for local backup storage:

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=file:///backup/rear
NETFS_KEEP_OLD_BACKUP_COPY=yes
OUTPUT_URL=file:///backup/rear
EXCLUDE_MOUNTPOINTS=( /tmp )
BOOTLOADER=GRUB2

Here is what each setting does:

OUTPUT=ISO creates a bootable ISO image as the rescue media
BACKUP=NETFS uses the built-in backup method (tar archive over network or local filesystem)
BACKUP_URL=file:///backup/rear stores the backup archive at /backup/rear on a locally mounted filesystem
NETFS_KEEP_OLD_BACKUP_COPY=yes keeps the previous backup when creating a new one, so you always have a rollback
OUTPUT_URL=file:///backup/rear stores the rescue ISO alongside the backup archive
EXCLUDE_MOUNTPOINTS=( /tmp ) skips temporary files from the backup
BOOTLOADER=GRUB2 explicitly sets the bootloader type. This is required on Rocky Linux 10 and RHEL 10 because ReaR 2.9 does not recognize the GRUB2-BLS bootloader variant used by these distributions. Without this setting, ReaR fails with an “Unknown bootloader” error. Ubuntu 24.04 does not need this line, but including it causes no harm

NFS backup variant: If you have a dedicated backup server (the recommended approach for production), use NFS instead of local storage:

BACKUP_URL=nfs://10.0.1.51/backup/rear
OUTPUT_URL=nfs://10.0.1.51/backup/rear

This stores both the rescue ISO and the backup archive on the NFS server at 10.0.1.51. During recovery, the rescue system mounts the NFS share automatically to access the backup.

USB backup variant: For portable disaster recovery media that contains both the bootable rescue system and the backup archive on a single USB drive:

OUTPUT=USB
BACKUP_URL=usb:///dev/disk/by-label/REAR-000

Format the USB drive first with sudo rear format /dev/sdX (where /dev/sdX is your USB device). ReaR labels it REAR-000 automatically.

Prepare Backup Storage

The backup destination must be on a separate filesystem. ReaR enforces this strictly. If you point BACKUP_URL at a directory on the root filesystem, ReaR refuses to run. This is by design because backing up a filesystem onto itself defeats the purpose of disaster recovery.

If you have a dedicated disk (such as /dev/sdb), create a filesystem and mount it:

sudo mkfs.xfs /dev/sdb1
sudo mkdir -p /backup/rear
sudo mount /dev/sdb1 /backup/rear

Make the mount persistent by adding it to /etc/fstab:

echo "/dev/sdb1 /backup/rear xfs defaults 0 0" | sudo tee -a /etc/fstab

For NFS storage, mount the remote share:

sudo mkdir -p /backup/rear
sudo mount -t nfs 10.0.1.51:/backup/rear /backup/rear

Without a separate filesystem, you will see this error when running ReaR:

ERROR: URL 'file:///backup/rear' has the backup directory '/backup/rear' in the '/' filesystem which is forbidden.

The error is clear: ReaR will not back up the root filesystem onto itself.

Create the Rescue ISO

The mkrescue command builds the bootable rescue ISO without creating a backup archive. This is useful for testing your configuration before committing to a full backup run.

sudo rear -v mkrescue

ReaR detects your hardware, kernel, disk layout, and bootloader, then builds a minimal rescue system:

Relax-and-Recover 2.9 / 2025-01-31
Running rear mkrescue (PID 4521 date 2026-03-28 14:32:05)
Using log file: /var/log/rear/rear-backup-rocky.log
Running workflow mkrescue on the normal/original system
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-6.12.0-124.8.1.el10_1.x86_64' as kernel in the rear recover system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct
Creating recovery system root filesystem skeleton layout
Handling network interface 'eth0'
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
Copying logfile /var/log/rear/rear-backup-rocky.log into initramfs as '/tmp/rear-backup-rocky-partial-2026-03-28T14:32:18+00:00.log'
Copying kernel modules
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/6.12.0-124.8.1.el10_1.x86_64 (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Testing that the recovery system in /var/tmp/rear.xxxx/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (112 MiB) in 15 seconds
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-backup-rocky.iso (131M)
Exiting rear mkrescue (PID 4521) and target is the normal/original system
Saving /var/log/rear/rear-backup-rocky.log as /var/log/rear/rear-backup-rocky.log.lockless

The rescue ISO weighs 131 MB and contains a complete bootable Linux system with your kernel and drivers. Verify it exists:

ls -lh /var/lib/rear/output/rear-backup-rocky.iso

You should see the ISO file with its size confirmed:

-rw-------. 1 root root 131M Mar 28 14:32 /var/lib/rear/output/rear-backup-rocky.iso

Copy this ISO to a safe location immediately. If the server dies, you need this file to boot the recovery environment. Store it on a different server, a USB drive, or your backup storage.

Create a Full System Backup

While mkrescue only creates the bootable ISO, mkbackup creates both the rescue ISO and a complete backup archive of your system. This is what you want for full disaster recovery capability.

sudo rear -v mkbackup

The output shows ReaR building the rescue system first, then creating the backup archive:

Relax-and-Recover 2.9 / 2025-01-31
Running rear mkbackup (PID 5102 date 2026-03-28 14:45:12)
Using log file: /var/log/rear/rear-backup-rocky.log
Running workflow mkbackup on the normal/original system
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-6.12.0-124.8.1.el10_1.x86_64' as kernel in the rear recover system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Creating recovery system root filesystem skeleton layout
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (112 MiB) in 14 seconds
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-backup-rocky.iso (131M)
Creating tar archive '/backup/rear/backup-rocky/backup.tar.gz'
Preparing archive operation
Archived 4317 MiB [avg 32035 KiB/sec] OK
Archived 4317 MiB in 138 seconds [avg 32035 KiB/sec]
Exiting rear mkbackup (PID 5102) and target is the normal/original system

The full backup compressed 4317 MiB of system data in 138 seconds. List the backup directory to see everything ReaR created:

ls -lh /backup/rear/backup-rocky/

The backup directory contains the ISO, the archive, and metadata files:

total 4.4G
-rw-------. 1 root root 4.3G Mar 28 14:47 backup.tar.gz
-rw-------. 1 root root  202 Mar 28 14:47 backup.log
-rw-------. 1 root root  131M Mar 28 14:45 rear-backup-rocky.iso
-rw-------. 1 root root  262 Mar 28 14:45 VERSION
-rw-------. 1 root root  4.2K Mar 28 14:45 README

Keep both the ISO and the backup.tar.gz together. The rescue ISO knows where to find the backup archive based on the BACKUP_URL in your configuration.

Verify the Disk Layout

ReaR saves your server’s complete disk layout to a file that it reads during recovery to recreate your partitions and filesystems exactly. Inspect it to make sure everything was captured correctly:

cat /var/lib/rear/layout/disklayout.conf

On the Rocky Linux 10 test system, the layout looks like this:

# Disk /dev/vda
# Format: disk   
disk /dev/vda 32212254720 gpt
# Partitions on /dev/vda
# Format: part      /dev/
part /dev/vda 2097152 1048576 rear-noname bios_grub /dev/vda1
part /dev/vda 209715200 3145728 rear-noname boot,legacy_boot,esp /dev/vda2
part /dev/vda 1048576000 212860928 rear-noname none /dev/vda3
part /dev/vda 30950866944 1261436928 rear-noname none /dev/vda4
# Filesystems (only ext2, ext3, ext4, vfat, xfs, reiserfs, btrfs are supported)
# Format: fs    [uuid=] [label=] 
fs /dev/vda2 /boot/efi vfat uuid=XXXX-XXXX label= options=rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii
fs /dev/vda3 /boot xfs uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx label= options=rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota
fs /dev/vda4 / xfs uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx label= options=rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota
# Swap partitions or swap files
# Format: swap  uuid= label=

Each line tells ReaR how to recreate a component of the disk. The disk line defines the drive size and partition table type (GPT). The part lines define each partition’s size, start offset, and flags. The fs lines specify the filesystem type and mount point. During recovery, ReaR reads this file and runs the corresponding parted, mkfs, and mount commands automatically.

On Ubuntu 24.04, the layout differs. The partitions are ordered differently, with vda1 as the root partition (29G), vda14 as a 4M BIOS boot partition, vda15 as the 106M EFI system partition, and vda16 as the 913M boot partition. ReaR captures whatever your system uses.

Schedule Automatic Backups

A one-time backup is better than nothing, but production servers change daily. Set up a systemd timer to run rear mkbackup automatically.

Create the service unit:

sudo vi /etc/systemd/system/rear-backup.service

Add the following service definition:

[Unit]
Description=ReaR bare metal backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/rear mkbackup
Nice=19
IOSchedulingClass=idle

The Nice=19 and IOSchedulingClass=idle settings ensure the backup runs at the lowest priority, so it won’t impact production workloads.

Now create the timer:

sudo vi /etc/systemd/system/rear-backup.timer

Configure it to run daily at 1:00 AM:

[Unit]
Description=Daily ReaR bare metal backup

[Timer]
OnCalendar=*-*-* 01:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

The Persistent=true setting ensures a missed backup (if the server was down at 1 AM) runs as soon as the server comes back up. RandomizedDelaySec=300 adds up to 5 minutes of random delay, which helps when multiple servers back up to the same NFS share.

Enable and start the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now rear-backup.timer

Verify the timer is active:

systemctl list-timers rear-backup.timer

The output shows when the next backup will run:

NEXT                        LEFT     LAST PASSED UNIT               ACTIVATES
Sun 2026-03-29 01:00:00 UTC 10h left n/a  n/a    rear-backup.timer  rear-backup.service

Check backup logs after the first automated run with journalctl -u rear-backup.service to confirm everything works unattended.

The Recovery Process

When disaster strikes, the recovery process follows a straightforward sequence. Here is what happens step by step when you boot from the ReaR rescue ISO.

1. Boot from the rescue ISO. Attach the ISO as a virtual CD/DVD (for VMs), burn it to a USB drive, or use the server’s IPMI/iLO/iDRAC virtual media. The rescue system boots your original kernel with all the hardware drivers from the backed-up server.

2. Log in as root. The rescue system drops you to a shell prompt. No password is required by default. If you configured SSH_ROOT_PASSWORD in local.conf, you can also SSH in from another machine.

3. Start the recovery. Run the recovery command:

rear recover

4. ReaR recreates the disk layout. It reads disklayout.conf and runs the partitioning commands: creating the partition table, formatting filesystems, creating swap space. If the new disk is a different size, ReaR can resize partitions automatically in many cases.

5. ReaR restores the backup. If using NFS or USB, ReaR mounts the backup storage and extracts backup.tar.gz to the newly created filesystems. For a 4.3 GB archive, this typically takes 2 to 3 minutes.

6. ReaR reinstalls the bootloader. GRUB2 is installed to the new disk’s MBR or EFI partition, configured with the correct root filesystem UUID.

7. Reboot. Remove the rescue media and reboot. The server comes up as if nothing happened, with all services, users, and data intact.

On Rocky Linux with SELinux enforcing, the first boot after recovery triggers an automatic SELinux relabel. This adds a few minutes to the boot time but is expected behavior. The system sets /.autorelabel during recovery, which tells SELinux to reapply all file contexts.

A note on testing recovery: In this guide, the backup storage was on a partition of the same test VM for demonstration purposes. In production, your backup storage should always be on a separate server (NFS) or USB drive, so the rescue ISO can access the backup archive after booting on new or replacement hardware. A proper DR test involves restoring to a second, separate machine.

Troubleshooting

Every error below was encountered during real testing on Rocky Linux 10.1 and Ubuntu 24.04. Most ReaR guides skip the error scenarios, which is exactly when you need guidance most.

Error: “Unknown bootloader (GRUB2-BLS)”

On Rocky Linux 10 (and RHEL 10), running rear mkrescue or rear mkbackup without the BOOTLOADER setting fails with:

ERROR: BUG in /usr/share/rear/layout/save/default/450_check_bootloader_files.sh line 44:
Unknown bootloader (GRUB2-BLS) - ask for sponsoring to get this fixed

RHEL 10 uses GRUB2 with the Boot Loader Specification (BLS) for managing boot entries, which ReaR 2.9 does not recognize as a valid bootloader type. The fix is simple. Add this line to /etc/rear/local.conf:

BOOTLOADER=GRUB2

This tells ReaR to treat the bootloader as standard GRUB2, which it functionally is. The BLS part only affects how boot menu entries are managed, not how GRUB2 itself is installed. Ubuntu 24.04 is not affected because it uses standard GRUB2 without BLS.

Error: “backup directory in the ‘/’ filesystem which is forbidden”

If your BACKUP_URL points to a directory that lives on the root filesystem:

ERROR: URL 'file:///backup/rear' has the backup directory '/backup/rear' in the '/' filesystem which is forbidden.

ReaR refuses to create a backup on the same filesystem it is backing up. The backup destination must be a separate mounted filesystem. Mount a dedicated partition, USB drive, or NFS share at /backup/rear before running ReaR. See the “Prepare Backup Storage” section above for the mount commands.

“No match for argument: genisoimage”

On Rocky Linux 10, attempting to install genisoimage fails because the package is not available in the default repositories:

No match for argument: genisoimage
Error: Unable to find a match: genisoimage

Install xorriso instead. It provides the same ISO creation capability and ReaR detects it automatically:

sudo dnf install -y xorriso

On Ubuntu 24.04, genisoimage is available and works fine. This is a Rocky/RHEL-specific issue.

“Failed to copy all contents of /lib/modules”

During mkrescue or mkbackup, you may see this warning on Rocky Linux 10:

Failed to copy all contents of /lib/modules/6.12.0-124.8.1.el10_1.x86_64 (dangling symlinks could be a reason)

This is a non-fatal warning, not an error. Some kernel module directories contain symlinks that point to build-time paths that no longer exist on the running system. ReaR copies all the actual module files successfully. The rescue system boots and functions correctly despite this warning.

A similar non-fatal warning may appear for systemd libraries:

usr/lib64/systemd/libsystemd-core-257-13.el10.rocky.0.1.so requires libraries where 'ldd' shows 'not found'

The library exists in a non-standard path that ldd cannot resolve, but the runtime linker finds it. ReaR includes the library in the rescue system and it works at recovery time. You can safely ignore both of these warnings.

For more backup approaches, see our guides on Bacula on Rocky Linux for enterprise-scale backup infrastructure, or BorgBackup with Borgmatic for deduplicated file-level backups. ReaR complements these tools by handling the bare metal layer that file-level backup tools cannot cover. Refer to the official ReaR documentation for advanced configurations including PXE boot recovery, encrypted backups, and multi-path SAN disk layouts.