Bernd Lentes writes: >>-----Original Message----- >>From: Phillip Susi >>Sent: Wednesday, June 7, 2023 10:09 PM >>To: Bernd Lentes >>Cc: Andrei Borzenkov ; 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