Bare metal recovery means rebuilding a server from nothing: partitions, filesystems, LVM, bootloader and data, onto an empty disk. File-level backups alone do not give you that, because you still have to reinstall the OS and recreate the disk layout by hand before you can restore anything. In this tutorial you will use Relax-and-Recover (ReaR), the standard open source bare metal recovery tool for Linux, to create a bootable rescue ISO plus a full system backup on an NFS share, and then use them to restore an Ubuntu 24.04 server.

Prerequisites

To follow this guide you need:

  • The server you want to protect, running Ubuntu 24.04 LTS (for example a CubePath VPS or dedicated server), with a non-root user with sudo privileges. This guide calls it the source server.
  • A second machine to store backups, also Ubuntu 24.04, with enough free disk space for a compressed copy of the source server's data. This guide calls it the backup server.
  • Private or public network connectivity between both machines on TCP port 2049 (NFSv4).
  • For the restore: a way to boot the target machine from an ISO image, such as IPMI/BMC virtual media on a dedicated server or an ISO mount option on a virtual machine, and a target disk at least as large as the original.

Replace backup_server_ip and source_server_ip in the commands with your real addresses.

How ReaR works

ReaR does two things in one run of rear mkbackup:

  1. It records the disk layout of the running system (partition tables, RAID, LVM, filesystems, mount points) and builds a small rescue system from the server's own kernel and tools. That rescue system is written to a bootable ISO.
  2. It archives the filesystems with tar into backup.tar.gz.

With BACKUP=NETFS both files go to the same network share. During recovery you boot the ISO, run rear recover, and ReaR recreates the disk layout, restores the archive and reinstalls GRUB.

Step 1 - Preparing the NFS share on the backup server

ReaR runs as root and writes files owned by root, so the export needs no_root_squash. Restrict it to the source server's IP address only.

On the backup server, install the NFS server and create the directory:

sudo apt update
sudo apt install nfs-kernel-server
sudo mkdir -p /srv/rear

Open the exports file:

sudo nano /etc/exports

Add this line, replacing source_server_ip:

/srv/rear source_server_ip(rw,sync,no_subtree_check,no_root_squash)

Reload the exports and allow NFS from the source server through UFW:

sudo exportfs -ra
sudo ufw allow from source_server_ip to any port 2049 proto tcp

Check that the share is exported:

sudo exportfs -v

/srv/rear     source_server_ip(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)

Step 2 - Installing ReaR on the source server

On the source server, install ReaR, an ISO builder and the NFS client:

sudo apt update
sudo apt install rear xorriso nfs-common

Confirm the version:

rear --version

Relax-and-Recover 2.7 / 2022-07-13

Before configuring anything, check that the source server can mount the share:

sudo mount -t nfs backup_server_ip:/srv/rear /mnt
sudo touch /mnt/test && sudo rm /mnt/test
sudo umount /mnt

If touch fails with Permission denied, the export is missing no_root_squash or lists the wrong IP.

Step 3 - Configuring ReaR

ReaR reads its settings from /etc/rear/local.conf. Open it:

sudo nano /etc/rear/local.conf

Replace the contents with:

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=nfs://backup_server_ip/srv/rear
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/mnt/*' '/var/tmp/*' '/var/cache/apt/archives/*.deb')
NETFS_KEEP_OLD_BACKUP_COPY=yes

What each line does:

  • OUTPUT=ISO builds a bootable ISO rescue image.
  • BACKUP=NETFS uses ReaR's built-in tar backup to a network share.
  • BACKUP_URL is the NFS share from Step 1. The ISO is stored there too, in a subdirectory named after the host.
  • BACKUP_PROG_EXCLUDE appends paths you do not need to restore to ReaR's default exclusions.
  • NETFS_KEEP_OLD_BACKUP_COPY=yes keeps the previous backup until the new one finishes, so a failed run never leaves you with nothing.

If the server stores large data you back up by other means (for example a database with its own dumps), add those paths to the exclusion list as well.

Check that ReaR parses the file and detects the disk layout without errors:

sudo rear -v savelayout

Relax-and-Recover 2.7 / 2022-07-13
Running rear savelayout (PID 12345 date 2026-09-25 10:12:03)
Using log file: /var/log/rear/rear-web01.log
Creating disk layout
Using guessed bootloader 'GRUB' (found in first bytes on /dev/sda)
Exiting rear savelayout (PID 12345) and its descendant processes ...

The saved layout is in /var/lib/rear/layout/disklayout.conf. Review it once to make sure every disk and filesystem you care about is listed:

sudo grep -E '^(disk|part|lvmvol|fs) ' /var/lib/rear/layout/disklayout.conf

Step 4 - Creating the rescue ISO and the backup

Run a full backup. It builds the ISO and then archives the system, so the first run can take a while depending on the amount of data:

sudo rear -v mkbackup

Relax-and-Recover 2.7 / 2022-07-13
Running rear mkbackup (PID 23456 date 2026-09-25 10:15:41)
Using log file: /var/log/rear/rear-web01.log
Running workflow mkbackup on the normal/original system
Using backup archive '/var/tmp/rear.XXXX/outputfs/web01/backup.tar.gz'
Using autodetected kernel '/boot/vmlinuz-6.8.0-84-generic' as kernel in the recovery system
Creating disk layout
...
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-web01.iso (412M)
Copying resulting files to nfs location
...
Creating tar archive '/var/tmp/rear.XXXX/outputfs/web01/backup.tar.gz'
Archived 3812 MiB in 241 seconds [avg 16198 KiB/sec]
Exiting rear mkbackup (PID 23456) and its descendant processes ...

On the backup server, verify that the files arrived:

ls -lh /srv/rear/*/

-rw------- 1 root root 2.1K Sep 25 10:16 README
-rw------- 1 root root  267 Sep 25 10:16 VERSION
-rw------- 1 root root 1.3G Sep 25 10:20 backup.tar.gz
-rw------- 1 root root 3.4M Sep 25 10:20 backup.log
-rw------- 1 root root 412M Sep 25 10:16 rear-web01.iso
-rw------- 1 root root 1.1M Sep 25 10:16 rear-web01.log

Also confirm the archive is readable, which catches truncated or corrupt uploads:

sudo tar -tzf /srv/rear/web01/backup.tar.gz > /dev/null && echo "archive OK"

Replace web01 with your source server's hostname.

Step 5 - Scheduling backups with a systemd timer

A recovery ISO is only as good as its last backup. Schedule rear mkbackup weekly with a systemd timer. Create the service unit on the source server:

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

[Unit]
Description=Relax-and-Recover full backup
Wants=network-online.target
After=network-online.target

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

Create the timer:

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

[Unit]
Description=Weekly Relax-and-Recover backup

[Timer]
OnCalendar=Sun *-*-* 03:00:00
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

Enable it and check the next run:

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

NEXT                        LEFT    LAST PASSED UNIT              ACTIVATES
Sun 2026-09-27 03:12:44 UTC 1 day 16h -    -      rear-backup.timer rear-backup.service

After a scheduled run, check the result with:

journalctl -u rear-backup.service -n 20

Whenever you change disks, partitions or LVM volumes, run sudo rear -v mkbackup manually right away so the ISO matches the new layout. sudo rear checklayout returns a non-zero exit code when the current layout differs from the one saved in the last run.

Step 6 - Restoring the server from bare metal

Use this procedure when the original disk is lost, or to move the system to a replacement machine.

  1. Copy rear-web01.iso from the backup server to wherever your boot method needs it (IPMI virtual media, the ISO mount of your virtualization platform, or a USB stick written with dd).
  2. Boot the target machine from the ISO. In the boot menu, select Recover web01.
  3. Log in as root. The rescue system does not ask for a password on the local console.
  4. Make sure the network is up and the backup server is reachable. ReaR reuses the original network configuration, so on the same subnet it usually works without changes:
ip -br addr
ping -c 3 backup_server_ip
  1. Start the recovery:
rear -v recover

ReaR compares the saved layout with the disks it finds. If the target disk has a different name or size, it asks you to map the old disk to the new one and lets you confirm or edit the generated disk layout script before writing anything. It then partitions and formats the disks, restores backup.tar.gz and installs GRUB.

Relax-and-Recover 2.7 / 2022-07-13
Running rear recover (PID 812 date 2026-09-25 14:02:10)
Using log file: /var/log/rear/rear-web01.log
Running workflow recover within the ReaR rescue/recovery system
Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available.
Started RPC portmapper 'rpcbind'.
RPC portmapper 'rpcbind' available.
Using backup archive '/tmp/rear.XXXX/outputfs/web01/backup.tar.gz'
Comparing disks
Disk configuration looks identical
Proceed with recovery (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)
yes
...
Restoring from '/tmp/rear.XXXX/outputfs/web01/backup.tar.gz' ...
Restored 3812 MiB in 198 seconds [avg 19715 KiB/sec]
...
Installing GRUB2 boot loader...
Finished 'recover'. The target system is mounted at '/mnt/local'.
Exiting rear recover (PID 812) and its descendant processes ...
  1. Before rebooting, check the restored system if you need to adjust anything, such as /mnt/local/etc/netplan/ when the replacement machine has a different network interface name.
  2. Detach the ISO and reboot:
reboot

After the server boots, verify that the services came back and the filesystems are mounted as expected:

findmnt -t ext4,xfs,vfat
systemctl --failed

Anything written after the last mkbackup is not in the archive. Restore those changes from your application-level backups (database dumps, object storage) afterwards.

Step 7 - Testing the recovery regularly

A backup you have never restored is a hope, not a plan. At least once per quarter, and after major changes:

  • Create a virtual machine or spare server with a disk at least as large as the source.
  • Boot it from the latest ISO and run rear -v recover, keeping it on an isolated network so the restored copy does not clash with production (same IP, same cron jobs).
  • Confirm it boots, that your application starts and that recent data is present.
  • Write down how long it took. That number is your real recovery time.

Troubleshooting

ERROR: Cannot autodetect what to use as ISO_MKISOFS_BIN: no ISO builder is installed. Install xorriso and rerun rear mkbackup.

mount.nfs: access denied by server: the export in /etc/exports does not match the client IP ReaR is using, or exportfs -ra was not run after editing. Check sudo exportfs -v on the backup server.

The restored system drops to a GRUB prompt or does not boot on UEFI: the target machine is booting in a different firmware mode (BIOS versus UEFI) than the original. Switch the firmware mode to match the source server and run the recovery again.

No code has been generated to recreate /dev/...: that device type is not supported by ReaR's layout code or was excluded. Review /var/lib/rear/layout/disklayout.conf and the log in /var/log/rear/ to see which device was skipped.

Conclusion

You now have a bootable ReaR rescue ISO and a full system archive on a separate backup server, refreshed every week by a systemd timer, and a tested procedure to rebuild the server on an empty disk. Next steps worth taking: copy /srv/rear off-site so a single site failure does not take both copies, add application-level backups (database dumps) for data that changes between runs, and schedule a recovery drill in your calendar.