BTRFS with snapper/snapper-rollback or rollback through Live USB

General system Community contributions
1

The instructions below are for BTRFS filesystem, snapper usage for snapshots management, and snapper-rollback.
Intended for single disk only which means no RAID instructions.

In the Live USB, do the following:

  • Add subvolume @snapshots to mount.conf
    edit /etc/calamares/modules/mount.conf
    Add these to the end of the file: (Make sure it is written exactly as the already existing mountpoints)
- mountPoint: /.snapshots
subvolume: /@snapshots
  • Change the mountOptions for btrfs compression field from lzo to zstd as per below:
    edit /etc/calamares/modules/fstab.conf
mountOptions:
ssdExtraMountOptions:
	btrfs: compress=zstd

Then install the system, once it’s finished, proceed below:

  • Configuration of snapper and mount point
    It is assumed that the subvolume @ is mounted at root /. It is also assumed that /.snapshots is not mounted and does not exist as folder, this can be ensured by the commands:
    # umount /.snapshots
    # rm -r /.snapshots

  • Then create a new configuration for /. Snapper create-config automatically creates a subvolume .snapshots with the root subvolume @ as its parent, that is not needed for the suggested filesystem layout, and can be deleted.
    # snapper -c root create-config /
    # btrfs subvolume delete /.snapshots
    After deleting the subvolume, recreate the directory /.snapshots.
    # mkdir /.snapshots

  • Now mount @snapshots to /.snapshots. Where # is the BTRFS root partition.
    # mount -o subvol=@snapshots /dev/sda# /.snapshots
    To make this mount permanent, add an entry to your fstab.
    Or if you have an existing fstab entry remount the snapshot subvolume:
    # mount -a
    # chmod 750 /.snapshots/
    Give the folder 750 permissions.
    This will make all snapshots that snapper creates be stored outside of the @ subvolume, so that @ can easily be replaced anytime without losing the snapper snapshots.

  • Restore a snapshot Using snapper-rollback: (Suggested SNAPPER filesystem layout required) Live USB boot not required.
    Find the device used for the root partition through:
    $ mount | grep btrfs
    Configure snapper-rollback
    Edit /etc/snapper-rollback.conf and add to the end of the file:
    dev = /dev/sda#
    Where # is the number of the drive for the root partition
    Then, to rollback, find out which snapshot you want to rollback to (snapper -c root list) and then issue the following command:
    # snapper-rollback #
    Where # is the number of the snapshot you want to rollback to.

6 Likes
2

This is great! Thank you for publishing it here!
It could go to EnOS’ Wiki imho.

1 Like
3

Hope the community likes it :slight_smile:

In case this is useful for the Wiki, feel free to change anyway you want before posting there.
My English sometimes fails on me, maybe it has spelling errors…
It would also be a good idea if someone that has a better understanding about BTRFS to take a look at it and fix eventual technical problems

1 Like
4

I’m sure many will find it very useful as more and more users seem to be installing with BTRFS judging by the number of questions posted on the forum.

I don’t really know what the proper procedure is for publishing a Wiki article but hopefully there will be some feedback from those in charge.

1 Like
5

Thanks for doing this as i think now some others will follow the btrfs trail! Mines working great. :+1:

1 Like
6

Wish I would have had this before I started using snapper last year! A couple of things that I spotted that you may want to consider:

  1. Instead of changing the permissions on the .snapshots directory, you can also add ALLOW_GROUPS="wheel" so that system admins have access.

  2. Have you considered using aur/btrfsmaintenance to automate BTRFS maintenance? I usually enable everything except the trim service/timer (no need when fstrim is already enabled), all default to once a month.

  3. Instead of adding .snapshots to PRUNENAMES in updatedb.conf, I added it to PRUNEPATHS. Is there a practical difference?

Thanks again for this tutorial.

1 Like
7

Thanks for the very comprehensive guide, I too run with btrfs+snapper, but was creating the snapshot subvolume manually during installation, this makes sense, modifying in the calameres itself. Looks like there is an typo in the below part.

# btrfs subvolume snapshot /mnt/@old/.snaphots/#/snapshot /mnt/@
Where # is the number of the snapper snapshot you wish to restore. Your / has now been restored to the previous snapshot.
# mv /mnt/@old/.snapshots /mnt/@/.

should it not be like below.

btrfs subvol snapshot /mnt/@snapshots/#/snapshot/ /mnt/@

1 Like
8

Hello ajgringo619,

Whenever you need to reinstall, this topic will be here, it’s part of the community now :slight_smile:

Hm that would be much easier, this is a optional step by the way, I should have put this info there, will update it
The groups “wheel” would allow all admins to list the snapshots indeed, but not sure if you would be able to browse the directory
Maybe you would still to use sudo?

Yes, I did, but when I considered I found that it wouldn’t be necessary and could lead to balance/scrub/trim/defrag to run while not necessary/expected

Balance: It’s pretty rare to use, based on what I have been reading, can decrease the lifespan of the disk (SSD) considerably, and the use case for a single drive would be just to reducing the amount of allocated but unused (meta)data chunks, so it’s useful for fixing filesystem full issues basically.
Trim: Trim (discard=async) can be enabled in fstab, or Periodic TRIM can be enabled through systemd unit files, so it’s something you do once and that is it
Defrag: Btrfs supports defragmentation through the mount option autodefrag in fstab, also something you do once and that is it
Scrub: Depending on the data usage and disk speed, it could take a long time to finish, I would say that if it runs when you are not expecting, may slow things down, so I choose to run manually, but you can enable the btrfs-scrub@.timer unit for monthly scrubbing the specified mountpoint in case you prefer, or use the aur/btrfsmaintenance also

It does have a pratical difference, because you will have a .snapshots directory for each snapper configuration created
If you are creating snapshots for /home, you will have a /home/.snapshots directory as well, so the PRUNENAMES would also detect that while the PRUNEPATHS wouldn’t, unless you add all the paths there.

9

Hello Skillrex,

It’s actually correct, just double checked

mv /mnt/@ /mnt/@old → we just moved @ to @old
btrfs subvolume snapshot /mnt/@old/.snaphots/#/snapshot /mnt/@ → we are restoring snapshot # from @old and it now becomes /mnt/@

10

My bad, you have clearly mentioned it is for the default calamares layout, got it mixed up with snapper layout.

1 Like
11

ALLOW_GROUPS="wheel" does allow full browsing of the .snapshots directories, although it takes a bit before snapper makes the changes (done via ACLs).

I’ve only had this EOS system up since last month, so I’ve only experienced (1) maintenance run via btrfsmaintenance. But I hardly noticed it, and I have (3) BTRFS partitions: two are SSDs, one is USB; this was also the case with Linux Mint.

12

Does that also allow to create/delete snapshots through snapper-gui-git ?Running as an user

Unfortunately I didn’t test that package yet, but it would be nice to include it in the post above as an option for the users
Can you share your btrfsmaintenance configuration, logs about that maintenance?
Is it possible to disable the balance from it?

13

Each of the difference maintenance options - balance, defrag, scrub, and trim - are all separate systemd services, triggered by timers, none of which are enabled by default. I have all but trim enabled - once per month (the default).

14

Hm, so what is that package doing ?
It’s just enabling the already existing services ?

15

No, the services are its own. Here’s the author’s Github site: https://github.com/kdave/btrfsmaintenance

1 Like
16

Just read the github link and found a few interesting things
As you said, each of the tasks can be turned on/off and configured independently.

  • scrub

Scrub can be cancelled, which means that in case it’s running in the background, and you decide to reboot, it won’t cause problems by interrupting the service while it’s running.

  • balance

My personal understanding about it is that it is more like a fix than a maintenance feature, but as always, I could be wrong about it, so I wouldn’t enable this by default.
But it’s nice to see that this package has it and you can tune it as well.
Not sure what would happen if it’s running in the background and you decide to reboot… Maybe someone with more experience than me in the BTRFS could answer that for us.

  • trim

It’s off by default because of the system fstrim.timer
Also some systems already set discard options in the fstab automatically.
So not sure if I would enable it, maybe just enable the fstrim.timer or discard in fstab would be enough.

  • Defrag

According to that link, defragmentation process does not descend to other mount points and nested subvolumes or snapshots, so you would need to tune it to include everything you want do defrag.
Note that I’m still learning about BTRFS, but based on what I observed so far, some systems (like mine), add the autodefrag option to the fstab automatically while others do not, maybe someone with more experience than me in the BTRFS could answer if it’s a good idea to run both at the same time, or just leave the autodefrag option enabled, or just use this package.

17

The big advantage of that package is the fact that those services can run against all subvolumes as opposed to the included services, many of which need to be started separately for each subvolume. For me, with over 50 subvols, that makes life vastly easier.

1 Like
18

Hm, I never thought about a system with that number of subvolumes…
Can you guys here help me to include that package in the first post here? I don’t have experience with it
Dalto, if you have a few minutes, do you mind in reading the 1st post here, and help us to make it better?
I would like to know your opinion about it, maybe some fixes, maybe add something along with the btrfsmaintenence info?

All suggestions are always welcome

1 Like
19

My first suggestion would be to add some formatting so it isn’t a giant wall of text. :slight_smile:

For example:

  • make the headers larger so it is clear where each piece ends and the next piece starts
  • Indent the text that goes with the bullets to match the bullets
2 Likes
20

I’ll start with that :slight_smile: