I use snapper (an automatic snapshotting tool) with btrfs, and have said here that it suits me well. Others in this forum don't like it, and prefer their own snapshotting set ups. It's very much a SUSE thing, and they're actively working on it.
I struck an issue with the way snapper is set up in systemd in 2018, solved it then, and forgot about it. I've done a fresh install of 20.04 and the issue surfaced again. So, in case someone else tries out snapper, I thought I'd post the fix here.
The problem is that snapper keeps many more timeline snapshots than its configuration tells it, because systemd only runs the snapper cleanup job every 24 hours of run time. IMO the intention was to run it daily, and before systemd a daily cron job was used. But the systemd timer uses run time. I suspend the computer when I'm not using it, and it might take a week for 24 hours of run time to accumulate. My fix is to run
and add the lines
This creates the file /etc/systemd/system/snapper-cleanup.timer.d/override.conf, which overides the settings in /usr/lib/systemd/system/snapper-cleanup.timer.
I struck an issue with the way snapper is set up in systemd in 2018, solved it then, and forgot about it. I've done a fresh install of 20.04 and the issue surfaced again. So, in case someone else tries out snapper, I thought I'd post the fix here.
The problem is that snapper keeps many more timeline snapshots than its configuration tells it, because systemd only runs the snapper cleanup job every 24 hours of run time. IMO the intention was to run it daily, and before systemd a daily cron job was used. But the systemd timer uses run time. I suspend the computer when I'm not using it, and it might take a week for 24 hours of run time to accumulate. My fix is to run
Code:
$ sudo systemctl edit snapper-cleanup.timer
Code:
OnUnitActiveSec= # every four hours, starting at 02:10:00 OnCalendar=*-*-* 02/4:10:00 RandomizedDelaySec=20m