#1095 Issue `closed`: Rear recover doesn't work with SLES 12 SP1 btrfs subvolume¶

Labels: support / question, fixed / solved / done

vishualways opened issue at 2016-12-01 13:08:¶

Relax-and-Recover (rear) Issue Template¶

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

rear version (/usr/sbin/rear -V): 1.19
OS version (cat /etc/rear/os.conf or lsb_release -a): SLES 12 SP1

Could you please let us know what can we do to get this working on SLES12 SP1? is there any specific patch or update need to be installed? We are stuck on a project where acceptable DR process needs to be hand over. if there is a workaround then kindly let us know.

Thanking in advance.
Vish

jsmeix commented at 2016-12-01 14:09:¶

Regardless of "quick response is not guaranteed with free support"
you ask for urgent help but think I have time to manually pull out
information from your file that does not "just display" in my browser
(I will of course not download foreign data).

Just write the basics as plain text here and I may have a look
when I have time.

In case of real urgency use the official SUSE support contact
according to your SUSE Linux Enterprise support contract.

vishualways commented at 2016-12-01 14:52:¶

I mean 'urgency' is at our end so please see if you can help us in getting this resolved. I came across some patch you have released but it seems currently its not in the download archive unless I am seeing it somethign different completely.
once again Thanks a lot for looking into it.
Vish

vishualways commented at 2016-12-01 16:23:¶

Hi, I will need help in fidning any workaround to get this working on SLES 12 SP1. Could you please review below log files while recovering through rear image? Your help would be much appreciable. Thanks and regards,Vish

rear-ulvwasaw01.txt

rear-sles12_test.txt -----> this is after trying snapper and try to recover the image but still failed

gozora commented at 2016-12-01 16:43:¶

Yes, agree that it failed, but this time it failed with:
+++ btrfs subvolume set-default /mnt/local/home
Try to manually enable snapper for each LVM lvol with BTRFS like:

snapper -c home create-config /home
snapper -c opt create-config /opt
snapper -c perflog create-config /perflog
...

snapper create
rear mkrescue

Let me warn you about possible implications though, guys in SuSE certainly had a reason for not enabling snapper for small partitions by default.

vishualways commented at 2016-12-01 17:25:¶

@gozora, Yes we tried this solution from - https://github.com/rear/rear/issues/1036 - by enabling snapper for each LVM vol and then ran it and as you can see it ( test VM log) progressed from stopping at lvroot and then stuck in lvhome. Just wondering if we are missing anything in base OS, which is needed to complete BMR recovery.
Thanks a lot for coming back to me, I will try again on a new VM tomorrow and keep you posted

gozora commented at 2016-12-01 17:46:¶

Whether you are missing something in base OS or not, is something I can't answer.
You can setup Linux in many ways, and in general there are no rights or wrongs (only bigger or smaller compromises).

I for example consider using btrfs on top of LVM as useless redundancy. Yes it works, but IMHO it just introduces another layer of complexity. see RFC: 1925 point 3

vishualways commented at 2016-12-02 14:37:¶

@gozora We had ran this using snapper for each FS/vol as attached in here. I have attached the log for your analysis and error is still same where it stuck in mounting /home while recovering.

+++ btrfs subvolume set-default /mnt/local/home
btrfs subvolume set-default: too few arguments
usage: btrfs subvolume set-default  

    Set the default subvolume of a filesystem

2016-11-18 12:01:11 An error occurred during layout recreation.

rear_manualsetup-119.txt
rear-sles12_test.txt

jsmeix commented at 2016-12-02 15:40:¶

Ahh!
First plain text error message here that I can "just read".

The error message in the above
https://github.com/rear/rear/issues/1095#issuecomment-264467678
is the same as in
https://github.com/rear/rear/issues/1057#issuecomment-260920515

In both cases the partitioning and filesystems layout
is rather complicated.

Unfortunately in both cases I have currently no time
to dig into that (on a voluntary base - of course when
you pay SUSE for official support, things change ;-)
see also
http://relax-and-recover.org/support/

In general:

When one likes to use ReaR for disaster recovery
one must set up the system in a way that is supported
by the current ReaR code - or one must adapt and
enhance the ReaR scripts to make it work for one's
particular use case.

One can set up a system in zillions of ways
where one gets into trouble with ReaR.

Regarding "VM" in
https://github.com/rear/rear/issues/1095#issuecomment-264236824

In particular on virtual machines I do not understand
why to use such a complicated setup, cf.
https://github.com/rear/rear/issues/1057#issuecomment-259640399

For example on KVM/QEMU with the qcow2
file type for the virtual disk images one can specify
e.g. a 2TB virtual disk size to have more than enough space
but on the host system the qcow2 virtual disk image file
will only be as big as the actually used space on the
virtual disk.

I wonder about all that complicated stuff with
tons of virtual disks and tons of partitions
plus LVM on top of them plus several btrfs
filesystems on top of LVM that becomes
a monstrosity from my point of view.

At least I currently fail to understand
what the real advantage of all that
could be on a virtual machine?

In general see
https://en.opensuse.org/SDB:Disaster_Recovery

In particular therein see the sections
about "Inappropriate expectations" and the
subsequent "Recommendations".

jsmeix commented at 2017-01-18 13:03:¶

The error message in the above
https://github.com/rear/rear/issues/1095#issuecomment-264467678
is the same as in
https://github.com/rear/rear/issues/1036#issuecomment-273049971
so that this issue is a duplicate of
https://github.com/rear/rear/issues/1036

jsmeix commented at 2017-11-28 11:32:¶

Also this issue should be fixed as described in
https://github.com/rear/rear/issues/1036#issuecomment-319049462

[Export of Github issue for rear/rear.]

#1095 Issue closed: Rear recover doesn't work with SLES 12 SP1 btrfs subvolume¶