mount btrfs volume for maintenance?

[jfabernathy]

Following the lead of many in this forum, when I want to do some maintenance on my btrfs partition, I do the follow:

mount /dev/nvme0n1p2 /mnt
ls /mnt
@ @cache @home @log timeshift-btrfs @tmp

Yesterday I watched a video demonstrating manually taking snapshots of a Fedora 37 system prior to an upgrade to 38 and then restoring back to 37, all manually.

However instead of mounting the partition as I showed above he did:

mount -t btrfs -o subvolid=5 /dev/nvme0n1p2 /mnt
​ls /mnt
@ @cache @home @log timeshift-btrfs @tmp

I can see no difference in the results of the 2 commands.

Can anyone see why you'd prefer one over the other??

[Schwarzer Kater]

[…]
Yesterday I watched a video demonstrating manually taking snapshots of a Fedora 37 system prior to an upgrade to 38 and then restoring back to 37, all manually.
[…]

I guess it was Stephen's? I consider him to be one of the few good Linux Youtubers.
https://www.youtube.com/watch?v=K_O4jIpE66o

[jfabernathy]

Yes that was the youtuber. I've watched him for a while now and in the early days I had issues with his mixing different distros way of using snapper. The Arch way differs from OpenSUSE and that differs from Garuda. Very little info on the recommended way for *buntu. I have found the method used by the application btrfs-assistant to be universal if you let it configure snapper it's way.

For Kubuntu or any *buntu the manually method maybe the best given the lack of support from Ubuntu for snapper the way other distros do. As an example, Arch and EndeavourOS support it very well to the point of being about to boot the read-only snapshots and then use btrfs-assistant to restore any root and home snapshot and then rebooting that snapshot as the default. No need to use the install ISO to recover.

I've been playing with that to see if I can break it, but not yet. btrfs-assistant seems to handle the nested snapshots that snapper uses. That is why many do a lot of monkeying around with subvolumes for @snapshots before and after they install snapper.

There is a lot of misinformation on setting up snapper, that seems to stem from which distro the documenter is most familiar with.

The manual method that Stephen talked about is what the experts on this forum recommend to me when I first came here. I still use it in production. It's fun to keep up with the progress of btrfs and snapshots as developers come up with ways to simplify it for the average user.

I have had better luck with Timeshift on *buntu systems. Since I include @home in my snapshots, I can recover from any bad update or install as long as the system is still bootable. I have tried with some success booting a USB stick ISO and from there running timeshift to restore on the SSD. Not always possible, but on Linux Mint 21.1 it seems to be okay.

[oshunluvr]

AFAIK, you only need to add the subvolid if you're mounting other than the default subvolume. Maybe his test system required it. I know I've never had to mount that way.

If you do:

bt su get-default /

you should get:

ID 5 (FS_TREE)

The Arch wiki says:

It is preferable to mount using subvol=/path/to/subvolume, rather than the subvolid, as the subvolid may change when restoring Snapshots, requiring a change of mount configuration, or else the system will not boot.

[jlittle]

The difference is the "default subvolume", as explained by oshunluvr. Some distros use the default subvolume to boot into snapshots painlessly, but on Ubuntu

The btrfs-tools command ''set-default'' will break Ubuntu's layout

I can confirm.

I expect that if some user knows how everything relevant works on Ubuntu, he or she could make it work, but IME it's too easy to make assumptions not considering the changed default subvolume, and there may be such assumptions in Ubuntu-specific scripts, such as that used by a release upgrade.

[jlittle]

mount /dev/nvme0n1p2 /mnt

IMO /mnt is a poor choice for this, as directories in /mnt are typically used for many mounting purposes. For example, in dual booting with Windows one might be advised to mount the Windows storage as /mnt/windows. When I started with btrfs I used /mnt/top, but <heresy alert>reduced this to /top, then to /t, to reduce typing</heresy>.

[jfabernathy]

The difference is the "default subvolume", as explained by oshunluvr. Some distros use the default subvolume to boot into snapshots painlessly, but on Ubuntu

I can confirm.

I think you should never mess with "default subvolume" on Debian based Distros. OpenSUSE seems to do that. That's also why you don't do the "snapper rollback" command on a Debian based system. That's one reason I like the btrfs-assistant utility. It keeps default as default and just moves the subvolume around even if they are nested. I also like the fact that it takes a backup first before restoring even if you think you don't need one.

I have a development system where I expect to screw up almost daily so I stay protected there by using EndeavousOS (archlinux based) with snapper, snap-pac, grub-btrfs, and btrfs-assistant. The snapshots are all read-only so nothing can run loose and write over things and if the system want boot I can boot a snapshot and restore. Even if I have to do it from a recovery ISO.

As to using /mnt. To me that is a temperory use directory. Meaning I mount to it, use it for 5 minutes, and umount it. Since I retired I don't use windows except to let fresh air in .

[jlittle]

... I like the btrfs-assistant utility.

Thank you, I'll check it out.

As to using /mnt. To me that is a temperory use directory. Meaning I mount to it, use it for 5 minutes, and umount it. Since I retired I don't use windows except to let fresh air in .

/mnt/windows was just an example use case, there's many others. I use several subvolumes for various purposes other than snapshots.