#2638 Issue `closed`: diskrestore.sh fails on already used disk (works on empty disk)¶

Labels: support / question, fixed / solved / done

cvijayvinoth opened issue at 2021-06-22 14:16:¶

ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.6 / Git
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

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

OUTPUT=ISO
BACKUP=RSYNC
RSYNC_PREFIX="vijay_${HOSTNAME}"
BACKUP_PROG="/var/www/html/imageBackup/rsync"
OUTPUT_URL=rsync://yuvaraj1@192.168.1.5::rsync_backup
BACKUP_URL=rsync://yuvaraj1@192.168.1.5::rsync_backup
BACKUP_RSYNC_OPTIONS+=(-z --progress --password-file=/var/www/html/xxxxx/xxxx)
ISO_DIR="/var/www/html/imageBackup/iso/$HOSTNAME"
MESSAGE_PREFIX="$$: "
PROGRESS_MODE="plain"
AUTOEXCLUDE_PATH=( /tmp )
PROGRESS_WAIT_SECONDS="1"
export TMPDIR="/var/www/html/imageBackup/iso/"
PXE_RECOVER_MODE=automatic
ISO_FILES=("/var/www/html/imageBackup/rsync")
ISO_PREFIX="${HOSTNAME}"
ISO_DEFAULT="automatic"

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
PC
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):
UEFI and GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
local
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0  55.4M  1 loop  /snap/core18/1944
loop1         7:1    0  31.1M  1 loop  /snap/snapd/10707
loop2         7:2    0  69.9M  1 loop  /snap/lxd/19188
loop3         7:3    0  55.4M  1 loop  /snap/core18/2066
loop4         7:4    0  32.3M  1 loop  /snap/snapd/12159
sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   512M  0 part  /boot/efi
└─sda2        8:2    0   931G  0 part
  └─md0       9:0    0 465.6G  0 raid1
    ├─md0p1 259:1    0   200G  0 part  /
    ├─md0p2 259:2    0    20G  0 part  /boot
    ├─md0p3 259:3    0   200G  0 part  /home
    └─md0p4 259:4    0  45.6G  0 part  [SWAP]
sdb           8:16   1  28.7G  0 disk
└─sdb1        8:17   1  28.7G  0 part
  └─md1       9:1    0  28.6G  0 raid1
    └─md1p1 259:0    0  28.6G  0 part  /mnt/raid1
sdc           8:32   1  28.7G  0 disk
└─sdc1        8:33   1  28.7G  0 part
  └─md1       9:1    0  28.6G  0 raid1
    └─md1p1 259:0    0  28.6G  0 part  /mnt/raid1
sdd           8:48   0 465.7G  0 disk
└─sdd1        8:49   0 465.7G  0 part
  └─md0       9:0    0 465.6G  0 raid1
    ├─md0p1 259:1    0   200G  0 part  /
    ├─md0p2 259:2    0    20G  0 part  /boot
    ├─md0p3 259:3    0   200G  0 part  /home
    └─md0p4 259:4    0  45.6G  0 part  [SWAP]
sr0          11:0    1  1024M  0 rom

Description of the issue (ideally so that others can reproduce it):

during the recovery process restore The disk layout recreation script failed
Attached disklayout file too. Same iso image is working fine in virtualbox.
Only on physical machine I am facing this issue.
In physical machine for create_component "/dev/md0" "raid"
condition the touch file created like rear-vgchange

Workaround, if any:

when i manually ran the command

mdadm --create /dev/md0 --force --metadata=1.2 --level=raid1 --raid-devices=2 --uuid=1ebd01dd:0e40a36e:0bc73849:0dcb662a /dev/sda2 /dev/sde1

I got the below error.

mdadm: super1.x cannot open /dev/sda2: Device or resource busy
mdadm: /dev/sda2 is not suitable for this array.
mdadm: super1.x cannot open /dev/sde1: Device or resource busy
mdadm: /dev/sde1 is not suitable for this array.
mdadm: create aborted

It looks it will work fine for empty disks and
if the os already exist it throws an error.

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear-vijay.log
disklayout.txt

jsmeix commented at 2021-06-25 05:53:¶

@cvijayvinoth
the crucial part is that you wrote:

It looks it will work fine for empty disks and
if the os already exist it throws an error.

This behaviour is no bug in current ReaR.

This kind of possible behaviour is well known at ReaR upstream.
For details and background information see
https://github.com/rear/rear/issues/799

This possible behaviour is explained in the section
"Prepare replacement hardware for disaster recovery" in
https://en.opensuse.org/SDB:Disaster_Recovery
therein in particular the part about
"you must completely zero out your replacement storage".

Same kind of possible behaviour can also happen
when one installs a system anew on an already used disk
that was not sufficiently zeroed out before.
Any system installer program has this kind of issue.
The only difference is that when installing a system anew
it is less likely that remainder data on an already used disk
gets in the way because when installing a system anew
the partitioning is likely (at least a bit) different.
In contrast when ReaR is used to reinstall a system
on the exact same disk where it had been before
(e.g. during a test where the replacement disk is
the exact same disk of the original system)
ReaR will recreate the disk layout byte-by-byte exactly
as it was before and then remainder data on the disk will
"magically" (in fact not magically but deterministically)
re-appear and cause various kind of weird issues.

In current ReaR upstream master code I implemented some initial
preliminary functionality (that is disabled by default) to
"Wipe disks before recreating partitions/volumes/filesystems/..."
https://github.com/rear/rear/pull/2514

It is not at all yet "ready for general production use"
but testing how far it works "out there in real world"
would be much appreciated.

By the way FYI:

When "rear recover" failed during disk layout recreation
it often gets too complicated to fix things properly
after "rear recover" failed so that one could continue
"rear recover" and the rest of "rear recover" succeeds
or rerun "rear recover" and then it succeeds.

What usually works much better when "rear recover" failed
during disk layout recreation is to start over from the beginning
i.e. reboot the ReaR recovery system and then
fix things before "rear recover" is called.
For example manually removing existing old/outdated partitions
and other higher level storage objects (like RAID or LVM things)
from the target system disks should be done in the recovery system
before "rear recover" is called, e.g. see the first entries in
https://github.com/rear/rear/issues/799

In contrast when "rear recover" failed after it had
successfully recreated the disk layout
and successfully restored the backup,
then it is often rather straightforward
to fix some remaining things in the restored target system
that is mounted in the ReaR recovery system at /mnt/local
like manually installing a bootloader via "chroot /mnt/local"
or things like that.

jsmeix commented at 2021-07-07 06:24:¶

I think the issue is sufficiently answered.

[Export of Github issue for rear/rear.]

#2638 Issue closed: diskrestore.sh fails on already used disk (works on empty disk)¶

cvijayvinoth opened issue at 2021-06-22 14:16:¶

jsmeix commented at 2021-06-25 05:53:¶

jsmeix commented at 2021-07-07 06:24:¶

#2638 Issue `closed`: diskrestore.sh fails on already used disk (works on empty disk)¶