#2389 Issue `closed`: Restore fails with LVM on LUKS encrypted volume¶

Labels: documentation, support / question, fixed / solved / done

vigri opened issue at 2020-05-07 06:55:¶

ReaR version ("/usr/sbin/rear -V"):

Relax-and-Recover 2.4 / Git

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

OS_VENDOR=Debian
OS_VERSION=10

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

BACKUP=DUPLICITY
PROGS=( "${PROGS[@]} "lftp" "unzip" )
MODULES_LOAD=( "${MODULES_LOAD[@]}" "fuse" )


COPY_AS_IS_EXCLUDE=( "${COPY_AS_IS_EXCLUDE[@]}" "/root/.duply" )
OUTPUT=ISO
OUTPUT_URL=.....................

TIMESYNC=NTPDATE
TIMESYNC_SOURCE=0.pool.ntp.org

ISO_PREFIX="${HOSTNAME}-$(date '+%Y-%m-%d-%H%M%S')"

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):

virtual machine

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

x86 compatible

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

BIOS / GRUB

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

local (virtual) disk

Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

NAME                           KNAME      PKNAME    TRAN TYPE  FSTYPE       SIZE MOUNTPOINT
/dev/loop0                     /dev/loop0                loop  squashfs    93.9M /snap/core/9066
/dev/loop1                     /dev/loop1                loop  squashfs      55M /snap/core18/1754
/dev/loop2                     /dev/loop2                loop  squashfs    69.1M /snap/lxd/14943
/dev/loop3                     /dev/loop3                loop  squashfs    69.2M /snap/lxd/14962
/dev/loop4                     /dev/loop4                loop  squashfs      55M /snap/core18/1705
/dev/loop5                     /dev/loop5                loop  squashfs    93.8M /snap/core/8935
/dev/sda                       /dev/sda                  disk                60G
|-/dev/sda1                    /dev/sda1  /dev/sda       part  ext4         285M /boot
`-/dev/sda2                    /dev/sda2  /dev/sda       part  crypto_LUKS 59.7G
  `-/dev/mapper/sda2_crypt     /dev/dm-0  /dev/sda2      crypt LVM2_member 59.7G
    |-/dev/mapper/vg01-lv_root /dev/dm-1  /dev/dm-0      lvm   ext4         9.3G /
    |-/dev/mapper/vg01-lv_home /dev/dm-2  /dev/dm-0      lvm   ext4         4.7G /home
    |-/dev/mapper/vg01-lv_tmp  /dev/dm-3  /dev/dm-0      lvm   ext4         2.8G /tmp
    |-/dev/mapper/vg01-lv_swap /dev/dm-4  /dev/dm-0      lvm   swap         3.7G [SWAP]
    |-/dev/mapper/vg01-lv_var  /dev/dm-5  /dev/dm-0      lvm   ext4          14G /var
    |-/dev/mapper/vg01-lv_log  /dev/dm-6  /dev/dm-0      lvm   ext4           7G /var/log
    `-/dev/mapper/vg01-lv_www  /dev/dm-7  /dev/dm-0      lvm   ext4         4.7G /var/www

Description of the issue (ideally so that others can reproduce it):
The image has been created with sudo mkrescue. On a second (clean) virtual machine I tried to execute rear recover
Workaround, if any:

none

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
Logfile which was created during the restore: https://gist.github.com/vigri/c5248d1a14ea701118c127bddf0b4bdb#file-rear-log-L26

Hello,
I've successfully restored a test-server some days ago. The disk layout was quite simple: no lvm, no encryption etc.
Now I'm trying to restore a second test-server which has multiple mountpoints, lvm and disk encryption. The restore fails.

I'm not sure what's causing the error.
But when looking at line 340 I see WARNING: Locking directory /run/cryptsetup is missing.
Line 374 says Volume group "vg01" not found.
Line 378 should be a consequential error or line 374.

But is line 340 really the root cause?

Another observation I made: After entering the passphrase for /dev/sda2 noting happens for a couple of minutes. Checking the available entropy results in 600 which is obviously not much...

Edit:
Full rear -D recover log:
https://gist.github.com/vigri/95e0ad340172fbb47b8af21a023a8e8e

/var/lib/rear/layout/disktodo.conf

disklayout.conf

# Disk /dev/sda
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sda 64424509440 msdos
# Partitions on /dev/sda
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
part /dev/sda 298844160 1048576 primary boot /dev/sda1
part /dev/sda 64123568128 299892736 primary none /dev/sda2
# Format for LVM PVs
# lvmdev <volume_group> <device> [<uuid>] [<size(bytes)>]
lvmdev /dev/vg01 /dev/mapper/sda2_crypt v0wMqg-tkjw-0bU2-ZEcP-s0hG-Cqo7-YPetCc 125237248
# Format for LVM VGs
# lvmgrp <volume_group> <extentsize> [<size(extents)>] [<size(bytes)>]
lvmgrp /dev/vg01 4096 15287 62615552
# Format for LVM LVs
# lvmvol <volume_group> <name> <size(bytes)> <layout> [key:value ...]
lvmvol /dev/vg01 lv_home 4999610368b linear 
lvmvol /dev/vg01 lv_log 7499415552b linear 
lvmvol /dev/vg01 lv_root 9999220736b linear 
lvmvol /dev/vg01 lv_swap 3997171712b linear 
lvmvol /dev/vg01 lv_tmp 2998927360b linear 
lvmvol /dev/vg01 lv_var 14998831104b linear 
lvmvol /dev/vg01 lv_www 4999610368b linear 
# Filesystems (only ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs are supported).
# Format: fs <device> <mountpoint> <fstype> [uuid=<uuid>] [label=<label>] [<attributes>]
fs /dev/mapper/vg01-lv_home /home ext4 uuid=dd4343d0-561a-4816-aabc-02e95db69b44 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16380 default_mount_options=user_xattr,acl options=rw,nosuid,nodev,relatime
fs /dev/mapper/vg01-lv_log /var/log ext4 uuid=d7805a44-9965-45a6-899f-0be13c9c1a0b label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16379 default_mount_options=user_xattr,acl options=rw,nosuid,nodev,noexec,relatime
fs /dev/mapper/vg01-lv_root / ext4 uuid=ee84fcac-6a9b-440b-82e0-537e24254e76 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16370 default_mount_options=user_xattr,acl options=rw,relatime,errors=remount-ro
fs /dev/mapper/vg01-lv_tmp /tmp ext4 uuid=a6ff2f0d-5d2f-453e-9c86-bde99af92d5c label= blocksize=4096 reserved_blocks=5% max_mounts=-1 check_interval=0d bytes_per_inode=16363 default_mount_options=user_xattr,acl options=rw,nosuid,nodev,relatime
fs /dev/mapper/vg01-lv_var /var ext4 uuid=b4d5579d-dc2a-4d26-adef-4cfb1cc81945 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16379 default_mount_options=user_xattr,acl options=rw,nodev,relatime
fs /dev/mapper/vg01-lv_www /var/www ext4 uuid=0f8631e1-37c2-4637-9f9a-48f9636c4bcd label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16380 default_mount_options=user_xattr,acl options=rw,nosuid,nodev,noexec,relatime
fs /dev/sda1 /boot ext4 uuid=e5fefbc4-bec5-4707-b6a7-b25dc16e3b1d label=lv_boot blocksize=1024 reserved_blocks=5% max_mounts=-1 check_interval=0d bytes_per_inode=4085 default_mount_options=user_xattr,acl options=ro,nosuid,nodev,noexec,relatime
# Swap partitions or swap files
# Format: swap <filename> uuid=<uuid> label=<label>
swap /dev/mapper/vg01-lv_swap uuid=287661ac-b09b-46ab-8619-a24eff766db8 label=
crypt /dev/mapper/sda2_crypt /dev/sda2 cipher=aes-xts-plain64 key_size=512 hash=sha256 uuid=6121978d-3287-4720-8d66-a134075773a0

diskrestore.sh

#!/bin/bash

LogPrint "Start system layout restoration."

mkdir -p /mnt/local
if create_component "vgchange" "rear" ; then
    lvm vgchange -a n >/dev/null
    component_created "vgchange" "rear"
fi

set -e
set -x

if create_component "/dev/sda" "disk" ; then
# Create /dev/sda (disk)
Log "Stop mdadm"
if grep -q md /proc/mdstat &>/dev/null; then
    mdadm --stop -s >&2 || echo "stop mdadm failed"
    # Prevent udev waking up mdadm later.
    # Reasoning: At least on RHEL6 when parted created a raid partition on disk,
    # udev (via /lib/udev/rules.d/65-md-incremental.rules) wakes up mdadm which locks the disk,
    # so further parted commands with the disk will fail since the disk is busy now.
    # The /lib/udev/rules.d/65-md-incremental.rules detects anaconda (the Red Hat installer),
    # and if it find itself running under anaconda, it will not run.
    # Accordingly also for other installers (in particular the ReaR installer)
    # this rule should not be there (and other Linux distros probably do not have it)
    # which means removing it is the right solution to make ReaR work also for RHEL6:
    if [ -e /lib/udev/rules.d/65-md-incremental.rules ] ; then
        rm -f /lib/udev/rules.d/65-md-incremental.rules || echo "rm 65-md-incremental.rules failed"
    fi
fi
Log "Erasing MBR of disk /dev/sda"
dd if=/dev/zero of=/dev/sda bs=512 count=1
sync
LogPrint "Creating partitions for disk /dev/sda (msdos)"
my_udevsettle
parted -s /dev/sda mklabel msdos >&2
my_udevsettle
my_udevsettle
parted -s /dev/sda mkpart "'primary'" 1048576B 299892735B >&2
my_udevsettle
my_udevsettle
parted -s /dev/sda set 1 boot on >&2
my_udevsettle
my_udevsettle
parted -s /dev/sda mkpart "'primary'" 299892736B 64423460863B >&2
my_udevsettle
sleep 1
if ! partprobe -s /dev/sda >&2 ; then
    LogPrint 'retrying partprobe /dev/sda after 10 seconds' 
    sleep 10
    if ! partprobe -s /dev/sda >&2 ; then
        LogPrint 'retrying partprobe /dev/sda after 1 minute' 
        sleep 60
        if ! partprobe -s /dev/sda >&2 ; then
            LogPrint 'partprobe /dev/sda failed, proceeding bona fide' 
        fi
    fi
fi
# Make sure device nodes are visible (eg. in RHEL4)
my_udevtrigger
my_udevsettle
component_created "/dev/sda" "disk"
else
    LogPrint "Skipping /dev/sda (disk) as it has already been created."
fi

if create_component "/dev/sda1" "part" ; then
# Create /dev/sda1 (part)
component_created "/dev/sda1" "part"
else
    LogPrint "Skipping /dev/sda1 (part) as it has already been created."
fi

if create_component "/dev/sda2" "part" ; then
# Create /dev/sda2 (part)
component_created "/dev/sda2" "part"
else
    LogPrint "Skipping /dev/sda2 (part) as it has already been created."
fi

if create_component "/dev/mapper/sda2_crypt" "crypt" ; then
# Create /dev/mapper/sda2_crypt (crypt)
Log "Creating LUKS device sda2_crypt on /dev/sda2"
LogPrint "Please enter the password for LUKS device sda2_crypt (/dev/sda2):"
cryptsetup luksFormat --batch-mode  --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid 6121978d-3287-4720-8d66-a134075773a0 --iter-time 2000 --use-random /dev/sda2
LogPrint "Please re-enter the password for LUKS device sda2_crypt (/dev/sda2):"
cryptsetup luksOpen /dev/sda2 sda2_crypt

component_created "/dev/mapper/sda2_crypt" "crypt"
else
    LogPrint "Skipping /dev/mapper/sda2_crypt (crypt) as it has already been created."
fi

if create_component "pv:/dev/mapper/sda2_crypt" "lvmdev" ; then
# Create pv:/dev/mapper/sda2_crypt (lvmdev)
LogPrint "Creating LVM PV /dev/mapper/sda2_crypt"
lvm vgchange -a n vg01 || true
lvm pvcreate -ff --yes -v --uuid "v0wMqg-tkjw-0bU2-ZEcP-s0hG-Cqo7-YPetCc" --restorefile /var/lib/rear/layout/lvm/vg01.cfg /dev/mapper/sda2_crypt >&2
component_created "pv:/dev/mapper/sda2_crypt" "lvmdev"
else
    LogPrint "Skipping pv:/dev/mapper/sda2_crypt (lvmdev) as it has already been created."
fi

if create_component "/dev/vg01" "lvmgrp" ; then
# Create /dev/vg01 (lvmgrp)
create_volume_group=1
create_logical_volumes=1
create_thin_volumes_only=0

LogPrint "Restoring LVM VG 'vg01'"
if [ -e "/dev/vg01" ] ; then
    rm -rf "/dev/vg01"
fi
#
# Restore layout using 'vgcfgrestore', this may fail if there are Thin volumes
#
if lvm vgcfgrestore -f "/var/lib/rear/layout/lvm/vg01.cfg" vg01 >&2 ; then
    lvm vgchange --available y vg01 >&2

    LogPrint "Sleeping 3 seconds to let udev or systemd-udevd create their devices..."
    sleep 3 >&2
    create_volume_group=0
    create_logical_volumes=0

#
# It failed ... restore layout using 'vgcfgrestore --force', but then remove Thin volumes, they are broken
#
elif lvm vgcfgrestore --force -f "/var/lib/rear/layout/lvm/vg01.cfg" vg01 >&2 ; then

    lvm lvs --noheadings -o lv_name,vg_name,lv_layout | while read lv vg layout ; do
        # Consider LVs for our VG only
        [ $vg == "vg01" ] || continue
        # Consider Thin Pools only
        [[ ,$layout, == *,thin,* ]] && [[ ,$layout, == *,pool,* ]] || continue
        # Remove twice, the first time it fails because of thin volumes in the pool
        lvm lvremove -q -f -y $vg/$lv || true
        lvm lvremove -q -f -y $vg/$lv
    done

    # All logical volumes have been created, except Thin volumes and pools
    create_volume_group=0
    create_thin_volumes_only=1

#
# It failed also ... restore using 'vgcreate/lvcreate' commands
#
else
    LogPrint "Warning: could not restore LVM configuration using 'vgcfgrestore'. Using traditional 'vgcreate/lvcreate' commands instead..."
fi

if [ $create_volume_group -eq 1 ] ; then
    LogPrint "Creating LVM VG 'vg01'; Warning: some properties may not be preserved..."
    if [ -e "/dev/vg01" ] ; then
        rm -rf "/dev/vg01"
    fi
    lvm vgcreate --physicalextentsize 4096k vg01 /dev/mapper/sda2_crypt >&2
    lvm vgchange --available y vg01 >&2
fi
component_created "/dev/vg01" "lvmgrp"
else
    LogPrint "Skipping /dev/vg01 (lvmgrp) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_home" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_home (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_home'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 4999610368b -n lv_home vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_home" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_home (lvmvol) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_log" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_log (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_log'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 7499415552b -n lv_log vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_log" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_log (lvmvol) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_root" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_root (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_root'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 9999220736b -n lv_root vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_root" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_root (lvmvol) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_swap" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_swap (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_swap'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 3997171712b -n lv_swap vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_swap" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_swap (lvmvol) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_tmp" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_tmp (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_tmp'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 2998927360b -n lv_tmp vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_tmp" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_tmp (lvmvol) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_var" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_var (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_var'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 14998831104b -n lv_var vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_var" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_var (lvmvol) as it has already been created."
fi

if create_component "/dev/mapper/vg01-lv_www" "lvmvol" ; then
# Create /dev/mapper/vg01-lv_www (lvmvol)

if [ "$create_logical_volumes" -eq 1 ] && [ "$create_thin_volumes_only" -eq 0 ] ; then

    LogPrint "Creating LVM volume 'vg01/lv_www'; Warning: some properties may not be preserved..."

    lvm lvcreate -L 4999610368b -n lv_www vg01 <<<y

fi
component_created "/dev/mapper/vg01-lv_www" "lvmvol"
else
    LogPrint "Skipping /dev/mapper/vg01-lv_www (lvmvol) as it has already been created."
fi

if create_component "fs:/" "fs" ; then
# Create fs:/ (fs)
# Wait until udev had created '/dev/mapper/vg01-lv_root' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/' on '/dev/mapper/vg01-lv_root'.'
# Using wipefs to cleanup '/dev/mapper/vg01-lv_root' before creating filesystem.
wipefs --all --force /dev/mapper/vg01-lv_root || wipefs --all /dev/mapper/vg01-lv_root || dd if=/dev/zero of=/dev/mapper/vg01-lv_root bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 4096 -i 16370 -U ee84fcac-6a9b-440b-82e0-537e24254e76 -F /dev/mapper/vg01-lv_root >&2 ; then
    mkfs -t ext4 -b 4096 -i 16370 -F /dev/mapper/vg01-lv_root >&2
    tune2fs -U ee84fcac-6a9b-440b-82e0-537e24254e76 /dev/mapper/vg01-lv_root >&2
fi
tune2fs  -m 4 -c -1 -i 0d -o user_xattr,acl /dev/mapper/vg01-lv_root >&2
LogPrint "Mounting filesystem /"
mkdir -p /mnt/local/
mount -o rw,relatime,errors=remount-ro /dev/mapper/vg01-lv_root /mnt/local/
component_created "fs:/" "fs"
else
    LogPrint "Skipping fs:/ (fs) as it has already been created."
fi

if create_component "fs:/home" "fs" ; then
# Create fs:/home (fs)
# Wait until udev had created '/dev/mapper/vg01-lv_home' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/home' on '/dev/mapper/vg01-lv_home'.'
# Using wipefs to cleanup '/dev/mapper/vg01-lv_home' before creating filesystem.
wipefs --all --force /dev/mapper/vg01-lv_home || wipefs --all /dev/mapper/vg01-lv_home || dd if=/dev/zero of=/dev/mapper/vg01-lv_home bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 4096 -i 16380 -U dd4343d0-561a-4816-aabc-02e95db69b44 -F /dev/mapper/vg01-lv_home >&2 ; then
    mkfs -t ext4 -b 4096 -i 16380 -F /dev/mapper/vg01-lv_home >&2
    tune2fs -U dd4343d0-561a-4816-aabc-02e95db69b44 /dev/mapper/vg01-lv_home >&2
fi
tune2fs  -m 4 -c -1 -i 0d -o user_xattr,acl /dev/mapper/vg01-lv_home >&2
LogPrint "Mounting filesystem /home"
mkdir -p /mnt/local/home
mount -o rw,nosuid,dev,relatime /dev/mapper/vg01-lv_home /mnt/local/home
component_created "fs:/home" "fs"
else
    LogPrint "Skipping fs:/home (fs) as it has already been created."
fi

if create_component "fs:/tmp" "fs" ; then
# Create fs:/tmp (fs)
# Wait until udev had created '/dev/mapper/vg01-lv_tmp' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/tmp' on '/dev/mapper/vg01-lv_tmp'.'
# Using wipefs to cleanup '/dev/mapper/vg01-lv_tmp' before creating filesystem.
wipefs --all --force /dev/mapper/vg01-lv_tmp || wipefs --all /dev/mapper/vg01-lv_tmp || dd if=/dev/zero of=/dev/mapper/vg01-lv_tmp bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 4096 -i 16363 -U a6ff2f0d-5d2f-453e-9c86-bde99af92d5c -F /dev/mapper/vg01-lv_tmp >&2 ; then
    mkfs -t ext4 -b 4096 -i 16363 -F /dev/mapper/vg01-lv_tmp >&2
    tune2fs -U a6ff2f0d-5d2f-453e-9c86-bde99af92d5c /dev/mapper/vg01-lv_tmp >&2
fi
tune2fs  -m 5 -c -1 -i 0d -o user_xattr,acl /dev/mapper/vg01-lv_tmp >&2
LogPrint "Mounting filesystem /tmp"
mkdir -p /mnt/local/tmp
mount -o rw,nosuid,dev,relatime /dev/mapper/vg01-lv_tmp /mnt/local/tmp
component_created "fs:/tmp" "fs"
else
    LogPrint "Skipping fs:/tmp (fs) as it has already been created."
fi

if create_component "fs:/var" "fs" ; then
# Create fs:/var (fs)
# Wait until udev had created '/dev/mapper/vg01-lv_var' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/var' on '/dev/mapper/vg01-lv_var'.'
# Using wipefs to cleanup '/dev/mapper/vg01-lv_var' before creating filesystem.
wipefs --all --force /dev/mapper/vg01-lv_var || wipefs --all /dev/mapper/vg01-lv_var || dd if=/dev/zero of=/dev/mapper/vg01-lv_var bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 4096 -i 16379 -U b4d5579d-dc2a-4d26-adef-4cfb1cc81945 -F /dev/mapper/vg01-lv_var >&2 ; then
    mkfs -t ext4 -b 4096 -i 16379 -F /dev/mapper/vg01-lv_var >&2
    tune2fs -U b4d5579d-dc2a-4d26-adef-4cfb1cc81945 /dev/mapper/vg01-lv_var >&2
fi
tune2fs  -m 4 -c -1 -i 0d -o user_xattr,acl /dev/mapper/vg01-lv_var >&2
LogPrint "Mounting filesystem /var"
mkdir -p /mnt/local/var
mount -o rw,dev,relatime /dev/mapper/vg01-lv_var /mnt/local/var
component_created "fs:/var" "fs"
else
    LogPrint "Skipping fs:/var (fs) as it has already been created."
fi

if create_component "fs:/var/log" "fs" ; then
# Create fs:/var/log (fs)
# Wait until udev had created '/dev/mapper/vg01-lv_log' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/var/log' on '/dev/mapper/vg01-lv_log'.'
# Using wipefs to cleanup '/dev/mapper/vg01-lv_log' before creating filesystem.
wipefs --all --force /dev/mapper/vg01-lv_log || wipefs --all /dev/mapper/vg01-lv_log || dd if=/dev/zero of=/dev/mapper/vg01-lv_log bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 4096 -i 16379 -U d7805a44-9965-45a6-899f-0be13c9c1a0b -F /dev/mapper/vg01-lv_log >&2 ; then
    mkfs -t ext4 -b 4096 -i 16379 -F /dev/mapper/vg01-lv_log >&2
    tune2fs -U d7805a44-9965-45a6-899f-0be13c9c1a0b /dev/mapper/vg01-lv_log >&2
fi
tune2fs  -m 4 -c -1 -i 0d -o user_xattr,acl /dev/mapper/vg01-lv_log >&2
LogPrint "Mounting filesystem /var/log"
mkdir -p /mnt/local/var/log
mount -o rw,nosuid,dev,noexec,relatime /dev/mapper/vg01-lv_log /mnt/local/var/log
component_created "fs:/var/log" "fs"
else
    LogPrint "Skipping fs:/var/log (fs) as it has already been created."
fi

if create_component "fs:/var/www" "fs" ; then
# Create fs:/var/www (fs)
# Wait until udev had created '/dev/mapper/vg01-lv_www' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/var/www' on '/dev/mapper/vg01-lv_www'.'
# Using wipefs to cleanup '/dev/mapper/vg01-lv_www' before creating filesystem.
wipefs --all --force /dev/mapper/vg01-lv_www || wipefs --all /dev/mapper/vg01-lv_www || dd if=/dev/zero of=/dev/mapper/vg01-lv_www bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 4096 -i 16380 -U 0f8631e1-37c2-4637-9f9a-48f9636c4bcd -F /dev/mapper/vg01-lv_www >&2 ; then
    mkfs -t ext4 -b 4096 -i 16380 -F /dev/mapper/vg01-lv_www >&2
    tune2fs -U 0f8631e1-37c2-4637-9f9a-48f9636c4bcd /dev/mapper/vg01-lv_www >&2
fi
tune2fs  -m 4 -c -1 -i 0d -o user_xattr,acl /dev/mapper/vg01-lv_www >&2
LogPrint "Mounting filesystem /var/www"
mkdir -p /mnt/local/var/www
mount -o rw,nosuid,dev,noexec,relatime /dev/mapper/vg01-lv_www /mnt/local/var/www
component_created "fs:/var/www" "fs"
else
    LogPrint "Skipping fs:/var/www (fs) as it has already been created."
fi

if create_component "fs:/boot" "fs" ; then
# Create fs:/boot (fs)
# Wait until udev had created '/dev/sda1' before creating a filesystem there:
my_udevsettle
LogPrint 'Creating filesystem of type 'ext4' with mount point '/boot' on '/dev/sda1'.'
# Using wipefs to cleanup '/dev/sda1' before creating filesystem.
wipefs --all --force /dev/sda1 || wipefs --all /dev/sda1 || dd if=/dev/zero of=/dev/sda1 bs=512 count=1 || true
# Try 'mkfs -U' to create the filesystem with initially correct UUID
# but if that fails assume it failed because of missing support for '-U'
# (e.g. in RHEL 5 it fails, see https://github.com/rear/rear/issues/890)
# then fall back to using mkfs without '-U' plus 'tune2fs/tune4fs -U'
if ! mkfs -t ext4 -b 1024 -i 4085 -U e5fefbc4-bec5-4707-b6a7-b25dc16e3b1d -F /dev/sda1 >&2 ; then
    mkfs -t ext4 -b 1024 -i 4085 -F /dev/sda1 >&2
    tune2fs -U e5fefbc4-bec5-4707-b6a7-b25dc16e3b1d /dev/sda1 >&2
fi
tune2fs -L lv_boot /dev/sda1 >&2
tune2fs  -m 5 -c -1 -i 0d -o user_xattr,acl /dev/sda1 >&2
LogPrint "Mounting filesystem /boot"
mkdir -p /mnt/local/boot
mount -o ro,nosuid,dev,noexec,relatime /dev/sda1 /mnt/local/boot
component_created "fs:/boot" "fs"
else
    LogPrint "Skipping fs:/boot (fs) as it has already been created."
fi

if create_component "swap:/dev/mapper/vg01-lv_swap" "swap" ; then
# Create swap:/dev/mapper/vg01-lv_swap (swap)
LogPrint "Creating swap on /dev/mapper/vg01-lv_swap"
mkswap -U 287661ac-b09b-46ab-8619-a24eff766db8 /dev/mapper/vg01-lv_swap >&2
component_created "swap:/dev/mapper/vg01-lv_swap" "swap"
else
    LogPrint "Skipping swap:/dev/mapper/vg01-lv_swap (swap) as it has already been created."
fi


set +x
set +e

LogPrint "Disk layout created."

jsmeix commented at 2020-05-07 08:40:¶

@vigri
I know basically nothing about LUKS internals
so I cannot actually debug issues with LUKS.
Therefore only as a shot into the dark
(my kids would call that a "360 noscope" in Fortnite ;-)
Do you perhaps use LUKS version 2 ?

If yes, that is currently not supported, see
https://github.com/rear/rear/issues/2204

In recent ReaR GitHub master code I added a test
(cf. https://github.com/rear/rear/pull/2381)
so that now ReaR at least errors out if LUKS version 2 is used, see
https://github.com/rear/rear/issues/2204#issuecomment-619824042

vigri commented at 2020-05-07 08:52:¶

I've checked the version. It's version 1:

x1@svr01:~$ sudo cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2
Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512

vigri commented at 2020-05-07 15:44:¶

I tried to investigate the error further...

fdisk -l right after ReaR booted and I logged in with root:

fdisk -l
Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Sector size: 512 bytes

then I executed rear recover which failed. Output of fdisk -l again:

Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbd17c94f

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sda1  *      2048    585727    583680  285M 83 Linux
/dev/sda2       585728 125827071 125241344 59.7G 83 Linux

Disk /dev/mapper/sda2_crypt: 59.7 GiB, 64106790912 bytes, 125208576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

vg01.cfg (excerpt)

physical_volumes {

        pv0 {
            id = "v0wMqg-tkjw-0bU2-ZEcP-s0hG-Cqo7-YPetCc"
            device = "/dev/mapper/sda2_crypt"   # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 125237248    # 59.7178 Gigabytes
            pe_start = 2048
            pe_count = 15287    # 59.7148 Gigabytes
        }
    }

This is the the output of fdisk -l on the original (up and running) system I tried to restore:

Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbd21e3f1

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sda1  *      2048    585727    583680  285M 83 Linux
/dev/sda2       585728 125827071 125241344 59.7G 83 Linux

My conclusion
The dev_size in /var/lib/rear/layout/lvm/vg01.cfg is 125237248 sectors.
The size (in sectors) of /dev/mapper/sda2_crypt is 125208576.

Because of that the recovery is failing.

If I raise the disk size of the recovery system to 61GB rear recover works.

So the question is: Why is /dev/mapper/sda2_crypt smaller than 125237248 sectors (vg01.cfg)...

jsmeix commented at 2020-05-08 11:49:¶

@vigri
because I know basically nothing about LUKS internals
I cannot actually debug issues with LUKS.

Excerpts from what I see in your comments:

The disk partitions on your original systems

/dev/sda1  *      2048    585727    583680  285M 83 Linux
/dev/sda2       585728 125827071 125241344 59.7G 83 Linux

and after "rear recover" on the replacement hardware

/dev/sda1  *      2048    585727    583680  285M 83 Linux
/dev/sda2       585728 125827071 125241344 59.7G 83 Linux

are exactly same which is the expected result when the
disk on the replacement hardware has exact same size.

From your disklayout.conf I see that the partition sizes are

part /dev/sda 298844160 1048576 primary boot /dev/sda1
part /dev/sda 64123568128 299892736 primary none /dev/sda2

i.e. /dev/sda2 has a size of 64123568128 bytes.

Fom what I see in your diskrestore.sh script ist seems therein the command

cryptsetup luksFormat --batch-mode  --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid 6121978d-3287-4720-8d66-a134075773a0 --iter-time 2000 --use-random /dev/sda2

that is run during "rear recover" results on the replacement hardware
those LUKS encrypted volume

/dev/mapper/sda2_crypt: 59.7 GiB, 64106790912 bytes

i.e. the recreated LUKS encrypted volume is
64123568128 bytes - 64106790912 bytes = 16777216 bytes = 16 MiB
smaller than its parent device /dev/sda2

I assume on your original system the LUKS encrypted volume
/dev/mapper/sda2_crypt is a bit bigger than 64106790912 bytes.

To verify that please show us the output of the command

lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT

on your original system.

Fortunately I use LUKS on my homeoffice laptop (with openSUSE Leap 15.1)
so I can compare how things look for me and there I get (excerpts):

# lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT

NAME                                                      KNAME      PKNAME    TRAN   TYPE  FSTYPE              SIZE MOUNTPOINT
...
|-/dev/sda2                                               /dev/sda2  /dev/sda         part  crypto_LUKS   4294967296 
| `-/dev/mapper/cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 /dev/dm-1  /dev/sda2        crypt swap          4292870144 [SWAP]
|-/dev/sda3                                               /dev/sda3  /dev/sda         part  crypto_LUKS 214748364800 
| `-/dev/mapper/cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 /dev/dm-0  /dev/sda3        crypt ext4        214746267648 /

so the LUKS encrypted volume for swap is
4294967296 - 4292870144 = 209715 bytes = 2MiB
smaller than its parent device /dev/sda2
and the LUKS encrypted volume for the root filesystem is
214748364800 - 214746267648 = 209715 bytes = 2MiB
smaller than its parent device /dev/sda3
so both LUKS encrypted volumes are exactly 2MiB
smaller than their parent devices in my case.

vigri commented at 2020-05-09 08:59:¶

Here we go

user@XXXXXXXXXX:~$ lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                           KNAME      PKNAME    TRAN TYPE  FSTYPE             SIZE MOUNTPOINT
/dev/loop0                     /dev/loop0                loop  squashfs       98484224 /snap/core/9066
/dev/loop1                     /dev/loop1                loop  squashfs       57618432 /snap/core18/1754
/dev/loop2                     /dev/loop2                loop  squashfs       72601600 /snap/lxd/15019
/dev/loop4                     /dev/loop4                loop  squashfs       57614336 /snap/core18/1705
/dev/loop5                     /dev/loop5                loop  squashfs       98336768 /snap/core/8935
/dev/loop6                     /dev/loop6                loop  squashfs       72593408 /snap/lxd/14999
/dev/sda                       /dev/sda                  disk              64424509440
|-/dev/sda1                    /dev/sda1  /dev/sda       part  ext4          298844160 /boot
`-/dev/sda2                    /dev/sda2  /dev/sda       part  crypto_LUKS 64123568128
  `-/dev/mapper/sda2_crypt     /dev/dm-0  /dev/sda2      crypt LVM2_member 64121470976
    |-/dev/mapper/vg01-lv_root /dev/dm-1  /dev/dm-0      lvm   ext4         9999220736 /
    |-/dev/mapper/vg01-lv_home /dev/dm-2  /dev/dm-0      lvm   ext4         4999610368 /home
    |-/dev/mapper/vg01-lv_tmp  /dev/dm-3  /dev/dm-0      lvm   ext4         2998927360 /tmp
    |-/dev/mapper/vg01-lv_swap /dev/dm-4  /dev/dm-0      lvm   swap         3997171712 [SWAP]
    |-/dev/mapper/vg01-lv_var  /dev/dm-5  /dev/dm-0      lvm   ext4        14998831104 /var
    |-/dev/mapper/vg01-lv_log  /dev/dm-6  /dev/dm-0      lvm   ext4         7499415552 /var/log
    `-/dev/mapper/vg01-lv_www  /dev/dm-7  /dev/dm-0      lvm   ext4         4999610368 /var/www
/dev/sr0                       /dev/sr0             ata  rom                1073741312

jsmeix commented at 2020-05-12 12:52:¶

q.e.d.

On the original system lsblk in
https://github.com/rear/rear/issues/2389#issuecomment-626132493
reports

/dev/mapper/sda2_crypt     /dev/dm-0  /dev/sda2      crypt LVM2_member 64121470976

During "rear recover" on the replacement hardware
those LUKS encrypted volume gets recreated,
cf. the Output of fdisk -l again in
https://github.com/rear/rear/issues/2389#issuecomment-625334979

/dev/mapper/sda2_crypt: 59.7 GiB, 64106790912 bytes

So the LUKS encrypted volume size decreased by
64121470976 - 64106790912 = 14680064 bytes = 14MiB

I know basically nothing about LUKS internals
so I cannot actually debug why the command

cryptsetup luksFormat --batch-mode  --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid 6121978d-3287-4720-8d66-a134075773a0 --iter-time 2000 --use-random /dev/sda2

results on the replacement hardware a LUKS encrypted volume
that is 14MiB smaller than what it was on the original system.

vigri commented at 2020-05-12 20:07:¶

I've relied on the "60 GB" which are shown in the web gui of my webhoster.
Because of that I created during my test a 60 GB HDD in vmware.

So maybe the 60 GB which were shown in the web gui were somthing around 60,0xxx GB in reality.

Anyway clearly not a fault of ReaR! 👍
Thanks for your support.

jsmeix commented at 2020-05-13 08:11:¶

@vigri
now I am confused because as far as I understand your
https://github.com/rear/rear/issues/2389#issuecomment-625334979
you reported that the disk size 64424509440 bytes = 60.00000000000 GiB
is identical on your original system and on your replacement hardware
and that also the disk partition sizes are identical on both systems, cf. my
https://github.com/rear/rear/issues/2389#issuecomment-625777923
and
https://github.com/rear/rear/issues/2389#issuecomment-627323031
where I concluded that the cryptsetup that is run during "rear recover"
recreates the LUKS encrypted volume 14MiB smaller
than what it was on the original system.

vigri commented at 2020-05-18 10:29:¶

Basically I have a hosted server which I wanted to backup. The server has a 60GB disk.
To test if the recovery works I created on my local computer a virtual machine with the "same" size (during the creation process I selected 60GB for the disk.)

After reading your commend and my comment twice.... you're right. https://github.com/rear/rear/issues/2389#issuecomment-627565932 can't be true.

Please tell me which information you need so we can investigate this further.

jsmeix commented at 2020-05-18 12:20:¶

@vigri
again:
Because I know basically nothing about LUKS internals
I cannot actually debug issues with LUKS.
so I can only basically blindly guess.

Provided my finding is right that cryptsetup that is run during "rear recover"
recreates the LUKS encrypted volume 14MiB smaller
than what it was on the original system
then
what needs to be debugged is to find out
WHY cryptsetup behaves this way.

But I cannot actually debug why the command

cryptsetup luksFormat --batch-mode  --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid 6121978d-3287-4720-8d66-a134075773a0 --iter-time 2000 --use-random /dev/sda2

results on the replacement hardware a LUKS encrypted volume
that is 14MiB smaller than what it was on the original system, cf.
https://github.com/rear/rear/issues/2389#issuecomment-627323031

Such kind of behaviour is unexpected because the cryptsetup that is
run during "rear recover" is ecactly the cryptsetup binary from the
original system so it should behave same as on the original system.

But things could behave different when for example cryptsetup
was updated on the original system so that an updated cryptsetup
will be running during "rear recover" compared to the cryptsetup
that was run when the original system was created.

Or the cryptsetup that was run when the original system was created
was called with special options?

When I skim through "man cryptsetup" I notice this parts (excerpts):

--align-payload <number of 512 byte sectors>
Align payload at a boundary of value 512-byte sectors.
This option is relevant for luksFormat.
If not specified, cryptsetup tries to use the topology info
provided by the kernel for the underlying device to get
the optimal alignment.
If not available (or the calculated value is a multiple
of the default) data is by default aligned to a 1MiB boundary
(i.e. 2048 512-byte sectors).

So perhaps for the disk of the original system that alignment
results a LUKS metadata header of 2 MiB size
(more percisely the payload starts after 2 MiB)
while for the disk of the replacement system that alignment
results a LUKS metadata header of 2 + 14 = 16 MiB size
(more percisely the payload starts after 16 MiB)
because
"the topology info provided by the kernel for the underlying device"
is different for the original disk compared to the replacement disk?

Because the

cryptsetup luksFormat --batch-mode  --cipher aes-xts-plain64 --key-size 512 --hash sha256 --uuid 6121978d-3287-4720-8d66-a134075773a0 --iter-time 2000 --use-random /dev/sda2

command does not specify --align-payload 4096 to enforce
a 2 MiB alignment it looks possible that the default alignment value
could be different on the replacement disk compared to the original disk.

The cryptsetup luksFormat command appears only in
usr/share/rear/layout/prepare/GNU/Linux/160_include_luks_code.sh
so you could as a test change the cryptsetup luksFormat commands
and append --align-payload 4096 to enforce a 2 MiB alignment.
Perhaps this way you get it recreated exactly same as it was before.

But if you enforce to recreate it with only 2 MiB alignment on the new disk
compared to the default alignment value of 16 MiB that results from
"the topology info provided by the kernel for the underlying device"
the disk I/O performance and the disk lifetime could be noticeable less
than what is right for "the topology for the underlying device"
in particular when you use a SSD because on SSDs the physical block size
(i.e. the block size that the actual flash storage hardware works with)
is usually 4 MiB or 8 MiB or perhaps even 16 MiB on nowadays big SSDs,
cf. my last comment in
https://hackweek.suse.com/19/projects/linux-system-on-usb-stick
and
https://bugzilla.opensuse.org/show_bug.cgi?id=820435
therein in particular
https://bugzilla.opensuse.org/show_bug.cgi?id=820435#c5
and follow the links therein, in particluar
https://lwn.net/Articles/428584/

So in the end I think it is likely better to rely on
the default LUKS payload alignment value that matches
"the topology info provided by the kernel for the underlying device"
and use a bit bigger replacement disk when needed.

jsmeix commented at 2020-06-09 11:33:¶

I tried LVM on LUKS on SLES 12 SP 5 cf. the section
"SLES 12 SP 5 with default LUKS encrypted LVM and btrfs structure" in
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6
and for me "rear recover" results a byte-by-byte identical
recreated disk layout:

# lsblk -ibpo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT

NAME                                               KNAME     PKNAME    TRAN TYPE  FSTYPE             SIZE MOUNTPOINT
/dev/sda                                           /dev/sda            ata  disk              21474836480 
|-/dev/sda1                                        /dev/sda1 /dev/sda       part  ext4          418381824 /boot
`-/dev/sda2                                        /dev/sda2 /dev/sda       part  crypto_LUKS 21055406080 
  `-/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2 /dev/dm-0 /dev/sda2      crypt LVM2_member 21053308928 
    |-/dev/mapper/system-root                      /dev/dm-1 /dev/dm-0      lvm   btrfs       18895339520 /
    `-/dev/mapper/system-swap                      /dev/dm-2 /dev/dm-0      lvm   swap         2147483648 [SWAP]

The LUKS data payload alignment in my case is again
21055406080 - 21053308928 = 2097152 bytes = 2 MiB

While I did that test "rear recover" had initially failed for me because
cryptsetup failed which lets ReaR's diskrestore.sh script fail
because I had used a weak LUKS password for my test
so I had to set in /etc/rear/local.conf in the ReaR recovery system

LUKS_CRYPTSETUP_OPTIONS+=" --force-password"

to enfore that cryptsetup accepts even a weak password.

By the way:
Instead of hacking --align-payload 4096 into a ReaR script, cf.
https://github.com/rear/rear/issues/2389#issuecomment-630144898
you could better specify such things in etc/rear/local.cvnf as

LUKS_CRYPTSETUP_OPTIONS+=" --align-payload 4096"

jsmeix commented at 2020-06-09 12:57:¶

By the way:
I was wondering if we could have the cryptsetup option
--force-password by default in default.conf because
it is the job of ReaR to let the user recreate his system
exactly as it was before i.e. with weak passwords
but not to patronize the user what paswords he must use.
But we cannot have --force-password in default.conf because
on SLES11 man cryptsetup does not list --force-password
so to stay backward compatible with older Linux distributions
we cannot have settings in default.conf that would let things fail
on older Linux distributions.

jsmeix commented at 2020-06-09 12:58:¶

Via
https://github.com/rear/rear/commit/09f265602d2bdc1b2e259ff0836d6a44da086987
now in default.conf the LUKS_CRYPTSETUP_OPTIONS usage
is better described plus some examples according to
what I learned from this issue here.

jsmeix commented at 2020-06-09 13:18:¶

@vigri
I think with the better description of LUKS_CRYPTSETUP_OPTIONS via
https://github.com/rear/rear/commit/09f265602d2bdc1b2e259ff0836d6a44da086987
this issue should be solved as far as currently possible for us
at ReaR upstream for our upcoming ReaR 2.6 release.
Therefore I would like to close this issue hereby.
Of course further comments can be added here nevertheless.

jsmeix commented at 2020-06-09 14:08:¶

FYI:
I could reproduce the "rear recover" failure during LVM setup with

LUKS_CRYPTSETUP_OPTIONS+=" --align-payload 32768"

in my etc/rear/local.conf that enforces 16 MiB alignment of the
LUKS data payload during "rear recover" compared to
only 2 MiB alignment on my original system.

[Export of Github issue for rear/rear.]

#2389 Issue closed: Restore fails with LVM on LUKS encrypted volume¶