snapper as time machine alternative on Debian GNU/Linux

Posted on Thu 14 January 2021 in linux

Goals

It must have been a year ago already that I reinstalled my Dell XPS laptop with Debian GNU/Linux. At install time I figured I really wanted to be able to snaphot filesystems, so I made sure I used btrfs as filesystem. Actually doing something with it was put on the 'backlog' uptill now. So it took a while :-)

My goals are twofold: save my actual data and recover easily from software upgrades / system changes gone wrong. Not that I need any of that on a daily / weekly basis, but it would give me some extra piece of mind.

Moving data to separate subvolumes

Reading up on snapshotting btrfs on Debian, I found out that Debian by itself does not ship a lot preconfigured / pretested options. The installer does not yet allow you to install things on btrfs subvolumes. So I have btrfs, but everything is on a single filesystem. I wanted to address that first and after some Internet searching it turned out to be not too hard to fix on an existing system.

At first I tried to mimic the Ubuntu setup in an effort to use apt-btrfs-snaphot as a tool to snapshot the system on package installes / changes. So the layout for now would become:

  • BTRFS filesystem
  • root subvolume @
  • home subvolume @home

This would allow separate snapshots for systemchanges and userdata. The proces was fairly easy as in:

  • create a new subvolume
  • copy all the data using 'cp -ar --reflink=always' option to the new subvolume
  • update /etc/fstab to reflect the new location
  • for the root filesystem: set the default ID for the btrfs volume to use at boot to the new location
btrfs subvolume create /@home
cp -a --reflink=always /home/* /@home/

add line for home to fstab:

/dev/mapper/nvme0n1p6_crypt /               btrfs   defaults,subvol=@        0       0
/dev/mapper/nvme0n1p6_crypt /home            btrfs   defaults,subvol=@home        0       0

(this example already shows both volumes as subvolumes configured)

For the root filesystem, I pointed the default ID from 0 to the newly created subvolume ID for root:

btrfs subvolume set-default  969 /

after succesfully rebooting, I mounted the original volume and removed the data from the old location.

mount -o subvolid=0 /dev/mapper/nvme0n1p6_crypt /mnt/btrfs/
cd /mnt/btrfs 
rm -rf boot/ bin etc dev initrd.img* media/ root/ sbin srv usr vmlinuz* 
rm -rf home/ lib* mnt opt proc/ run/
rm -rf snap/ sys/ tmp/ var/

(yes you better be sure what you are doing. Have backups at hand)

Creating regular snapshots

At first I tried to use apt-btrfs-snapshot but although it figured my system with the @ and @home volumes was 'supported', it would croak with an error. So I searched the web for alternatives and found a tool originating in 2012 called 'snapper'. From the description it seemed to fit my bill and it was available as a Debian package so that made it an extra attrictive alternative to apt-btrfs-snapshot. After installing it took me some time to figure it out, but soon enough I had a separate config setup for my @ and @home subvolumes.

At first I created a snapper config per subvolume

snapper -c root create-config /
snapper -c home create-config /home

Then I edited the timeline parameters for both subvolumes in /etc/snapper/configs/ to manage the way older snapshots are retained or removed.

For @ / root: retain 24 hourly and 14 daily snapshots, delete the rest

TIMELINE_LIMIT_HOURLY="24"
TIMELINE_LIMIT_DAILY="14"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"

For @home: retain 10 hourly, 14 daily, 12 monthly and 10 yearly snapshots, delete the rest

TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="14"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="12"
TIMELINE_LIMIT_YEARLY="10"

The thing lacking right now are a pretty GUI that works to restore files or compare snapshots. Also, I need a hook to create pre and post snapshot running commands like apt-get. There is some GUI but it seems unpolished / outdated. Maybe I will find something better. I do have my snapshots now, making it just as 'safe' as my Mac running Timemachine.

update

The pre and post hooks for apt actions apparently are already been taken care off. Nice one Debian maintainers!

45  | pre    |       | Fri 15 Jan 2021 06:11:53 AM CET | root | number   | apt         |         
46  | post   |    45 | Fri 15 Jan 2021 06:11:56 AM CET | root | number   | apt         |         
47  | pre    |       | Fri 15 Jan 2021 06:11:57 AM CET | root | number   | apt         |         
48  | post   |    47 | Fri 15 Jan 2021 06:11:58 AM CET | root | number   | apt         |         
49  | single |       | Fri 15 Jan 2021 07:00:07 AM CET | root | timeline | timeline    |         
50  | pre    |       | Fri 15 Jan 2021 07:16:03 AM CET | root | number   | apt         |         
51  | post   |    50 | Fri 15 Jan 2021 07:16:07 AM CET | root | number   | apt         |  

Now I will have this running for some time to see how things work out. I might need to created extra subvolumes to exclude some very volatile parts of the data like logging to keep the disk from clogging with irrelant snapshot data. We will see.

References