I'm using btrfs-sxbackup to create local snapshots. It creates a technical subvolume in /.sxbackup and creates readonly snapshots in its subfolder. All subvolumes are automatically mounted when OS boots, nothing needed to be specified in fstab.

This one time I tried to restore a snapshot:

btrfs subvol snapshot /.sxbackup/sx-20190308-070926-utc /.before-5.0
btrfs subvol set-default /.before-5.0

Upon reboot the technical subvolume /.sxbackup/ is not mounted. Now every time I have to mount it manually.


On BTRFS, subvolumes form the "snapshot barrier." Meaning, when you snapshot a subvolume which contains subvolumes, the nested subvolumes are not included in the snapshot.

But care must be taken when snapshots should be made (nested subvolumes are not part of a snapshot, and as of now, there are no recursive snapshots)... - source https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Nested

If you check your snapshots in /.sxbackup you'll find that none of them contain the .sxbackup subvolume.

To make the snapshots available in a consistent fashion, consider adding a read-only mount-point of the .sxbackup subvolume to some other place on the filesystem. For example:


/dev/sd* /mnt/snapshots btrfs ro,subvol=/.sxbackup 0 0

The above example mounts the .sxbackup subvolume at /mnt/snapshots regardless of which subvolume is the default.

  • I'm starting to think that installing OS to the top-level subvolume was a bad idea – basin Mar 13 '19 at 15:37
  • Yeah... a flat layout provides more flexibility. – Emmanuel Rosa Mar 14 '19 at 4:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.