Snapper v Btrbk v Manual

[jlittle]

Nested snapshots have the... feature ... that they stay where they're nested. If, like me, one mucks about booting into various snapshots to try out stuff, like release upgrades, or to keep an old release for testing, snapper keeps running in only one of the boots. I keep forgetting this.

Would I have trouble if I move the .snapshots subvolumes to follow the booted subvolume?

Sent from my VFD 822 using Tapatalk

[kubicle]

Nested snapshots have the... feature ... that they stay where they're nested. If, like me, one mucks about booting into various snapshots to try out stuff, like release upgrades, or to keep an old release for testing, snapper keeps running in only one of the boots. I keep forgetting this.

Would I have trouble if I move the .snapshots subvolumes to follow the booted subvolume?

Your guess is probably as good as mine

While I can navigate my way around btrfs subvolumes and snapshots, my first experience with running snapper was hours ago...so I'm not at all familiar with snapper's inner workings or configs.

You could try something like this (but I cannot guarantee it'll work as expected):
https://www.reddit.com/r/btrfs/comme...mountpoint_to/

[GreyGeek]

That is an interesting comment in Reddit. The remark that all snapshots are read only is wrong, though. A snapshot is read only ONLY IF one includes the "-r" switch when creating it. Without the "-r" switch the snapshot is read-write.

The necessity to add an entry for /.snapshots/xx/snapshot in fstab to avoid the multiple mirrors syndrome encumbers and complicates things considerably, at least for my 80 year old brain which, admittedly, is not as agile as it used to be. That's why I like to "KISS" it and keep everything hanging off of the <ROOT_FS> and operate in the manual mode.

[kubicle]

That is an interesting comment in Reddit. The remark that all snapshots are read only is wrong, though. A snapshot is read only ONLY IF one includes the "-r" switch when creating it. Without the "-r" switch the snapshot is read-write.

You are right of course. He could have meant to say that snapper's snapshots are created read-only by default (so it says in the manual, already purged snapper, so can't check) when using btrfs, but even if he did, that's poorly worded.

The necessity to add an entry for /.snapshots/xx/snapshot in fstab to avoid the multiple mirrors syndrome encumbers and complicates things considerably, at least for my 80 year old brain which, admittedly, is not as agile as it used to be. That's why I like to "KISS" it and keep everything hanging off of the <ROOT_FS> and operate in the manual mode.

It doesn't say to add individual snapshots (/.snapshots/xx/snapshot) into fstab, just the @/.snapshots subvolume (remember that the individual snapshot subvolumes are nested, they appear automatically if the parent is mounted).

The "multiple mirrors" (if you are referring to the recursivity), would only happen if snapper would keep making snapshots when you boot into a snapshot (from grub...it doesn't, like jlittle mentioned...adding an fstab entry should make creating snapper snapshots possible, even when booted into a snapshot) ...or possibly after an automated snapper rollback (I don't know enough of snapper internals to say how it performs the roll-backs, never done one...never plan to do one ). If I would use snapper, I'd do any rollbacks manually (just to be sure I know what's happening).

[GreyGeek]

I always do manual rollbacks.

Snapper won't roll back any files listed in /etc/snapper/filters/*.txt
It pre-lists /etc/mtab, the mount table, and won't revert changes made to it. That doesn't make any sense to me.
IF I want to roll back to snapshot 2 from snapshot 3 I want 2 in its entirety, not just pieces of it. IF there is something in 3 I want to keep, but roll back everything else, I'd just copy that something to the #2 snapshot and then do the rollback.

That's what I like about my flat system. When I roll @ back to @yyyymmdd I know that I am getting @ just the way it was in every respect, when I made the @yyyymmdd snapshot. Restoring just a thing or two from @yyyymmdd to @ is easy to do as well. Just use mc to browse to @yyyymmdd in the left panel, @ in the right panel, and copy what I want from the left panel to the right panel. I know one can use snapper to rollback (undochange) specific files but I'm getting too old to wrap my brain around snapper.

[kubicle]

It pre-lists /etc/mtab, the mount table, and won't revert changes made to it. That doesn't make any sense to me.

/etc/mtab in a current linux system is a symlink to /proc/self/mounts that lists currently mounted filesystems (/proc is a special virtual filesystem that is generated at boot, and not a part of the physical / filesystem), even with a manual rebase /etc/mtab contents are regenerated at boot. I'm not sure why snapper specifically lists this for exclusion (possibly something to do with how it does the "online" rollbacks or possibly to accommodate "old style" mtab-files [which also don't survive reboots], because reverting list of currently mounted filesystems is not a good idea on a running system...it's not a problem if you rollback "externally", but snapper's rollback tools can also be used "online").

When you see something that doesn't seem to make sense, a good rule of thumb is that there is probably a reason for it being the way it is (in this case it's likely the combination of facts that you *never* need to revert mtab [nor would doing have any effect on a rebooted system, it would have a "new" mtab anyway], and that it is a bad idea to do so on a running system [because mtab is used, for example, when the system unmounts filesystems during shutdown, and not having mtab accurately describing mounted filesystems could cause some of them not being unmounted cleanly before power off]...with symlinked mtab that is not a problem, but some systems might be using traditional mtab files).

IF I want to roll back to snapshot 2 from snapshot 3 I want 2 in its entirety, not just pieces of it. IF there is something in 3 I want to keep, but roll back everything else, I'd just copy that something to the #2 snapshot and then do the rollback.

Sometimes it makes sense to exclude parts from reverting back like /var/log (to see what was wrong and/or keep the logs you have accumulated since the snapshot), or other changes you made to to the filesystem that you know are not a problem. You can get them back by copying, but if you do a lot of rollbacks it might be simpler/quicker to add these to exclusion. It's a nice feature to have, even if you don't use it (or need it).

That's what I like about my flat system. When I roll @ back to @yyyymmdd I know that I am getting @ just the way it was in every respect, when I made the @yyyymmdd snapshot. Restoring just a thing or two from @yyyymmdd to @ is easy to do as well. Just use mc to browse to @yyyymmdd in the left panel, @ in the right panel, and copy what I want from the left panel to the right panel. I know one can use snapper to rollback (undochange) specific files but I'm getting too old to wrap my brain around snapper.

You can do all that with snapper, too. Just by doing the rollbacks manually (and avoid it's automated rollbacks). I also have my own automated system in place, so I don't need snapper, but snapper can also be used as an automated snapshotting tool (even if you don't use it's rollback/recovery tools, and do all that manually). It's snapshots can be used just as well with manual recovery/copy whatever, if you keep in mind the subtle differences between nested/non-nested subvolumes. Like I said, nothing wrong in doing everything manually or with your own automation, but not everyone has the time, motivation or skills to reliably do that, and could use snapper fairly easily. It's not a bad tool (even for advanced users).

[jlittle]

...snapper can also be used as an automated snapshotting tool (even if you don't use it's rollback/recovery tools, and do all that manually)...

When I adopted snapper the rollback/recovery tools were rudimentary, and documented well (as far as I haphazardly found) for single file recovery, so I have been doing "all that manually", as part, or as another dimension, of a menagerie of methods (vim timestamped saves, git, backups to internal hard drive, to external drives, uploads to a VPS, ...). But what sold me on snapper was recovering two files in a couple of months, because they had been automatically snapshotted.

I suppose I could easily cobble together a cron job or a systemd timer to make regular snapshots. But then I'd have to clean them up, keeping some of them with metadata about them, and write a hooks for APT and booting. A point I've made before, that's what snapper is, why reinvent it.

I should do a deeper dive into what snapper does now. Being installed as part of some distros means a lot of users have been testing it for me. Like Fedora 34 using btrfs as its default fs should result in improvements in robustness and performance.

[GreyGeek]

:~$ vdir /etc/mtab
[COLOR=#ff0000][B]l[/B][/COLOR]rwxrwxrwx 1 root root 19 Jan  5  2020 /etc/mtab[COLOR=#ff0000][B] -> [/B][/COLOR]../proc/self/mounts

So much for my "keen powers of observation"...

Now you know why I "KISS" it with a flat snapshot structure.