Custom subvolume layout for Snapper

just asking @dalto 's opinion about this:

just did a recovery of root and home. the root filesystem I did by garuda assistant. the home subvolume I did by hand in a terminal.

i was wondering if it wouldn't be easier and safer to have instead the following scheme: ( example, the name of the snapshot folder is unimportant )

  • root = @ , root snapshots in @.snapshots ( and add fstab entry to mount @.snapshots into @/.snapshots )
  • home = @home, home snapshots in @home.snapshots ( and add fstab entry to mount @home.snapshots into @home/.snapshots )

then the backup would be a simple move and btrfs sub snapshot into the right place ( no need to mv .snapshots ).

this is just asking for opinion ( is there a downside to this method i mention that i am unaware? ).... the current method works very well and doesn't need the etc entries, so has that advantage.

The downside is that it relies on a specific naming scheme and requires the end-user to understand that scheme.

One of my goals when building this is that it should work with any subvolume no matter what it was named. If I create a subvolume called "bob" and create a snapper config for it, it should just work. It shouldn't require me to know that I also need to create a "bob.snapshots" and then add an additional entry to /etc/fstab. Further, what happens if you rename "@" to "monkey". How would you then know that the snapshots in "@.snapshots" need to be restored to "monkey"?

The current system handles all that transparently.

4 Likes

true ! I understand. I guess if its something I know about and manage carefully, its no big deal. But if its something created by the GUI for a lot of users who might start messing, it would be trouble !

Thanks for your answer !!

@dalto btw ... i just figured it the hard way ( glad that I still had the restore folder ).

If there are some subvolumes under the root or home ( in my case home, which i did manually ), those will get lost.

its easy to fix manually by btrfs sub list . (-o) and moving the found subvolumes, but maybe its something to take notice to the user ?

( edit: just to make evident that this would also happen with the method i presented above, nothing to do with that )

Hmm...since neither I nor Garuda uses nested subvolumes I didn't consider that case. That is probably a bug which should be fixed.

1 Like

You have lot's of free space. Did you overbuy?

I take that as a personal failure when I was testing. Although I don't use much nested subvolumes ( prefer flat + mounting structure ), I do sometimes have to do it to skip backup and snapshots ( things like temp or cache ).

Sorry, should have tested better !

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.