Bare-metal recovery for Linux: LVM snapshots, filesystem freeze and Relax-and-Recover

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Linux bare-metal recovery is two separate jobs. One is getting a consistent copy of the files from a running server, which LVM snapshots can do. The other is rebuilding partitions, LVM, filesystems and the boot loader on empty disks, which Relax-and-Recover (ReaR) does.

ReaR does not solve the first job for you. The documentation we opened never describes taking an LVM snapshot before a backup, and we found no snapshot or freeze option in its default configuration (our reading, checked 10 November 2026). Its built-in backup archives files as they are. Plan the two jobs separately, then prove they work together with a real restore.

The commands below were not run in a lab. They come from project documentation and man pages, and names such as vg0, SRV01 and backup01 are examples. They are reference material, not a ready-to-run procedure, until a qualified engineer has checked them on a copy of the server.

Recommendations and interpretations are editorial unless attributed; source research is not lab validation.

Why it matters

A restored archive is not a working server. Without the original partition table, volume groups and boot loader there is nothing to restore into and nothing to start it.

ReaR's manual states the gap directly: most backup software is very good at restoring data but does not support recreating the system layout. ReaR creates a bootable recovery image for physical or virtual replacement hardware, recreates the storage, calls a restore program, and installs a boot loader.

The other half matters just as much. Files copied while applications write can be mutually inconsistent, and the restore will not tell you.

This article covers what happens inside the guest. We have published separately on quiesced VMware snapshots of Linux guests and on full LVM thin pools, and do not repeat those diagnostics.

How it works

What a freeze does

fsfreeze halts new access and creates a stable image on disk. Ongoing transactions complete, new writes are halted, and dirty data, metadata and log information are written out. Any process writing to the frozen filesystem blocks until it is unfrozen.

You usually do not need to run it with LVM. The man page says fsfreeze is unnecessary for device-mapper devices, because device-mapper and LVM automatically freeze a filesystem when a snapshot is requested. The page names hardware RAID snapshots as the tool's intended use.

Warning: running a manual freeze by hand on a filesystem your shell, logging or the freeze script itself writes to can block those processes. If you must freeze, design and test an independent thaw path; a shell trap cannot guarantee recovery after an uncatchable kill, power loss or a blocked process. Plan that failure path, and never freeze / interactively.

A freeze gives filesystem consistency, and nothing more. Applications may still hold data in memory that the freeze never sees. PostgreSQL's documentation shows what a careful vendor requires: a frozen snapshot works on a running server, and the copy looks as if the database was not shut down properly, so startup replays the write-ahead log, and the same page says to include the WAL files in your backup. Check your own database's documentation for the equivalent statement.

Two kinds of LVM snapshot

COW (copy-on-write) snapshots are created when a size is specified, and that size is allocated from the volume group. It is the room for saving old blocks as writes occur. The man page says the size should depend on expected writes, and often 20% of the origin is enough. A small part of that space is used to track block locations, so not all of it holds data.

The failure is severe, and the remedy is to act early: a COW snapshot running low can be extended with lvextend. A snapshot that runs out of space becomes invalid, and is unmounted if possible. A backup reading it at that moment fails or stops. The monitoring daemon warns in syslog at 80%, then again at 85%, 90% and 95%.

Thin snapshots behave differently. They share blocks in the thin pool and do not allocate new space from the volume group. Passing a size creates a COW snapshot instead, so leave it out. A thin snapshot also gets the skip-activation property, so it needs lvchange -ay -K before use. Their limit is the pool itself: a thin pool that runs out of space may be damaged, and difficult or impossible to repair. Our separate thin pool article covers that case.

What Relax-and-Recover records and does

rear mkrescue builds the rescue media, and rear mkbackup also backs up the system, but only for the internal backup methods. Recovery goes through verify, recreate, restore and finalize stages. The verify stage aborts before touching disks if ReaR does not believe recovery can succeed, and the new system is mounted under /mnt/local for the restore.

The storage description lives in /var/lib/rear/layout/disklayout.conf, a plain file that is both human and machine readable. ReaR's layout handling covers LVM among other storage types.

On the same hardware, ReaR detects the same system and makes sure things like UUIDs match. If the disks were encrypted, it asks for the LUKS password.

What to choose and why

ReaR's manual is plain about its built-in method. NETFS is for demonstration and special purposes, and for permanent setups the project recommends something more professional. The built-in methods also create backups, while third-party integrations only restore, so for those products you must create the backups yourself, unless otherwise noted.

Sample command output in its user guide advises going into single-user mode before a built-in backup, so active data is consistent on disk. The same guide has sample output dated 2011, so check whether your version still prints this. Even so, it is the honest cost of archiving a live filesystem without a snapshot.

A smaller interruption is available through ReaR's hooks. Its configuration file gives the use directly: stop a database with PRE_BACKUP_SCRIPT and restart it with POST_BACKUP_SCRIPT. If a pre script is set, ReaR also runs the post script on an error exit during the backup, which covers handled error exits but does not guarantee restart after every process or host failure. Taking a snapshot inside such a hook would be your own design, and ReaR does not document it.

For a third-party product, the normal pairing is that the product backs up and ReaR rebuilds. Run rear mkrescue rather than mkbackup in that case; the manual notes mkbackup has usually no function with third-party methods.

Design the archive and recovery as one system

Establish a consistent capture boundary

A snapshot archive design must name every filesystem, its role and the applications writing to it. One root snapshot does not capture separate /var, /home, /boot or EFI filesystems. A per-filesystem archive option deliberately stops at mount boundaries, so inventory omissions become restore omissions.

Choose COW capacity from measured changed-block growth over the entire archive duration, including safety margin and failure handling. An arbitrary 20 GB example is not a sizing method. Record the origin and snapshot identifiers separately and verify their relationship before creation or cleanup. Removing an origin can also remove its dependent snapshots, so cleanup must be part of the reviewed implementation rather than a guessed volume name.

A snapshot's validity must be monitored during the copy, with automated abort and reporting if capacity is exhausted. An archive that completed after the snapshot became invalid cannot be accepted as a reliable capture. The read-only lvs output helps document the layout and usage:

lvs -a -o lv_name,vg_name,origin,lv_attr,lv_size,data_percent,metadata_percent

Mount semantics need their own validation. XFS snapshots can have duplicate UUIDs, and ext4 read-only mounts can replay the journal. Preventing replay can leave an unclean filesystem inconsistent; allowing it can consume snapshot space. Select the filesystem-specific method with the storage engineer and test what it writes. This article does not supply an unvalidated mount-and-archive sequence.

Separate boot partitions need the same consistency boundary as the captured operating system. Copying /boot or EFI files live while packages or kernels are changing can pair the root image with different modules, initramfs or boot files. Freeze package changes for the capture or use another validated common-point method, and record the kernel and boot-artifact identities together.

Coordinate several volumes

The opened LVM documentation describes a snapshot of one origin at a time; it does not establish an atomic multi-volume capture for this design. PostgreSQL explicitly warns about data and WAL on different filesystems. Its alternatives include a brief controlled shutdown or continuous-archiving backup. Use the database-supported method, and treat the operating-system archive as a separate protection component.

The archive specification must also preserve the required metadata. Ownership, ACLs, extended attributes, SELinux context and file capabilities are different properties. GNU tar stores extended-attribute names when requested but normally extracts only the user namespace; other namespaces require an explicit decision. Validate binary compatibility and restore behaviour on the intended operating system rather than assuming a copied filename has retained its privileges.

Keep rescue media aligned with the backup

ReaR's manual-restore integration pauses for a separate restore procedure after layout creation. Record the chosen integration, media identifier, storage-layout description and compatible backup set as one recovery bundle. A rescue ISO built before a layout change may not describe a newer archive correctly.

rear checklayout can report a changed layout, but a nonzero exit can also be a command failure. Automation must retain the exit status and diagnostic output, distinguish the cause, alert on failures and verify any rebuilt media. A shell expression that rebuilds on every error does not establish that the resulting recovery bundle is valid.

The default broad kernel-module selection is relevant to replacement hardware. A smaller image containing only currently loaded modules can omit the replacement controller. Test booting the media on the actual hardware class, with the required network clients and storage drivers available before the incident.

Review destination mapping before recovery

ReaR recovery can repartition disks and overwrite data. Its documentation warns that similarly sized disks can be confused when device names change. Migration mode can request mapping, but the operator must still verify serials or other stable identities, sizes and the role of each destination. Keep the backup medium and unrelated storage outside the approved overwrite set.

A manual restore needs a separate mapping from each archive to its target mount point. Root, /var, /boot and EFI archives are not interchangeable. Extracting the contents of a /var archive at the new root can scatter its files into the wrong directories. FAT EFI storage also has different ownership semantics from Linux filesystems. Have the map reviewed and reproduce it in the rehearsal before automating extraction.

The reviewed plan should include the expected state before and after ReaR's layout, restore and finalisation stages. Confirm that the intended target filesystems are actually mounted where the restore expects them, that adequate capacity remains, and that the boot loader is installed for the unchanged firmware mode. A successful archive extraction is not permission to skip those checks.

Accept the recovered server

Before release, verify kernel and module alignment, initramfs and EFI contents where applicable, mount configuration, encryption access and the complete filesystem inventory. Then boot more than once, verify networking and run controlled application transactions. Time any SELinux relabelling and other first-boot work because it belongs in the recovery window.

Retain the logs and exact manual decisions needed by the rehearsal. Confirm a new backup and restore path on the replacement. If the recovered machine accepted writes during validation, record their disposition before returning to an older source. The evidence should establish a repeatable recovery of this server, not just a bootable rescue image.

Different disks or hardware

ReaR's guide is candid: it supports different hardware but cannot always adapt automatically, and may need manual changes. Named examples are editing disklayout.conf for the disks present, reducing partition or logical volume sizes for smaller storage, and configuring network interfaces by hand.

Sizing has limits. By default, automatic shrinking stops at 2%: a new disk smaller than that errors out, and you must edit disklayout.conf before running rear recover. The menu during recovery lets you edit the layout and the generated diskrestore.sh script. Some sample output in the guide is dated 2011, so follow the method and check today's prompts.

For networking in the rescue system, set ip=, nm=, netdev= and gw= on the kernel command line, or prepare /etc/rear/mappings/ip_addresses and routes before building the media.

A hardware difference can also defeat the recovery environment itself, because ReaR depends on the software of the running system, and that may not support newer hardware. Keep the protected system's kernel reasonably current, and test on the hardware class you would really buy.

Risks and limits

• Check support first. ReaR 2.9 lists RHEL 7, 8 and 9, SLES 15, Debian 10 and 11, Ubuntu 20.04, 22.04 and 24.04 and others. RHEL 10 and Debian 12 are not in that list. The notes say newer versions usually work but can fail arbitrarily when tools change.
• Btrfs and Oracle ASM. Btrfs support is limited to single-device configurations, and Oracle ASM is not supported.
• UEFI and Secure Boot. ReaR detects UEFI by default, and has a setting for the Secure Boot loader. We did not find a statement covering every firmware migration, so keep the boot mode unchanged and test.
• Re-validation. The release notes say that after each ReaR upgrade or change to your base system you must re-validate your recovery procedure.
• Snapshots are not backups. A snapshot sits in the same volume group as its origin, so disk loss takes both. lvconvert --mergesnapshot rolls an origin back, and on a root volume it is deferred until the next activation. It discards every write made since the snapshot.
• SELinux after restore. ReaR's source sets BACKUP_SELINUX_DISABLE=1 by default, and a script in its default restore directory then creates .autorelabel on the target. We read this as applying to REQUESTRESTORE too, but did not run it. If so, the first boot relabels every file, which can take a long time on a large server, and restored SELinux contexts matter less than the tar options suggest. Time this in your test.
• Documentation age. Several ReaR examples are old, and we read default.conf from the development branch. On a real system, read /usr/share/rear/conf/default.conf for your installed version.

Finally, do the whole restore. Boot the media on spare hardware or an isolated virtual machine, restore and boot it, and record any manual step you had to take.

Sources

Opened 10 November 2026.

• rear(8) manual
• ReaR user guide: getting started
• ReaR user guide: scenarios
• ReaR user guide: layout configuration
• ReaR user guide: design concepts
• ReaR default.conf
• ReaR restore script: SELinux autorelabel
• ReaR restore script: REQUESTRESTORE prompt
• ReaR 2.9 release notes
• ReaR frequently asked questions
• lvcreate(8)
• lvmthin(7)
• lvremove(8)
• lvconvert(8)
• dmeventd(8)
• fsfreeze(8)
• mount(8)
• xfs(5)
• ext4(5)
• GNU tar: extended file attributes (GNU tar 1.35.90 manual)
• capabilities(7)
• PostgreSQL: file system level backup

This article was originally published on 10 November 2026.