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.
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.