#2067 Issue closed: Restoring Btrfs file system fails if a snapshot has been used for rollback¶

Labels: enhancement, bug, cleanup, fixed / solved / done

OliverO2 opened issue at 2019-03-06 12:20:¶

Versions¶

• ReaR version ("/usr/sbin/rear -V"): 2.4
• OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Ubuntu 18.04.2 LTS

Scenario¶

• Configuration:

  • /etc/fstab: UUID=... / btrfs defaults,noatime,subvol=@ 0 1 UUID=... /volumes/01 btrfs defaults,noatime,subvolid=0 0 0

  • Btrfs volume structure: /volumes/01 - Btrfs top-level subvolume (subvolid 5, mountable via subvolid=0) /volumes/01/@ - Btrfs subvolume mounted at /

• Sequence of events:

  1. Prepared an OS release upgrade:
     1. cd /volumes/01
     2. mkdir release-upgrade
     3. btrfs subvolume snapshot @ "release-upgrade/@-$(date -Isecond)-pre-release-upgrade"
  2. Started the OS release upgrade (on Ubuntu do-release-upgrade)
  3. Release upgrade failed
  4. Recovered the previous state:
     1. Booted into recovery mode
     2. Rolled back the root file system (/):
        1. cd /volumes/01
        2. mv @ "release-upgrade/@-$(date -Isecond)-broken-release-upgrade"
        3. btrfs subvolume snapshot release-upgrade/@-*-pre-release-upgrade @
     3. Rebooted

• Consequence: The system now has its root file system on a subvolume named @ which has not been created by btrfs subvolume create but by btrfs subvolume snapshot.

• Trying to recover that system with ReaR produced the following results:

  • ReaR recreated only the original Btrfs subvolume: # btrfs subvol list /mnt/local/volumes/01 ID 257 gen 13 top level 5 path release-upgrade/@-2019-02-09T12:28:54+01:00-broken-18.04

  • ReaR refused to recover the current snapshot subvolume named @, which acted as /.

• In #556, ReaR gained code to handle a similar situation, but this is limited to SLES12.

Background¶

• From Manpage/btrfs-subvolume - btrfs Wiki:

  A snapshot is a subvolume like any other, with given initial content.

• From SysadminGuide - btrfs Wiki:

  A Btrfs filesystem has a default subvolume, which is initially set to be the top-level subvolume and which is mounted if no subvol or subvolid option is specified.

Suggestions¶

• Since the above sequence of events is a perfectly legal way to roll back a system, ReaR should be able to handle such a system later on without extra intervention.

• ReaR should not make assumptions about subvolumes the way it currently does:

  • ReaR should not attribute any meaning to the way a subvolume was created (empty or as a snapshot).
  • ReaR should not attribute any meaning to the default subvolume (it is really just a way to shorten the list of mount options required).

• ReaR should recreate Btrfs subvolumes which are mounted via /etc/fstab. Regardles of whether these were originally empty or started as a snapshot, they can be recreated with btrfs subvolume create and their contents expected to be restored from a backup.

• Hopefully, if we concentrate on recreating mounted Btrfs subvolumes only and ignore everything else, the entire Btrfs recreation code could be greatly simplified. Would this break anything currently useful?

jsmeix commented at 2019-03-07 10:22:¶

@OliverO2
only a short initial notice:

The current btrfs support in ReaR is basically an add-on hack
as needed for SLES and RHEL.
In particular for SLES: ReaR works with the btrfs snapshotting
as it is done there (via snapper).

I think 90% of what can be done individually with btrfs
is currently not supported in ReaR.

Cf. https://github.com/rear/rear/issues/2028 in particular see
https://github.com/rear/rear/issues/2028#issuecomment-463193378
and follow the links therein and see the "FYI" part in
https://github.com/rear/rear/issues/791#issuecomment-406513969

Because of newest storage features in SLES like
https://github.com/rear/rear/issues/2057
we may need to completely overhaul the layout code
rather sonner than later...

jsmeix commented at 2019-03-15 12:59:¶

@OliverO2
I assume since your https://github.com/rear/rear/pull/2079 is merged
this issue was fixed for your use case and I hope it still works for you
since my https://github.com/rear/rear/pull/2080 is merged
so that I can close this issue hereby for now
regardless that btrfs_subvolumes_setup_generic()
needs some enhancements to make it work everywhere, cf.
https://github.com/rear/rear/pull/2080#issuecomment-472448686
and subsequent comments - but that is something for the future.

jsmeix commented at 2019-03-15 13:07:¶

@OliverO2
thank you for continuously testing ReaR on current Ubuntu versions and
for your enhancements that make things work on new Ubuntu versions!

---

[Export of Github issue for rear/rear.]