Is there an up-to-date list of directories in the root filesystem to exclude from Btrfs snapshots in Arch-Linux?

General system Newbie
1

Hello everyone,

I am new to EndeavourOS and Linux in general. I’ve been reading multiple sources on the web and working to wrap my head around a great many topics. I have a few questions:

  1. The question in the title, is there an up-to-date list of directories in the root filesystem to exclude from Btrfs snapshots in Arch-Linux?

There are multiple sources with differing suggested Btrfs subvolume layouts. I prefer to have a flat layout. The pages at the kernel.org System Admin Guide, linked to from the Btrfs Arch Wiki page, are maked as “Obsolete Content”.

  1. Should I exclude all of /var or do I need to exclude multiple individual sub-directories within /var? If I need to exclude multiple individual sub-directories within /var, then I need a list of the sub-directories? Since the folders within /var can vary based on the packages installed, would excluding just /var cause problems or come with downsides?

  2. If I decide to use snapshots for my user home directories, as insurance against accident file deletion, are there sub-directories that I need to exclude there?

  3. I have a Btrfs layout listed below, that I would like some feed back on. Am I forgetting some exclusions? Am I excluding a folder that should not be excluded?

Background Info:

  • 1x 2TB NVMe, 1x 4TB HDD, 1x 8TB HDD
  • No drive spanning or RAID (not what I’m looking to do at them moment)
  • I want to use Snapper, Btrfs Assistant, Grub, grub-btrfs, and snap-pac (for pre/post snapshots with pacman)
  • I will be using qemu/kvm with virsh and virt-manager (moving away from Virtualbox), but my VM files will reside separately from /var/lib…)
  • I want to use Steam, WINE, Lutris, and maybe Heroic Launcher
  • I may use a few flatpaks (not Steam), but prefer standard packages
  • All video game files will reside on my NVMe separate from my user home folder
  • My data and documents will reside separately outside of my user home folder
  • In general I want to keep the system root filesystem and user home folder lean within sane limitations
  • I currently dual-boot Windows and Linux Mint, but I will be dropping Windows completely, reclaiming the disk space used by Windows, and moving data on NTFS partitions to Btrfs filesystems
  • I will be replacing Linux Mint
  • I am considering dual-booting 2 different Linux distros to separate work from play (something like Fedora/Endeavour, OpenSUSE/Endeavour, Nobara/Endeavour, or another dual setup)
  • Video game files will not be snapshotted (NoCOW)… there are benefits to removing and reinstalling some games after multiple patches (ex: some Blizzard games)

My flat Btrfs layout ideas and naming conventions using EndeavourOS and OpenSUSE:

EndeavourOS setup:

  • top level volume (unnamed and not mounted during normal operation)
  • @eos_root (eos root subvolume mounted at /)
  • @eos_home (eos user home subvolume mounted at /home)
  • @eos_root_snapshots (snapshots subvolume mounted at /.snapshots, must be adjusted after snapper package install)
  • @eos_home_snapshots (arch user home snapshots subvolume mounted at /home/.snapshots)
  • @eos_var (subvolume to exclude from snapper snapshots, mounted at /var)
  • @eos_srv (subvolume to exclude from snapper snapshots, mounted at /srv)
  • @eos_opt (subvolume to exclude from snapper snapshots, mounted at /opt)
  • @eos_tmp (subvolume to exclude from snapper snapshots, mounted at /tmp)
  • @eos_local (subvolume to exclude from snapper snapshots, mounted at /usr/local)
  • @eos_root_user (the root user’s home folder, subvolume to exclude from snapper snapshots, mounted at /root)

OpenSUSE setup:

  • top level volume (unnamed and not mounted during normal operation)
  • @suse_root (suse root subvolume mounted at /)
  • @suse_home (suse user home subvolume mounted at /home)
  • @suse_root_snapshots (snapshots subvolume mounted at /.snapshots, must be adjusted after snapper package install)
  • @suse_home_snapshots (suse user home snapshots subvolume mounted at /home/.snapshots)
  • @suse_var (subvolume to exclude from snapper snapshots, mounted at /var)
  • @suse_srv (subvolume to exclude from snapper snapshots, mounted at /srv)
  • @suse_opt (subvolume to exclude from snapper snapshots, mounted at /opt)
  • @suse_tmp (subvolume to exclude from snapper snapshots, mounted at /tmp)
  • @suse_local (subvolume to exclude from snapper snapshots, mounted at /usr/local)
  • @suse_root_user (the root user’s home folder, subvolume to exclude from snapper snapshots, mounted at /root)

Non-Root Filesystem Data:

  • @mydata = /mnt/mydata
  • @linux_gaming = /mnt/linux_gaming
  • @vm_storage = /mnt/vm_storage

2TB NVME (2TB partition/Btrfs filessystem)

  1. linux_gaming
  2. eos and opensuse

4TB HDD (3TB partition/Btrfs filessystem and a chunk of unallocated space):

  1. vm_storage
  2. 1TB empty unallocated space (not partitioned)

8TB HDD (5TB partition/Btrfs filesystem and a chunk of unallocated space):

  1. mydata and user home subvolumes
  2. 3TB empty unallocated space (not partitioned)

I’m leaving some extra un-partitioned/unallocated space for emergencies and/or experiments I haven’t thought of yet (ex: installing a distro to the bare metal for distro exploration/experimentation outside of a VM).

2

The EOS default is to create subvolumes for /var/cache and /var/log; leave everything else alone (unless you plan on using the default virtual machine directories for QEMU/KVM). One thing that I did differently is not to mount any of the excluded subvolumes, just create them in place.

For example, I have the following subvolumes spanning a couple of disks:

ID	gen	top level	path	
--	---	---------	----	
1640	63430	5		.swap
1592	373289	5		home
1583	373271	1592	home/ajgringo619/.cache
1882	362279	1592	home/ajgringo619/.cargo
1883	373267	1592	home/ajgringo619/.config/vivaldi/Default/File System
1884	373267	1592	home/ajgringo619/.config/vivaldi/Default/Service Worker
1880	373286	592		home/ajgringo619/.config/vivaldi/Default/WebStorage
1588	283928	1592	home/ajgringo619/.local/opt
1589	373289	1592	home/ajgringo619/.local/share/Steam
1881	339294	1592	home/ajgringo619/.rustup
1587	263381	1592	home/ajgringo619/.wine
1582	371408	1592	home/ajgringo619/build
1581	286118	1592	home/ajgringo619/go
1590	373266	5		var/cache
1591	373289	5		var/log

Basically I create subvolumes for any directory that I don’t want backed up offsite. Since I create them in place, I don’t need to mount them, which keeps my /etc/fstab clean.

3

I would recommend excluding /var/cache and ~/.cache from snapshots.

It looks very SuSe-like but Arch is different. Specific comments below.

I would recommend against this if you are planning on using Btrfs Assistant to restore snapshots. It will make your life harder with minimal benefits.

You should definitely not do this. On Arch-based distros, pacman stores data in /var that needs to stay in sync with /.

Arch doesn’t use this for anything, so I am not sure why you would separate it.

I can’t think of any reason you would want /opt separate from /.

By default, /tmp is mounted on a tmpfs so you shouldn’t need this unless you plan to force /tmp to disk.

You 100% don’t need this. It is pointless in all scenarios. Even if you plan to rollback with snapper directly you don’t need this.

Is there a reason you would not want ~/.local in your snapshots of /home? There is no harm in separating them but I don’t see any value in it, personally.

For reference, here is what I usually use:

/
/home
/var/cache
~/.cache
~/Pictures
~/.local/share/Steam
~/Documents
~/Downloads
~/Music

I also keep my VM files separate.

When I multiboot from within a single btrfs partition I also separate some other things so I can share them across my installs. For example, ~/.thunderbird, ~/.mozilla, ~/.steam, etc.

Obviously, everyone will use a different layout and a lot of it is personal preference.

4

Thank you @ajgringo619. I don’t mind if my fstab is a bit verbose. You are advocating for nested subvolumes. When doing a roll back of a broken/erroneous filesystem root, wouldn’t I have to move the nested subvolumes from the broken/erroneous root subvolume to the restored snapshot?

5

Mostly what dalto said. Personally I use a single /mnt/mydata for all the home default folders, and then only separate out ~/Downloads. On top of that:

/home/me/.local/share/Trash
/var/lib/flatpak
/var/lib/systemd/coredump
6

Thank you @dalto. I did take inspiration from several sources including SUSE sources.

I don’t understand how it will make life harder when using rolling back to a previous snapshot with Btrfs Assistant (I haven’t used Btrfs Assistant yet). If I leave the Snapper and Btrfs Assistant defaults they will create nested subvolumes within the filesystem root subvolume. If I roll back a broken/erroneous root filesystem, wouldn’t I need to move the nested subvolumes from the broken/erroneous root subvolume to the restored snapshot? The point of using the flat layout and adjusting Snapper expected subvolumes after Snapper/Btrfs Assistant installation, is to remove the need to move subvolumes after a rollback. Wouldn’t the mounts via the fstab make the subvolumes in the top level available in the expected locations for Snapper and Btrfs Assistant?

The point of snapshotting my user home directories is to have insurance against an accidental file/folder deletion. This would all me to extract such a file/folder from a recent snapshot. I was not my intention to do full rollbacks like one does with the root filesystem.

This idea was borrowed from SUSE or Fedora source. It was not to separate out “~/.local” (hidden within the user home folder) but separating out “/usr/local” which hangs from the root of the filesystem tree.

I was planning on using Thunderbird but moving the ~/.thunderbird folder to a folder within mydata and soft linking to the new location. On Mint, the ~/.steam folder is huge (16-17 GB) even though I’ve pointed the steam library default location to a folder on my NVMe. I’m not sure if moving and soft linking would cause issues.

Thanks @Schlaefer.

7

Yes, this is the best approach when doing restores with Btrfs Assistant. Because Btrfs Assistant uses the nesting to know where to restore the snapshot to.

Btrfs Assistant handles this automatically whenever it is needed.

This sort of true but not exactly. The reason you do this on suse is because they use as a rather interesting approach to root restores there. They don’t actually restore the root subvolume, they change the default btrfs subvolume to the snaphot and make the snapshot writable. So you end up permanently booting off the snapshot once you “restore” a root snapshot.

I didn’t love this approach, so Btrfs Assistant does actual restores where it restores the snapshot to the target subvolume which is the behavior most people would expect.

No, neither use this information.

I totally agree with snapshotting your home directory. But you don’t need this flat subvolume to do that. The logic above only applies to root. Even suse/snapper use the nested subvolumes here.

Adding a flat subvolume here would break restores in Btrfs Assistant and honestly I am not sure if snapper properly supports it either. There is no reason to do this that I can think of.

Sorry, I misread that. Almost nothing uses /usr/local anymore so I suppose it doesn’t hurt anything but I can’t think of any reason it would help either.

You can do it that way but if you are using btrfs it is a lot easier to use subvolumes instead of links. It also provides you with additional options such as the ability to have different snapshot retention periods for different purposes.

I use subvolumes here without issue. Although I don’t do this anymore, I used to multi boot many different distros and you can just mount the same steam subvolumes in all the distros and everything “just works”. I did the same with my thunderbird profile.

Also, I snapshot all my subvolumes except for cache. For me, what differs is the retention rules I apply. For example, the retention on my downloads subvolume may only be 48 hours. But the retention on my documents subvolume could be 2 years.