Restoring Btrfs file system fails if a snapshot has been used for rollback

[OliverO2]

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]

@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]

@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]

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