Not new and not recommended
I think I tested it over a year ago.
I just wanted to show that itâs possible and probably not dangerous if it isnât your boot device.
Iâm old, everything after sliced bread is recent.
I thought I read something at least 2020ish that thereâs another push on native encryption, put at the same layer as compression. But it itâs also possible my brain made that up.
I didnât follow development recently
I tested transparent encryption on ext4 and itâs really a cool feature.
You can easily encrypt your /home and decrypt it with your login password, in a similar fashion that Ubuntu did with ecryptfs (but technically, totally different).
Okay⌠Did a reinstall with btrfs and I have sorted compression.
Now how to sort the whole snapshot / backup situation. Wonder if the easiest is to install Snapper for local snapshots and use Timeshift for external HDD backup?
Ah. Missed that snapshots doesnât work on separate /home partitions anyway, so btrfs is pointless for me other than for compression purposes since I refuse to risk my data by not having a separate /home drive (My / is on an SSD, my /home is on my HDD).
Just to inject an alternative here - I have found that the /home does not need to be separate anymore - just donât keep the data in it! I have a data drive (mounted at /mnt/data), with all the usual directories (and more) soft-linked to /home/freebird. On some machines I run ext4 for data (it isnât the default for so many for no reason) and on others I run ZFS for all the benefits of btrfs with even better performance and stability for my data.
Backups I donât do as well as I should, but at least the different machines are rsyncâed regularly, leaving me with multiple copies (but all local )
Anyway - my setup work OK with btrfs doing the âotherâ partitioning, as I use it that way with Garuda. Many of my other systems are running f2fs for rootâŚ
Timeshift refuses and can only work with the system partition (aka / ). It also seems most other tools wonât do it but assumes you have your /home as a subvolume, which I canât really understand how I would set up properly with two different types of drives even if I was to merge partitions.
Edit: With âproperlyâ I mean system files on the faster SSD and media files and documents on the slower HDD and no mixing of the two.
Maybe Snapper then? But all the documentation about that as well only talks about subvolumes which would require a melding of an SSD and an HDD for me which is far from ideal and I might as well just delete the Linux part of the SSD and use it all for Windows C: and just repartition the HDD to host / as well as /home.
You would still have a subvolume for /home. Is there an issue I am not understanding? A subvolume doesnât mean things are combined into a single partition/disk.
/home is on a completely different physical media, formatted as btrfs yes, but not a subvolume as btrfs defines it, itâs mounted by the installer as /home.
It is not @home, as btrfs snapshot demands, as far as I understand it.
It seems btrfs is just too complicated for me to grasp, I guess.
With Red Hat now really pushing BTRFS with Fedora more and more people will probably use it, but not really understand it or use 99% of its features and capabilities. Rendering their âchoiceâ of file system kinda pointless.
Once bitten for me, never again. Do not trust it.
Same here, always have.
/home is just basically a user config location, all my data is stored in multiple encrypted data drives mounted beneath /media. All media is separate also on enterprise grade nas drives. Other systems / distros installed on separate SSD. All VMs on another SSD.
This means the root file system is small, simple to backup and restore if necessary using partclone. I personally hate timeshift, so rigid and limiting.
One day the ultimate ZFS hot swap data rack server will supplant all, assuming I could be bothered. Lockdown apathy is real.
You can create as many subvolumes as you want, name them as you wish and structure them flat or nest them in a tree. So, thereâs a lot of flexibility.
@root and @home is just a convention that many installations create by default and some tools have therefore hardcoded, but thereâs no inherent btrfs meaning. Itâs just easy to grasp whatâs what for the user.
So if you donât have it yet, create a new home subvolume yourself on that home drive and move the files there. Then mount that subvolume to your normal /home mount point.
As I said, this all seems way too complicated for me.
And since only having / as btrfs (like Suse used to do) is pointless for me, as I said my actual SYSTEM is of no consequence for me if it breaks or not (which is a huge part in why i use Arch to begin with, I can play around all day and take 12 minutes and redo the whole / in the evening), I am virtually ONLY interested in backing up /home, I guess I just go back to ext4, btrfs seems to literally not be worth the time learning for a person who uses linux as I do.
Iâm not sure if you need help setting it up, because if thatâs not the case I donât want to argue and convince you of something you donât want to do.
Well, I am not offended, but I think I will revert back to Ext4; it seems, the more I read about Btrfs that it is no longer unreliable, but itâs like Vivaldi (the browser, bear with me): it has 2000 features, of which I wonât ever use any.
I might give it a shot when I get a computer with big enough storage that I can have Linux on itâs own 1-2TB SSD and not have to frakk around with different kinds of media. So in about 10 years when SSD prices have gone down enough