RE: rollback to a snapshot

[Nicholas D Steeves <nsteeves@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4232 bytes --]

Bernd Lentes <bernd.lentes@helmholtz-muenchen.de> writes:

>>-----Original Message-----
>>From: Phillip Susi <phill@thesusis.net>
>>Sent: Wednesday, June 7, 2023 10:09 PM
>>To: Bernd Lentes <bernd.lentes@helmholtz-muenchen.de>
>>Cc: Andrei Borzenkov <arvidjaar@gmail.com>; linux-btrfs@vger.kernel.org
>>Subject: Re: rollback to a snapshot
>
>>The last time I installed Ubuntu on btrfs, the installer automatically created a
>>top level subvolume named @ and actually installed the system in that
>>subvolume, then configured grub to tell the kernel to mount the root btrfs
>>volume with the flag subvol="@" so that the system would boot normally.
>>Then you just mount the real root of the filesystem somewhere else and make
>>a snapshot of the @ subvolume.  When you want to roll back, you just rename
>>@ to something else, and either rename or create a new writable snapshot
>>from your previous snapshot and name it @, then reboot.
>
> Do you remember which version it was ?
> You say " top level subvolume named @". You mean subvolid 5 ?
> " Then you just mount the real root of the filesystem". What do you mean by "real root" ?
> Does the subvolume @ already contain files or is it just a container for another subvolume ?
> "you just rename @ to something else". How can i rename a subvolume ? Just rename the corresponding directory ?
> " Then you just mount the real root of the filesystem somewhere else" Why ? With a bind mount ?
>
> Bernd

If I remember correctly, Ubuntu looks something like this

sudo btrfs sub list / -t
ID      gen     top level       path
--      ---     ---------       ----
347     477642  5               @
348     476215  5               @home

which is

subvolid=5
         |_ @
         |_ @home

and you shared this info in the initial thread:

> root@Microknoppix:/home/knoppix# mount|grep btrfs
> /dev/mapper/ubuntu--vg-ubuntu--lv on /mnt/btrfs type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)

> root@Microknoppix:/home/knoppix# btrfs sub list /mnt/btrfs
> ID 430 gen 1215864 top level 5 path .snapshots
> ID 434 gen 1213568 top level 430 path .snapshots/06-06-2023--15:16_PRE_UPGRADE
> ID 435 gen 1216086 top level 430 path .snapshots/06-06-2023
> I want to go back to ID 434 or 435.

So you have something like
1. subvolid=5
2.          |_ @
3.          |_ @home
4.          |_ snapshots
5.                     |_ 06-06-2023--15:16_PRE_UPGRADE
6.                     |_ 06-06-2023

subvolid=5 is always the "real root" I think Andrei Borzenkov is calling
it to mitigate the confusion resulting from potentially having used the
default subvolume feature, which in my opinion should never be used,
because it will confuse the bootloader.  A default Ubuntu installation
will have "subvol=@" in the bootloader, which means all that you need to
do is move your snapshot into place (position #2 in the above table)

So I think you're going to do something like the following: Mount the
true / (position #1) or subvolid=5 to /mnt/btrfs, then

  cd /mnt/btrfs/snapshots
  btrfs sub snap -r ../@ ./@_broken-upgrade  # note readonly "-r"
  cd ..
  # I still do a subvol sync and fi sync here
  btrfs sub del -c ./@
  # I still do a subvol sync and fi sync here
  btrfs sub snap ./snapshots/06-06-2023--15:16_PRE_UPGRADE ./@
  #             /\ note no readonly "-r"

If you stuck with Ubuntu defaults and didn't use the default subvolume
feature, then subvol=@ is still what grub will boot, and
06-06-2023--15:16_PRE_UPGRADE is now the new writable @.

I believe this is the safest method available.  The perfect snapshotting
tool would make it easier to see the relationship between snapshoted
copies of subvolumes.

Note that rootfs rollbacks won't fix potentially incompatibly upgraded
databases in @home (is that rare these days?).  There's not really any
good fix for that, other than to restore them from backup.  Note that
with this method you will lose a day's worth of everything in @ that
didn't have its own subvolume (ie logs, any VMs not in @home, etc).

For the record: If you consult the table above, the default subvolume
feature makes any subvolume become the user-apparent / of the
filesystem, and hides anything that's not beneath its tree.

'hope this helps,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]