On Thursday, 27 July 2023 18:30:11 BST Neil Bothwick wrote: > On Thu, 27 Jul 2023 17:18:14 +0100, Michael wrote: > > Although I've been using btrfs for the best part of 10 years I have not > > really done justice to it, because I have neither explored nor used > > enough most of its features. I am now thinking of installing Gentoo on > > btrfs again, but this time I want to optimise the structure of btrfs > > subvolumes, to simplify snapshots and backups. > > > > I see Ubuntu and derivates install the OS root fs under btrfs subvolume > > "@" and /home under subvolume "@home". This makes storing snapshots of > > the two subvolumes under the btrfs top-volume, which remains unmounted, > > cleaner and reduces the chance of mixing up the fs you may end up in > > and operate on (live, or snapshot). > > > > I have 3 partitions for /boot(ESP), / and /home, but have not yet > > created additional partitions for general data storage and backups. > > > > What's your recommended approach and subvolume structure for the > > deployment of btrfs on Gentoo for a personal PC, if the primary > > objective is simplicity in maintenance, combined with ease of fs > > recovery? > > I too put everything on subvolumes, and set the one containing / to be > the default when mounted without a subvolid.
When you say "everything", do you include temporary and virtual filesystems too (e.g. /sys, /proc/ /tmp, /run), or do you place these in hierarchically lower subvolumes so they are not backed up? Also, how do you treat /var/db and /var/cache/distfiles? How much space do you allocate for snapshots and at what point you start moving/deleting older snapshots? > > Any gotchas I should be mindful of? > > > > Your favoured snapshot/backup strategy? > > I have a script, I can share it with you if you don't criticise my > coding, that creates and destroys snapshots from cron. Based in principle > on zfs-snapshot but written from scratch. Me, criticise anyone's coding?! I couldn't code my way out of a paper bag. :-( Please send over what you have and I'll try to adjust it for my use, or at least I can see what you've written and learn from it. > > The impact of autodefrag on VM performance is noted, but then the > > example given proceeds to mount a subvolume for VM storage with > > 'autodefrag'. :-/ > > I disable COW on the subvolume containing my VM disk volumes. Yes, I've run 'chattr +C' on directories where I store VMs. > > Encryption is mentioned for VMs "... if the VM uses drive encryption, > > the whole compression strategy gets blown out of the water" but doesn't > > mention what type of encryption, or why/how this presents a problem. > > > > Given btrfs does not offer fs level encryption, what could/would work > > to encrypt a subvolume, *without* requiring an initrd, or the > > introduction of encryption becoming orthogonal with snapshots and > > backups? I am not clear on the best strategy and components to achieve > > this. I'm also concerned of introducing an additional complexity layer > > in trying to recover btrfs when/if fs corruption creeps in. > > The lack of encryption is a problem. You have to encrypt the block > device(s) containing btrfs, which means you will need an initrd. It also > means each component of a RAID is encrypted separately. so I only use > encryption on laptops. The alternative is to use ecryptfs for individual > subvolumes or directories. I have one SSD and a larger spinning disk. I have a separate partition on the SSD for /home, so I could put dm-crypt on this partition alone and afford some basic security for personal data against opportunistic theft. No RAID on this box, unless you suggest to create a RAID 1 with two partitions, in case the SSD cells go wrong on one of them? Without RAID things should be simpler with block device level encryption for / home. But, ... will this work without an initrd? The unencrypted rootfs will be mounted before /home. I am also not clear on steps I would need to follow in recovery operation scenarios and what I must have available to achieve this. It is not as simple as booting with any ol' liveUSB to try to access an unecrypted drive/ partition. I'll need dm-crypt and cryptsetup, or ecryptfs-utils and some familiarity with these tools, if I'm not reading off my exceptionally well structured notes I had the premonition to put together BEFORE the drive went south. ;-)
signature.asc
Description: This is a digitally signed message part.
