#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.
#
OUTPUT=USB
#
# Using NETFS indicates the USB disk is an external device.
#
BACKUP=NETFS
#
# REAR-000 is the label of the ext4 partition on the USB disk.
#
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
#
# The maximum size of the EFI partition in megabytes.
#
USB_UEFI_PART_SIZE=1024
# This indicates the data is stored with an ext4 file system.
#
USB_DEVICE_FILESYSTEM=ext4
#
# These make progress reporting easier to track.
#
PROGRESS_MODE=plain
PROGRESS_WAIT_SECONDS=3
-
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
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/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.
https://tech-docs.system76.com/models/gaze16/README.html
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.
https://i.dell.com/sites/content/shared-content/data-sheets/en/documents/latitude-e6420-spec-sheet.pdf
https://ark.intel.com/content/www/us/en/ark/products/52229/intel-core-i52520m-processor-3m-cache-up-to-3-20-ghz.html
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.
https://linuxconfig.org/ubuntu-20-04-system-requirements
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:¶
@paulra1
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
https://en.opensuse.org/SDB:Disaster_Recovery
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
https://en.opensuse.org/SDB:Disaster_Recovery
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
https://github.com/rear/rear/issues/2770#issuecomment-1070968457
how you could at least test if the ReaR recovery system boots from USB.
https://tech-docs.system76.com/models/gaze16/README.html
reads (excerpts):
BIOS ... System76 Open Firmware
...
Storage
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
https://i.dell.com/sites/content/shared-content/data-sheets/en/documents/latitude-e6420-spec-sheet.pdf
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
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L375
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
AUTORESIZE_PARTITIONS
AUTORESIZE_EXCLUDE_PARTITIONS
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE
AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
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),
see the comment at USB_PARTITION_ALIGN_BLOCK_SIZE
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
https://en.opensuse.org/SDB:Disaster_Recovery
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:¶
@paulra1
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.]