#2782 Issue closed: Question: Adequate REAR Validation Measures ?

Labels: support / question, fixed / solved / done

paulra1 opened issue at 2022-03-31 01:39:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.6-git.0.0.master.changed / 2022-03-11

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): Ubuntu 20.04.3

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"): local.conf

# Linux rear, Relax-and-Recover, local.conf configuration file. This version
# is for an Ubuntu 20.4 OS and version 2.6-git.0.0 of rear.
# These settings are for creating an image an an external USB hard disk that
# includes both a boot partition and ext4 file system partition and can be
# used for bare metal recovery.
# Setting USB indicates the external USB hard disk is a USB device.
# Using NETFS indicates the USB disk is an external device.
# REAR-000 is the label of the ext4 partition on the USB disk.
# The maximum size of the EFI partition in megabytes.
# This indicates the data is stored with an ext4 file system.
# These make progress reporting easier to track.
  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): N/A

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): AMD64

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): SSD

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"): Approximate

/dev/loop0       /dev/loop0                         loop squashfs        938.5M /snap/android-studio/118
/dev/loop1       /dev/loop1                         loop squashfs         55.5M /snap/core18/2284
/dev/loop2       /dev/loop2                         loop squashfs            4K /snap/bare/5
/dev/loop3       /dev/loop3                         loop squashfs        938.5M /snap/android-studio/119
/dev/loop4       /dev/loop4                         loop squashfs         55.5M /snap/core18/2344
/dev/loop6       /dev/loop6                         loop squashfs         61.9M /snap/core20/1376
/dev/loop7       /dev/loop7                         loop squashfs        248.8M /snap/gnome-3-38-2004/99
/dev/loop8       /dev/loop8                         loop squashfs        247.9M /snap/gnome-3-38-2004/87
/dev/loop9       /dev/loop9                         loop squashfs         54.2M /snap/snap-store/558
/dev/loop10      /dev/loop10                        loop squashfs         43.6M /snap/snapd/15177
/dev/loop11      /dev/loop11                        loop squashfs         49.8M /snap/snap-store/467
/dev/loop12      /dev/loop12                        loop squashfs        164.8M /snap/gnome-3-28-1804/161
/dev/loop13      /dev/loop13                        loop squashfs         65.2M /snap/gtk-common-themes/1519
/dev/loop14      /dev/loop14                        loop squashfs         62.1M /snap/gtk-common-themes/1506
/dev/loop15      /dev/loop15                        loop squashfs          219M /snap/gnome-3-34-1804/77
/dev/loop16      /dev/loop16                        loop squashfs        391.3M /snap/gimp/383
/dev/loop17      /dev/loop17                        loop squashfs        255.6M /snap/gnome-3-34-1804/36
/dev/loop18      /dev/loop18                        loop squashfs         43.6M /snap/snapd/14978
/dev/loop19      /dev/loop19                        loop squashfs         61.9M /snap/core20/1405
/dev/nvme0n1     /dev/nvme0n1                nvme   disk                 931.5G 
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme   part vfat     EFI      512M /boot/efi
|-/dev/nvme0n1p2 /dev/nvme0n1p2 /dev/nvme0n1 nvme   part ext4     Ubuntu   927G /
`-/dev/nvme0n1p3 /dev/nvme0n1p3 /dev/nvme0n1 nvme   part swap                4G [SWAP]
  • Description of the issue (ideally so that others can reproduce it):
    Dear Staff:

I would like to prove that the bare-metal rear backup procedures I developed for the System76
machine, described below, are valid. However, I don't have a spare System76 machine. I think,
but don't know, if the procedures work on the Dell machine, described below, configured with
the same Linux OS version as the System76 machine, the same backup procedures will also
work for the System76 machine.

In your opinion, is performing rear validation on the Dell machine sufficient to prove the same
set of procedures used for the Dell machine will also work for the System76 machine?
(Assume they have machines have same release of the Ubuntu 20.04.3 LTS OS installed on them.)

The System76 machine is described by the following link.


It has an 11th Gen Intel® Core™ i7-11800H @ 2.30GHz × 16 processor, 16GB RAM, and a 1TB SSD.

The Dell Latitude machine is described by the following links.


It has a i5-2520M @ 2.5Ghz processor, 8GB RAM and a 128GB SSD.

Both of the above machines have AMD64 architecture and satisfy the Ubuntu requirements described by
the following link.


The sequence of validation procedures is as follows.

  • Install Linux Ubuntu 20.04.3 LTS on the machine.

  • Use "rear mkbackup" on an external USB disk to create a rescue disk with both boot and data sectors.

  • Erase the internal disk on the machine.

  • Use the rear image on thee external USB disk to restore the machine.

Best Regards,

Paul R.

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

gdha commented at 2022-03-31 08:23:

@paulra1 Hi - thanks for using ReaR, however, you cannot expect from us that we validate your hardware setup. The ultimate test has to be done by you. Don't be afraid to test it out as thousands of other end-users already did it before you.
If you encounter a bug with ReaR then submit an issue, but hope that won't be necessary.

paulra1 commented at 2022-03-31 14:21:

Hi gdah
I understand and don't expect validatation of my hardware setup and that is not the topiic of the case.
The case is in fact an opinion question. In particular, I would like to know if you and your colleagues
believe the strategy I described in adequate to verify that a rear backup will work. What prompted it
is that I am unable to perform a direct test because I don't have the right kind of spare machine.

Best Regards,
Paul R.

jsmeix commented at 2022-04-01 12:43:


I assume your System76 machine is the one that actually matters for you
and your Dell machine is intended only as some kind of "playground"
so you can use your Dell machine to try out things with ReaR
only on that machine, in particular you can risk that "rear recover"
may fail to recreate your Dell machine (so you would have to
reinstall your Dell machine manually from scratch and try again).

If my assumption is right, then yes, do that!

Try out how ReaR behaves on your Dell machine because
you need to use ReaR yourself, play around with it yourself,
do some trial an error experiments with it yourself,
to get used to ReaR which is a mandatory precondition
to be able to do a real disaster recovery, cf.
"First steps with Relax-and-Recover" in

Regarding your question if a successful recovery on your Dell machine
"proves" that then with same ReaR settings and same installed OS
there will be also a successful recovery on your System76 machine:

The only possible answer is of couse NO.
Here NO means that this is NO proof.

The reason is that things are different on different hardware.
A "same installed" OS is not same on different hardware.

See the section
"Fully compatible replacement hardware is needed" in
for some critical areas where differences matter a lot for ReaR.

Those areas are in particular firmware (BIOS type / UEFI)
and storage (disk types, disk sizes).

Different firmware can behave differently
in particular regarding booting from USB.
We had issues in ReaR with exactly that.
See what I wrote at
how you could at least test if the ReaR recovery system boots from USB.

reads (excerpts):

BIOS ... System76 Open Firmware
    1x M.2 (PCIe NVMe Gen 4)
    1x M.2 (PCIe NVMe Gen 3 or SATA)
    2.5" 7mm SATA drive bay

while in contrast
reads (excerpts):

Primary Storage Options
    7200 rpm SATA up to 500GB
    Encrypted 7200 rpm 320GB12
    Mobility Solid State up to 256G

but it tells nothing about BIOS type or UEFI but I assume
it has something different than "System76 Open Firmware".

You wrote that the one has a 1TB SSD and the other one a 128GB SSD
but the crucial point would be the storage type i.e. if it is SATA or NVMe.

ReaR is known to work with SATA and NVMe disks.

I only tell that there is no proof when ReaR works on one particular hardware
that then same ReaR settings will also work on different hardware
with a "same installed" OS.

In general regarding different hardware:

When you do not have fully compatible replacement hardware
then recreating the system becomes what we call a MIGRATION.

Migrating a system onto somewhat different hardware
will usually not work "out of the box" with ReaR, see
MIGRATION_MODE in default.conf currently online at

Regarding migration to a system with a bit smaller or a bit bigger disk
see in conf/default.conf the description of the config variables

I reccommend to not use AUTORESIZE_PARTITIONS="yes"
with layout/prepare/default/430_autoresize_all_partitions.sh
because that may result bad aligned partitions in particular
bad aligned for what flash memory based disks (i.e. SSDs) need
that usually need a 4MiB or 8MiB alignment (a too small value
will result lower speed and less lifetime of flash memory devices),
in default.conf

In general regarding system migration with ReaR
(e.g. to a system with substantially different disk size):

In general migrating a system onto different hardware
(where "hardware" could be also a virtual machine)
does not "just work", cf. "Inappropriate expectations" at

In sufficiently simple cases it may "just work" but in general
do not expect too much built-in intelligence from a program
(written in plain bash which is not a programming language
that is primarily meant for artificial intelligence ;-)
that would do the annoying legwork for you.

In general ReaR is first and foremost meant to recreate
a system as much as possible exactly as it was before
on as much as possible same replacement hardware.

paulra1 commented at 2022-04-01 16:20:

Hi Johannes:

Thank you for your lucid explanation. I don't believe my question could be addressed better,
and think the the case should be closed.

You are right that the Dell machine is just being used as a playground and your comments make
it clear that the rear configuration behavior on the Dell machine has only limited applicatility
to how the configuration will behave on another machine--for instance the System76 machine.

While both machines are UEFI machines, their BIOS are significantly different.
In addition, as you pointed out, the differences in low level SSD layout merits
careful consideration.

Best Regards,

Paul R.

jsmeix commented at 2022-04-04 11:09:

thank you for your feedback!

Only as a side note FYI:
To avoid confusion I recommend to use the word BIOS
only if you mean the legacy firmware in PC architecture
and also when you use the firmware in legacy BIOS mode
but the word EFI or UEFI if you mean nowadays firmware
that you use in its native way (i.e. as [U]EFI bootloader)
and the word firmware as generic name for such kind of software
that is provided built-in by the manufactuer of the raw hardware.

[Export of Github issue for rear/rear.]