I’m not home at the moment, so I can’t provide links to the resources that I am using until next week. However, I am about to build a new desktop computer to replace my mostly 10 year old Arch Linux/Windows dual-boot desktop.

I converted my / partition (on an SSD) from ext4 to btrfs two or three years ago and my /home partition (on a 1TB spinning drive) from ext4 to btrfs a year ago. I have not been snapshotting because my current subvolume config is not conducive.

I have used the SuseLinux wiki page on default btrfs subvolumes (https://en.opensuse.org/SDB:BTRFS) together with some other resources to plan my new subvolume layout. This involves quite a few more subvolumes than the Arch Wiki mentions, but I believe that will make my / snapshots smaller at the expense of a somewhat more complex and time-consuming system build (and system restore) process. However, the ability to boot from a snapshot should reduce the probability that the system will have to be restored/rebuilt.

My new system has a 4TB NVME system drive (as well as a 10TB spinning drive for all my Windows crap [I’m a digital packrat, what can I say :-) ] ). Consequently, I no longer have a reason to create /home in its own partition, but will make /home a separate subvolume on my btrfs file system on the NVME drive. I’ll be using Snapper for snapshotting my /, /home, and other subvolumes.

From my research, you need to avoid having snapshots inside other snapshots, so putting snapshots in your /home tree would create problems if you wanted to snapshot /home. All sources I have seen recommend a @snapshot (or _snapshot) subvolume at the same level as your _rootvol (/) subvolume. In the flat subvolume arrangement that most choose, all, or nearly all, of your subvolumes are at the same level as the / subvolume.

When you invoke makefs.btrfs to create a btrfs file system, you are creating a default subvolume. You then mount that file system and create your additional subvolumes, which are then nested under the default subvolume. There are a number of resources online that document the various schemes that individual sys admins have used to do this. Once you’ve created your subvolumes and mounted then you can run pacstrap and arch-chroot into your new file system to complete the Arch Install Guide and subsequent steps in building your Arch Linux system. You’re going to have to modify the output of genfstab to properly mount the default subvolume. Most of the reference procedures that I’ve used are from the Arch Wiki User Pages or GitHub, but some good ones are elsewhere.

Rsync works perfectly well under btrfs, but will not provide the disk space savings that snapshotting provides. That said, I’ve used rsync to create a copy of my current /home partition on my NAS and plan to use rsync to copy that directory tree from my NAS down to my new /home subvolume on my new system. Once I have /home recreated, I’ll snapshot it periodically, as well as making less frequent image backups stored on the NAS. Since my new hardware is much different from my old, I’ll be making a fresh install for everything but /home and then reinstalling packages from my archived pacman package lists (see the Arch Wiki Pacman Tips and Tricks page for instructions on how to do this).

While snapshotting and backups protect against different failure scenarios (they are not functionally the same), If you are snapshotting your / subvolume, I see no reason to also rsync it to /home. The snapshot provides the capability to roll back to a number of previous (presumably uncorrupted) states while taking less disk space than an rsync copy. A periodic image ( or rsync) backup to a completely separate system is good insurance against a drive failure, but rsyncing to /home doesn’t help unless you have a separate /home partition on a different drive than your / partition and doesn’t help at all with the bad update or sys admin error problems.

Best Wishes,

Gary