I think they are excluded. Snapper works, like btrfs only on the same btrfs partition. But i think if another btrfs partition is present snapper should capable to make snapshots of it into this other partition, but not across partitions. The same “limitation” as with btrfs it self.
My mounts on /media of ext4,ntrfs partitions are’nt snapshotted within @ → ‘/’, logical.
And now, just try it, you can make snapshots and rollback it. testing some things and showing what happend is now easy 
Yeahh the rolebacks are super nice. Already did my first one. Only thing I have to get going is the systemd setup.
When I have time I want to setup a system where with one command in my main distro it will select the snapshot to revert to, boot into a secondary os, do the rollback, and then automatically reboot into the main os without intervention.
@Hagen I’ve read this entire thread with great interest as I’m considering using BTRFS for my Manjaro installation using the subvolume layout and snapshot/backup strategy that you suggest. One question I have is that on this machine I may want to play with libvirt and docker. What would be the best way of dealing with their default data locations /var/lib/libvirt and /var/lib/docker, respectively, within the context of the /usr/var/lib bind mount suggested? I expect that I would want +C attr for both of these locations. Thanks.
I dont know it 
It depends on what docker is using these folders and because i never used docker in the past i can’t realy help you, based on real expiriences.
The bind-mount to /usr/var/lib use the same BTRFS configuration a on / → @. Thus normaly not +C attr set.
The problem is that we want to separate some stuff into /var to different places. We can go like OpenSUSE old style and use many individual SubVolumes to split out /var/lib. Or we go my way and exclude anything from /var into a @var Subvolume and then include only what must be included into our root snapshots, eg. a bind-mount of copied content of original /var/lib to /usr/var/lib. I’m not such as expieriemced to say thats the right way of doing this. I can only say: on may setup it’s working, because i tested it without this hack, eg. only @var → /var SubVolume and this don’t work correctly.
I see potentialy three ways.
In FSTAB mount @ → /, @home → /home, @var → /var, bind-mount /usr/var/lib → /var/lib, and finally @docker → /var/lib/docker.
In FSTAB mount @ → /, @home → /home, @var → /var, @docker → /usr/var/lib/docker, and finally bind-mount /usr/var/lib → /var/lib.
In FSTAB mount @ → /, @home → /home, @var → /var, @docker → /var/lib/docker, and finally /usr/var/lib → /var/lib.
Some cases depends on how fstab is executed (sequentially or not). The last case depends on if a mounted BTRFS subvolume supercedes a bind-mount. I don’t knew it, you have to test it and made you choice.
Why can Garuda, which is also Arch based, use BTRFS as the default but Manjaro cannot?
I finally got around to documenting my installation. I’ll step through the main setup and highlight key changes that I have made from your above posts regarding installation.
I used Manjaro Architect to install the base OS. Key installation related items:
@ → /@home → /home@cache → /var/cache (note that this had to be manually added to /etc/fstab)Post-installation, I set up Snapper the same was you recommended above: delete Snapper .snapshots subvolumes under @ and @home, replace with directory, create @snapshots root subvolume with @snapshots/root and @snapshots/home subvolumes mounted to /.snapshots and /home/.snapshots, respectively. I also installed snap-pac and snap-sync.
For grub-btrfs, I discovered a reasonably elegant way to work with read-only snapshots without requiring /var to be writeable on the filesystem. It uses the overlayfs hook as per instructions at grub-btrfs github. From the repo:
Booting on a snapshot in read-only mode can be tricky.
An elegant way is to boot this snapshot using overlayfs (included in the kernel ≥ 3.18).Using overlayfs, the booted snapshot will behave like a live-cd in non-persistent mode.
The snapshot will not be modified, the system will be able to boot correctly, because a writeable folder will be included in the ram.
(no more problems due to/varnot open for writing)Any changes in this system thus started will be lost when the system is rebooted/shutdown.
wget https://github.com/Antynea/grub-btrfs/raw/master/initramfs/Arch%20Linux/overlay_snap_ro-hook
wget https://github.com/Antynea/grub-btrfs/raw/master/initramfs/Arch%20Linux/overlay_snap_ro-install
mv overlay_snap_ro-hook /etc/initcpio/hooks/grub-btrfs-overlayfs
mv overlay_snap_ro-install /etc/initcpio/install/grub-btrfs-overlayfs
Re-generate initramfs:
mkinitcpio -P
With this, I realize I’m likely resulting in a bit of write amplification on /var since it’s part of the COW root filesystem, but I like that its all contained and issues with booting into the DE are resolved by having a writeable upper dir in the overlayfs.
I’ve tested out rebooting into snapshots and it seems to work flawlessly. Thanks a lot for the wealth of information in this thread for me to have built on.
As an aside, I haven’t yet gotten around to needing Docker or libvirt on this machine, but when I do, I’ll just create systemd mount definitions for their respective subvolumes to ensure that their mounted prior to those services starting. This isn’t a huge priority right now.
Way too complicated for me to understand. Now that I understand that BTRFS is an upcoming but better technology, I can just hope it will implemented sooner rather than later.
@Hagen, thanks for your contribution to this fascinating thread, I have also read this related one from Manjaro Forum:
default-btrfs-mount-options-and-subvolume-layout/43250)I am no stranger to Linux, having run it as my main OS on my desktop for 20 years (starting out with Mandrake/Mandriva, then Ubuntu), and quite happy to use the command line. However, I got tired of the fixed/timed release model and wanted to try a rolling release model, and have been on Manjaro for just over 4 weeks now, and very happy!
Now I want to try something new: btrfs
My question: I don’t want snapshotting for my home subvolume as I run various VMs, and for a variety of other reasons. However, it would be useful to have snapshotting on the Documents subfolder of my home directory, i.e. $HOME/Documents. So how best to implement this? I am looking to have a single btrfs partition on my drive (plus a small EFI partition for the bootloader), and do the rest with btrfs subvolumes.
@Documents subvolume in a flat layout? OR@Documents in hierarchical manner as child of @home?For (1) I could also mount this in a different place and then bind-mount to$HOME/Documents, similar to your solution for /var/lib. For (2) it could be mounted directly in place.
The point is that $HOME should NOT be COW, but $HOME/Documents should be COW, and I don’t know how the inheritance of the +C attribute works. I have literally zero experience with btrfs and aside from reading this and the referenced thread, and the ArchWiki entry on btrfs, as well as some man pages, have never actually used it myself. So your advice would be appreciated 
Replying to self here: having read up a bit more about this, am I understanding the following correctly?
With the following layout:
@ -> /
@home -> /home
@home/user/Documents -> /home/user/Documents
If I mount @ in fstab with compression and COW, and mount @home in fstab with nodatacow, then do I understand it correctly that @home/user/Documents will automatically appear in the correct place and does not have to be explicitly mounted?
Also, I understand from the docs that it is not possible to change the btrfs specific mount options for subvolumes, so if @home is mounted nodatacow it is not possible to mount the documents subvolume with datacow.
If a btrfs volume is mounted with nodatacow, do the associated files and directories automatically have the +C attribute set, or is this handled at the mount level for the whole volume? Why I’m asking: would it be possible to get COW for @home/user/Documents by removing the attribute with chattr -C Documents before populating the directory with files?
If none of the above is possible, then I understand the only way to achieve this is with a flat subvolume layout and bind mounts:
@ -> /
@home -> /home
@documents -> /mnt/Documents (or wherever in the FS hierarchy you want to mount it, just not under /home)
and then bind mount /mnt/Documents to /home/user/Documents in fstab?
Apologies for all the questions, but from reading the various docs there are so many different ways of implementing this, that it is quite confusing to a btrfs newcomer like myself.
Yes, i think your way is good for a multi user environment. The Subvolume @home/user/Documents is then excluded from a subvolume @home. Means any snapshot taken from @home dont include @home/user/Documents. Now you have to configure Snapper and/or Timeshift with this @home/user/Documents. Contrary to my setup above described, you dont configure @home snapshots in Snapper instead @home/user/Documents for each user.
@Hagen just wanted to let you know that the effort you have put into this thread is still greatly appreciated. Keep going back to it as a reference 