snapper as timemachine alternative on Debian GNU/Linux

Posted on do 14 januari 2021 in linux


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


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


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.

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.