[FEATURE] Rollback snapper default layout snapshots (e.g. `@home`)

[tkna91]

It would be more useful to be able to rollback the @home subvolume below.

• https://wiki.archlinux.org/title/Snapper#Suggested_filesystem_layout

Is it possible to incorporate the following steps to rollback the home directory?

• https://wiki.archlinux.org/title/Snapper#Restore_snapshot_of_/home_and_others

[jrabinow]

Hey @tkna91, there's no reason for this tool to not enable you to rollback your home directory today [1]. However this setup isn't as pretty as it could be. I'll have to add support for multiple config entries to the tool. I'm afraid it might take a little while but contributions are welcome!

For the time being, I can suggest the following: you'd need to create a new snapper-rollback.conf and enter your home directory details in there. From there, you can call the tool with -c path/to/config option. Reboot, your home directory should have rolled back. The caveat here is that this workaround will only behave as expected if your /home is a separate btrfs partition. If /home is a btrfs subvolume instead of an entirely separate partition, the script would need a few changes.

---

[1] except for the "modify the fstab" part, namely If subvolid was used for the /home mount entry option in fstab, instead of /path/to/subvolume, change subvolid in the fstab to the new subvolid. This script assumes path-based subvolume entries in fstab -> if changes are needed, IMO the user should be doing them manually or rewriting the fstab so that changes aren't needed in the first place.

[tkna91]

I see. In the following, @home is a subvolume, not a separate partition, so someone needs to adapt the script to handle it that way. https://wiki.archlinux.org/title/Snapper#Suggested_filesystem_layout

In addition to that, I am also concerned about the snapshot directory being /@home/.snapshots. Could this also be a problem?

[jrabinow]

so someone needs to adapt the script to handle it that way.

Indeed. Personally I wouldn't advise having home as a subvolume: for example, reinstalling the system, filesystem corruption, multiboot all become (more) problematic. That being said it's a valid usecase. I'm afraid my system is offline at the moment so it'll take me a while to get around to supporting it, but I'll get to it eventually.

the snapshot directory being /@home/.snapshots. Could this also be a problem?

I don't believe so, ~/.snapshots should be its own subvolume in any case so it wouldn't be affected by rollback. But what problems do you foresee?

[tkna91]

Personally I wouldn't advise having home as a subvolume: for example, reinstalling the system, filesystem corruption, multiboot all become (more) problematic.

Indeed, I concur with your perspective. Nonetheless, I regularly synchronize the majority of data from / and /home directories to an external SD card and a backup server using rsync. Moreover, I continuously employ Syncthing for the data within my /home directory. The synchronization target is backed up with Snapper every hour, capturing differential backups. Consequently, this arrangement mitigates the severity of potential issues, such as disk crashes.

In devices with limited SSD capacity, like laptops, managing free space becomes simpler without partition splitting. Thus, I typically utilize a single partition with subvolumes beneath it.

I don't believe so, ~/.snapshots should be its own subvolume in any case so it wouldn't be affected by rollback. But what problems do you foresee?

Indeed, to rephrase your words, in order to support /home with minimal adjustments to the tool, it would be advisable to configure a subvolume for /home/.snapshots employing a layout akin to the one mentioned below.

Filesystem layout	Subvolume	Mountpoint
@	/
@snapshots	/.snapshots
@home	/home
@home_snapshots	/home/.snapshots
@var_log	/var/log

However, Snapper's default layout (without a subvolume for @home/.snapshots) is currently documented in the ArchWiki, and it would be convenient if this could be automated. Since this is the default layout of snapper, it would be helpful to many people regardless of OS if it could be supported.

[jrabinow]

However, Snapper's default layout (without a subvolume for @home/.snapshots) is currently documented in the ArchWiki

It looks like https://wiki.archlinux.org/title/Snapper#Restore_using_the_default_layout is what you're talking about here? I've never used this setup in home so this isn't tested, but what is happening there is actually quite different from the rootfs /.snapshots directory: someone is issuing a move command to move data across subvolumes. This can get iffy quite fast if I setup my system by following my own recipe and have /home/.snapshots as a separate subvolume.

Compared to what this script's intended goal is: recover a borked system while maintaining a clean subvolume system per the archwiki's description here and this /home/.snapshots is a separate setup and usecase.

I won't add support for this usecase myself, but I'll be happy to review PRs. I'd also like to add support for /home/ with /home/.snapshots as a subvolume, once I get some bandwidth.

[tkna91]

It looks like https://wiki.archlinux.org/title/Snapper#Restore_using_the_default_layout is what you're talking about here?

Yes, I wrote that section. I also tested it. There may be a more sophisticated method, but I thought this form seemed more reliable.

I won't add support for this usecase myself, but I'll be happy to review PRs. I'd also like to add support for /home/ with /home/.snapshots as a subvolume, once I get some bandwidth.

Understood. I can't use python properly yet, so I'm hoping for someone who can.

[jrabinow]

Yes, I wrote that section. I also tested it. There may be a more sophisticated method, but I thought this form seemed more reliable.

I'm wondering if consistency with the rootfs system isn't worth pursuing. Moving a .snapshots directory from one btrfs subvolume to another means:

• it's a different approach the user needs to be aware of. Consistency is always nice per principle of least astonishment
• I'm not 100% sure about the following but taking a wild guess here that moving data across BTRFS subvolumes means copying the metadata to the new subvolume, then deleting it on the old (or at the very least updating all the involved filesystem pointers): this approach is more prone to failure. We're talking one directory per snapshot -> doesn't make a difference in most cases. For large amounts of snapshots, this might be more problematic.

If instead, the /home/.snapshots dir was a separate subvolume:

• the mv operation could be replaced with a mount, which means the only bytes being written to disk would be the ones involved in renaming the @home subvolume and creating a single new @home directory. This in turn means that each recovery step is atomic.
• consistency with the rootfs: /.snapshots and /home/.snapshots would work exactly the same way. Once the user knows about one, they'd know about the other.
• as a nice side effect, this script would support this setup once I add support for it

[tkna91]

Indeed, when using mv or cp between subvolumes on a Btrfs filesystem, even though inodes differ, the underlying data is the same due to Btrfs's fundamental features, which alleviates concerns about insufficient space during copying.

https://btrfs.readthedocs.io/en/latest/Reflink.html

Based on inquiries in the #btrfs channel on irc.libera.chat, both mv and cp appear to have Copy-on-Write (CoW) as the default option, as indicated below.

• 5.18 kernel added support for cross-mountpoint reflink
• mv, core-utils since 8.28 and cp defaulting to reflink since 9.0

However, as you mentioned, managing different subvolume layouts and directory structures within the same script can undoubtedly increase complexity. Considering the critical nature of the scenarios being handled, it may indeed be more prudent to keep them separate.

[jrabinow]

which alleviates concerns about insufficient space during copying.

My concern wasn't so much with space, you're right when you say the data itself wouldn't be copied thanks to CoW. The metadata however is a different story. As noted in the link you shared: A reflink will effectively create only a separate metadata pointing to the shared blocks This is similar to when accessing a file in any way, a write goes to disk unless the partition is mounted with -o noatime option. Having a separate subvolume whose mountpoint is changed means that the metadata writes (1 per snapshot directory) could be avoided.

managing different subvolume layouts and directory structures within the same script can undoubtedly increase complexity

Increasing complexity is ok, I would be open to reviewing and accepting PRs as long as the new logic was separated out from the existing logic in a way where things were properly encapsulated.

[tkna91]

Certainly the addition of the following steps means that you are making that change.

mv /mnt/@home-backup/.snapshots /mnt/@home/

When I did it, it took a moment, just like a normal mv, but I don't think there is zero chance (although there may be a small chance) that it will fail due to lack of resources at the time of the change, etc. There may be other advantages, but it is certainly better in the sense that it is less likely to be an accident if that procedure is not used.

[danboid]

I think the OP is pretty much describing the same feature that I would like to see added to snapper-rollback.

My fave Linux distro is SpiralLinux ( https://spirallinux.github.io/ ), which is based upon Debian. I prefer it over normal Debian because it has better BTRFS support than the official Debian installers. SL installs grub-btrfs by default which adds snapper snapshots to your grub boot menu and it also includes snapper-rollback to make rolling back to previous snapshots from the terminal easier.

This is what the default subvolume layout of a SpiralLinux install with a couple of snapper snapshots looks like:

# btrfs su list /
ID 256 gen 297 top level 5 path @
ID 257 gen 263 top level 5 path @snapshots
ID 258 gen 298 top level 5 path @home
ID 259 gen 264 top level 5 path @root
ID 260 gen 284 top level 5 path @var@log
ID 261 gen 267 top level 5 path @var@lib@AccountsService
ID 262 gen 267 top level 5 path @var@lib@blueman
ID 263 gen 298 top level 5 path @tmp
ID 265 gen 280 top level 258 path @home/.snapshots
ID 278 gen 164 top level 265 path @home/.snapshots/1/snapshot
ID 287 gen 260 top level 257 path @snapshots/1/snapshot
ID 288 gen 262 top level 257 path @snapshots/2/snapshot
ID 289 gen 280 top level 265 path @home/.snapshots/2/snapshot

I would like snapper-rollback to have a new option/argument that would allow the user to also restore their @home subvolume, just in case they accidentally nuked their home dir. This would be a non-default, opt in feature for obvious reasons.

Maybe this would only be able to work for those using this exact subvol config but that's OK with me.

The timeshift gui gives BTRFS users the option of easily restoring their @home subvolume at the same time as restoring the root @ subvol so I'm hoping we can basically replicate that functionality in an easy manner with this script.

If we're not asking for the same thing here then I'll create a separate issue for this feature request, presuming snapper-rollback can't already do what I want?

Thanks

[tkna91]

@danboid I am not using snapper as I have already moved to btrbk. So I will not actively participate in this discussion, but if @jrabinow doesn't mind, you can take over. Do as you please.

[danboid]

I have found this guide on how to rollback snapper @home snapshots under Arch and I'd imagine its pretty much exactly the same process to do it with SpiralLinux / Debian

https://wiki.archlinux.org/title/snapper#Restore_using_the_default_layout

Its quite tricky so it would be handy to have a script to help automate it.

SpiralLinux uses the same subvolume layout as is recommended for use with snapper on the Arch wiki.

I have created a ticket with SpiralLinux to suggest that we try to get the @home subvol rollback process documented, or at least link to that guide on the Arch wiki.

https://github.com/SpiralLinux/SpiralLinux-project/issues/441

[danboid]

The "Snapshots for the /home subvolume" section of this guide describes how to rollback @home subvolumes under Debian:

https://github.com/david-cortes/snapper-in-debian-guide