#556 Issue closed: Implement support for recovery when what is mounted at '/' is a btrfs snapshot subvolume¶
Labels: enhancement, fixed / solved / done
jsmeix opened issue at 2015-03-04 13:57:¶
Currently my code that supports btrfs in rear explicitly excludes support for btrfs snapshot subvolumes. The main reason for this is described in the "btrfs" secion at https://en.opensuse.org/SDB:Disaster_Recovery
Currently SUSE Linux Enterprise 12 is installed by default in a way so that what is mounted at '/' is a "normal" btrfs subvolume (the "/@" subvolume).
For the upcoming first service pack for SUSE Linux Enterprise 12 (i.e. SLE12-SP1) it is currently planned to install it by default in a way so that what is mounted at '/' is a btrfs snapshot subvolume (something like "/.snapshots/1/snapshot").
Therefore I need to enhance my code that supports btrfs for recovery when what is mounted at '/' is a btrfs snapshot subvolume.
This does not mean that I will implement support for any kind of btrfs snapshot subvolumes.
It only means I will enhance my current code so that recovery of all mounted btrfs subvolumes works regardless if there is a normal subvolume mounted or if there is a snapshot subvolume mounted.
In other words: It will be still unsupported to restore all data in all existing btrfs snapshot subvolumes. Only mounted btrfs snapshot subvolumes will become supported.
Background information:
The reason behind the change to install it by default in a way so that what is mounted at '/' is a btrfs snapshot subvolume is the following:
The snapshot subvolumes in "/.snapshots" are controlled by snapper (a tool for filesystem snapshot management, see http://snapper.io).
This change ensures that always what is mounted at '/' is controlled by snapper (i.e. both after booting from a snapshot and also from the very beginning after the initial installation).
This way there is no longer a special difference after the system was booted from a snapshot compared to when the system was booted as it was setup during the initial installation.
In the end this change will ensure that the system works the same even after it was booted from a snapshot.
gdha commented at 2015-03-05 11:27:¶
@jsmeix I assume this is a placeholder - I've put the milestone to 1.18 if that is Ok for you
jsmeix commented at 2015-03-05 12:59:¶
Yes, it is meant for a future rear release after 1.17 and I will implement it (i.e. you could assign it to me if this is o.k. for you).
gdha commented at 2015-03-05 15:26:¶
@jsmeix are you OK with it I grant you the rights inside our master tree?
jsmeix commented at 2015-03-05 15:58:¶
I do very much appreciate your offer but currently I am not a good-enough Git/GitHub user to be sure that I may not accidentally mess up your things.
At least for now - I prefer to learn how to make proper GitHub pull requests and after I got a somewhat experienced Git/GitHub user I might even become rights for your master tree.
In particular for this feature I will have to work separated from rear master with whatever changing beta versions of SLE12-SP1 and do some trial and error work until I learned how to deal correctly with it and then I can actually implement it for rear master - just as I did for the generic btrfs support ( you should be really happy that rear master never got my dirty-hack stuff that only works on SLE12-GA ;-).
For me it is topmost important not to cause regressions in rear master like https://github.com/rear/rear/issues/555 that is a really unfortunate side-effect of my change from "mount" to "findmnt".
schlomo commented at 2015-03-05 16:38:¶
@jsmeix I agree with @gdha and salute your modesty. I'll be happy to give your pull requests and issues a high priority and assist in any way which you need.
jsmeix commented at 2015-03-06 14:03:¶
Likely not yet for rear 1,18 (to be released about June 2015) but for rear 1.19 (to be released about Dec. 2015).
jsmeix commented at 2015-09-10 13:49:¶
FYI some very first information:
I did some reverse-engineering how our installer does the default btrfs setup for SLE12-SP1.
Up to now I found out (by inspecting SLE12-SP1 beta3 installation on a KVM virtual machine) that snapper is now needed (specifically /usr/lib/snapper/installation-helper) in the installation system (inst-sys for our installer and the rear recovery system for rear).
Currently I cannot estimate how long it may take to integrate snapper into the rear recovery system.
Furthermore rear needs support for "chattr" (currently there is none in rear):
Because for SLE12-SP1 some btrfs subvolume directories (/var/lib/pgsql /var/lib/libvirt/images /var/lib/mariadb) have the "no copy on write (C)" file attribute set (via "chattr +C /path/to/directory") chattr support is needed in rear.
jsmeix commented at 2015-10-08 14:23:¶
FYI:
For me the first basic step works (on a KVM/qemu virtual machine) that is:
Recovery of a SLES12-SP1 system with default btrfs structure (but currently without chattr support).
I made my current SLE12-SP1 specific implementation public available in the openSUSE Build Service development project "Archiving" package "rear" at
https://build.opensuse.org/package/show/Archiving/rear
gdha commented at 2015-10-12 12:02:¶
@jsmeix any plans to integrate the patch SLE12-SP1-btrfs.patch (https://build.opensuse.org/package/view_file/Archiving/rear/SLE12-SP1-btrfs.patch?expand=1) into the upstream track?
jsmeix commented at 2015-10-13 07:24:¶
@gdha
yes, but see "Reasoning and background information" in
https://github.com/rear/rear/issues/666#issue-110397975
jsmeix commented at 2015-10-16 11:42:¶
I enhanced my SLE12-SP1-btrfs.patch so that now
on my test system it works for me to recreate
the SLE12-SP1 default btrfs structure
plus
for mounted btrfs subvolumes that have the 'no copy on write'
attribute set those btrfs subvolumes are recreated with that
attribute set (by using 'chattr' on the btrfs subvolume directory).
From my current point of view the issue is hereby fixed
specifically for SUSE.
@gdha
please have a look at my SLE12-SP1-btrfs.patch in OBS project
"Archiving" package "rear" at
https://build.opensuse.org/package/show/Archiving/rear
I tried to implememt it so that it should be backward compatible
(i.e. I think my new stuff should not cause a regression)
but to be really safe this would require testing
(in particular on Red Hat, Fedora, Debian, Ubuntu, ...).
@gdha
if you think it would be o.k. to have my current SUSE-specific
implementation in rear upstream I can of course make a
GitHub pull request.
gdha commented at 2015-10-16 12:59:¶
@jsmeix looks ok to me - just prepare a pull request.
Furthermore, concerning the example config files - perhaps we can add
these under conf/examples/ ? What do you think?
jsmeix commented at 2015-10-16 13:51:¶
O.k. - for next week - I like to do a few more tests.
Have a nice weekend!
jsmeix commented at 2015-11-02 14:45:¶
The issue should be fixed with my above commit https://github.com/rear/rear/commit/307b98c1281c58619d59cb9e6f41863b9278122b
@gdha
is my above commit o.k. for you?
jsmeix commented at 2015-12-02 09:08:¶
I used it many times on my SLES12-SP1 test system
and for me it "just works" so that from my point of view
I can close this issue.
jsmeix commented at 2016-07-28 07:53:¶
It seems that changing btrfs default setup never ends,
see
https://github.com/rear/rear/issues/944
regarding what they changed from SLE12 SP1 to SP2.
vishualways commented at 2016-12-01 13:42:¶
Hi, We are facing similar issue while recovering SLES 12 SP1 (Rear 1.19)
with default btrfs for systemvg. We can backup and create image fine
however during recovering it gives errors. Could you please help us in
overcoming this issue and it has became a kind of show-stopper atm. Is
there a workaround/patch/update to get it working on SLES12 SP1? I have
contacted SLES support and they said they only support REAR on SLES for
SAP version and not the normal SLES.
I am not well-verse with github so please excuse my non-awareness
regarding posts. Your help/advice would be much appreciated.
Thanks and regards,
Vish
We also tried solution given in one of the thread - https://github.com/rear/rear/issues/1036 - we used snapper to get around it however it still failed as in attached rear-sles12-test.log
gozora commented at 2016-12-01 13:56:¶
Hi,
as in attached rear-sles12-test.log
Attached where?
we used snapper to get around it
did you run rear mkrescue and booted from newly created ReaR rescue
system?
What is size of your /dev/mapper/system-lvroot ?
jsmeix commented at 2016-12-01 14:13:¶
@gozora
don't waste your time with that.
@vishualways
cf.
https://github.com/rear/rear/issues/1095
[Export of Github issue for rear/rear.]