Neither raw disk nor partitions are included into disklayout file

[jakstara]

Hi folks,

I'm struggling to make ReaR works for me because not raw disks nor partitions are included into disklayout.conf file.

My machines are running SUSE SLES 11/12 most common 4.12.14-122.57-default version.

I'll put here some outputs but not sure if they'll be enough for full investigation:

/etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
#BACKUP_OPTIONS="nfsvers=4"
BACKUP_URL=nfs://l0309adm/data/linuxbackup/l0817cus
ONLY_INCLUDE_VG=( 'vg00' )
AUTOEXCLUDE_MULTIPATH=n
BOOT_OVER_SAN=y
BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' /output/\* )

df -h

devtmpfs                    3.9G  8.0K  3.9G   1% /dev
tmpfs                       8.9G     0  8.9G   0% /dev/shm
tmpfs                       3.9G  374M  3.6G  10% /run
tmpfs                       3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/mapper/vg00-lvsysroot  7.8G  5.6G  2.3G  72% /
/dev/mapper/vg00-lvsrv      232M  180K  232M   1% /srv
/dev/sda1                   504M  127M  378M  26% /boot
/dev/mapper/vg00-lvhome     488M   45M  444M  10% /home
/dev/sda2                   512M     0  512M   0% /boot/efi
/dev/mapper/vg00-lvtracker  232M  8.5M  224M   4% /home/tracker
/dev/mapper/vg00-lvdp       232M   63M  169M  28% /dp
/dev/mapper/vg00-lvsupport  976M  2.2M  974M   1% /support
/dev/mapper/vg00-lvkhis     232M  104M  129M  45% /khis
/dev/mapper/vg00-lvsap      961M   93M  869M  10% /usr/sap
/dev/mapper/vg00-lvtmp      2.0G  6.3M  2.0G   1% /tmp
/dev/mapper/vg00-lvopt      5.8G  747M  5.1G  13% /opt
/dev/mapper/vg00-lvvar      2.0G  1.3G  675M  66% /var
/dev/mapper/vg00-lvcups     2.0G  3.1M  2.0G   1% /var/spool/cups

fdisk -l

Disk /dev/sda: 30 GiB, 32212254720 bytes, 62914560 sectors
Disk model: Virtual disk    
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: 0x000d63d2

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1  *       2048  1050623  1048576  512M 83 Linux
/dev/sda2       1052672  2101247  1048576  512M 83 Linux
/dev/sda3       2103296 62914559 60811264   29G 83 Linux

The boot disk is coming from SAN, not locally and we are talking about VMs if that makes sense.

I'm attaching here current disklayout conf file, as well as partition_layout & create_layout scripts.

I'll highly appreciate if someone could refer me to the right point of investigation

200_partition_layout.txt
100_create_layout_file.txt
disklayout.txt

[jsmeix]

@jakstara
what ReaR version do you use?

Missing 'disk' and 'part' entries in disklayout.conf indicate your issue is same as
#2298
which was fixed via
#2299
for ReaR version 2.6, cf.
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
that reads (excerpts)

Version 2.6 (June 2020)
...
    Improved 'is_multipath_path' function to be more fail safe that now tests
    (via "multipath -l" output) if multipath is used ... (issue #2298).

Meanwhile that improved 'is_multipath_path' function was further improved
in our current GitHub master code via
#2708
which is not needed on systems with a few disks
but may somewhat speed up things on systems with many disks (hundreds)
and is likely really useful on systems with very many disks (thousands).

Please test if it works for you when you use
our current ReaR GitHub master code.
See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.

In general when there are issues with ReaR
you should report them via the New Issue button at
https://github.com/rear/rear/issues
that leads you to
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md
where we list what information we need to be able to help.
See also the section
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

In general I recommend to try out our latest GitHub master code
because the GitHub master code is the only place where we fix things
and if there are issues it helps when you use exactly the code
where we could fix things.

In general we at ReaR upstream do not support older ReaR versions.
We at ReaR upstream do not plain reject issues with older ReaR versions
(e.g. we may answer easy to solve questions also for older ReaR versions)
but we do not spend much time on issues with older ReaR versions because
we do not (and cannot) fix issues in released ReaR versions.
Issues in released ReaR versions are not fixed by us (by ReaR upstream).
Issues in released ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported with
reasonable effort) by the Linux distributor wherefrom you got ReaR.

In case of SUSE Linux Enterprise you may contact SUSE directly
provided you have an appropriate support contract.
In this case in particular see also the section
"SUSE support for Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

[jakstara]

Hi,

Thank you for your prompt reply!

I'm using Relax-and-Recover 2.5 / 2019-05-10 version.

Looks like my version has bugs so I'll first try the suggested workarounds and then , in case of need installation of the fixed version.

I'll keep you updated.

[jakstara]

Hello,

I have installed ReaR version 2.6 as advised and it looks like working for disklayout.conf file - the raw disk and its partitions are auto filled there.

However after making backup and testing consecutive restore the error from the screenshot appeared.

Could you advise how it can be fixed since I'm not using multipathing....and is this the real error in general :)

If you need the complete log I can share it with you but for me it looks like no errors were reported during the restore job.

[jsmeix]

@jakstara
I am neither a SAN nor a multipath user
(and I don't have that on my homeoffice laptop - of course)
so I cannot actually help with SAN or multipath specific issues in ReaR.

You wrote "The boot disk is coming from SAN, not locally and we are talking about VMs"
but your 'fdisk -l' output looks as if a single normal local disk /dev/sda was used.
I do not understand that - in particular I do not understand how VMs are related to SAN.

When the system where "rear mkbackup" is run is a VM then only what there is
"inside" that VM matters.
For example when its virtual disk appears in the VM as a normal local disk /dev/sda
then only that matters but the host system where the VM runs on does not matter.
E.g. when a VM with a virtual disk /dev/sda runs on a host system that has its disk via SAN
then the SAN disk does not matter for "rear mkbackup" when it is run in the VM
because from inside the VM only the VM's disk /dev/sda is visible to the kernel
that runs in the VM but this kernel cannot see host system's SAN disk.

Regarding the "rear recover" failure during diskrestore.sh (excerpts):

Creating LVM PV /dev/sda3
lvm pvcreate ... --uuid=XYZ ... /dev/sda3
UUID XYZ ... already in use on /dev/mapper/mpatha-part3

Now it looks as if /dev/sda is a multipath disk (because of the 'mpatha')
but you wrote "I'm not using multipathing" - I do not understand this.

Do you run "rear recover" on an already used disk?
Perhaps on the exact same /dev/sda of the original system where "rear mkbackup" was run?

If yes, see the section
"Prepare replacement hardware for disaster recovery" in
https://en.opensuse.org/SDB:Disaster_Recovery

E.g. when "rear mkbackup" was run on a VM with a virtual /dev/sda disk
then run "rear recover" on another same setup VM with a pristine new virtual /dev/sda disk.

In general see what I wrote above:

Please test if it works for you when you use
our current ReaR GitHub master code.
See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.

In general when there are issues with ReaR
you should report them via the New Issue button at
https://github.com/rear/rear/issues
that leads you to
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md
where we list what information we need to be able to help.
See also the section
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

In particular see the part

To analyze and debug a "rear recover" failure the following information is mandatory

in the section
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery