BTRFS with ‘/home’ on separate disk

Support
,
1

I have a Manjaro (v23) installation with the following configuration:

  • / mounted on my SSD, which is /dev/sdb3
  • /home mounted on my HDD, which is /dev/sdc1

This way:

sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
sdb 8:16 0 223.6G 0 disk
├─sdb1 8:17 0 1G 0 part /boot/efi
├─sdb2 8:18 0 6G 0 part [SWAP]
└─sdb3 8:19 0 216.6G 0 part /var/log
                                  /var/cache
                                  /swap
                                  /
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part /home

I am using the btrfs file system because I want to take system snapshots using Timeshift. The problem is that, by default, the installation only created the /@ subvolume and others that are inside /:

ID 257 gen 1573 top level 5 path @cache
ID 258 gen 1575 top level 5 path @log
ID 259 gen 1468 top level 5 path @swap
ID 266 gen 1576 top level 5 path @

And this is my /etc/fstab:

UUID=AE59-40E0 /boot/efi vfat umask=0077 0 2
UUID=a6d21c44-0cb4-4d5c-beb2-d0a1adef9dd9 swap swap defaults,noatime 0 0
UUID=a822aa8a-8f97-4b43-afd3-162d5e434822 / btrfs subvol=/@,defaults,discard=async,ssd 0 0
UUID=a822aa8a-8f97-4b43-afd3-162d5e434822 /var/cache btrfs subvol=/@cache,defaults,discard=async,ssd 0 0
UUID=a822aa8a-8f97-4b43-afd3-162d5e434822 /var/log btrfs subvol=/@log,defaults,discard=async,ssd 0 0
UUID=a822aa8a-8f97-4b43-afd3-162d5e434822 /swap btrfs subvol=/@swap,defaults,discard=async,ssd 0 0
UUID=3cb05b51-ade4-4206-bd9b-f221d599b3a3 /home btrfs defaults 0 0
/swap/swapfile swap swap defaults,noatime 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

I would like, for testing, to also take a snapshot of my /home. But it needs the subvolume /@home to be created on /, which, in my case, is another disk.

So, my question is:

  1. How can I do this?
  2. By doing this, would the data saved in /home remain on the HDD or would it be saved on the SSD, along with the installation of /?

I’m new to btrfs, so I was sorry for some hesitation.

Thanks.

1 Like
2

Welcome to the forum! :vulcan_salute:

Well, /home is by default not included in timeshift btrfs snapshots, and for a reason, because if you are going to restore your system from a snapshot, then you don’t want to have missing files (or changes to files) in your /home due to the rollback.

That said, if you do want to include /home in the btrfs snapshots that you make with timeshift, then you’re going to have to make /home a subvolume on the root filesystem. This means creating a new subvolume on the root filesystem, mounting it somewhere — i.e. a temporary mountpoint — and then copying the entire content of /home into this new subvolume, followed by modifying your /etc/fstab to point to the new subvolume instead of the partition on the other drive.

The alternative however is that you simply tell timeshift to make rsync snapshots instead of btrfs snapshots. This will of course be an entirely different methodology, because then you won’t have any copy-on-write snapshots, but physical copies of your initial backup, added with additional copies and hard-links for incremental backups. And in that case, you can easily tell timeshift to include the home directories of the individual user accounts. But then you’ll need a (preferably empty and unmounted but formatted) partition as the target.

But, having your backups stored on the same drive(s) as the rest of your system is pointless, because if that drive fails, then you not only lose your system, but also your backups. Therefore, the best backup strategy is always to put your backups on a drive that is completely separate from your system (with or without /home).

On my system here, I am using btrfs, but not with btrfs subvolumes or snapshots — I was still too unfamiliar with btrfs myself when I installed this system four years ago. Instead, I have a very elaborate partitioning layout, in which all partitions except for swap, /boot and /boot/efi happen to be btrfs, but without using subvolumes. All of that is on an SSD. And then I use a second drive — a spinning HDD — for storing the backups that I make with timeshift, as well as manually made backups — literal copies with preservation of the permissions and file ownership — of my /home.

If you only copy the data, then the originals will still be on the HDD, of course. If you move the data, then it’ll only be on the SSD. You can either way only have one /home, so if the subvolume is mounted as /home, then you’d have to mount the HDD partition elsewhere. Considering that they are all files owned by yourself, you might want to mount it to a folder in your home directory, e.g. /home/thiago/Data.

1 Like
3

Timeshift is too limited. You are looking for snapper solution. This is a CLI (a command line interface) without GUI. If you need GUI to easily manage snapshots on multiple different partitions, btrfs-assistant can help that.

You do not have the subvolume @home.

  1. mount your home partition.
$ sudo mount -o subvol=/ /dev/sdc1 /mnt
$ cd /mnt
  1. Create @home
$ sudo btrfs subvolume create @home
  1. Edit fstab
    Change
UUID=3cb05b51-ade4-4206-bd9b-f221d599b3a3 /home btrfs defaults 0 0

to

UUID=3cb05b51-ade4-4206-bd9b-f221d599b3a3 /home btrfs subvol=/@home 0 0
  1. Go to Manjaro Live to chroot your system, then move your home data to the subvolume @home
2 Likes
4

I think with this configuration and your goals it’s better if you use snapper. Although Timieshift is super easy to use, it is relatively inflexible.
Snapper is a little more complex, but super flexible.

With snapper it is also possible to take snapshots of /home without rolling back /home during a rollback of /. But you have to spend some time with snapper.

P.S. Putting /home on an extra partition is “old fashion”. If you have two devices, a btrfs raid is ideal. Yes, with btrfs you have to rethink. But it’s worth it!

You can find good Information about Btrfs in the wiki

1 Like
5

Timeshift has the option to include home folders, but this is hard coded to reside in the same brtfs filesystem under the @home volume when using btrfs.

I was dealing with brtfs for the first time as well not long ago, and Snapper was a little overwhelming at first. So I found some workarounds to fit my needs, but unfortunately it wasn’t having @home reside on a different btrfs filesystem. RAID was mentioned, but I think it’s safe to say you don’t want to be doing that to your SSD and HDD.

For the sake of simplicity, and if you want to keep using Timeshift, at least for now. Zekso’s instructions tell you how to migrate your home volume. I would make sure Timeshift does not include @home in Settings/Users. Then you can just manage that separately, knowing they aren’t included in your root volume snapshots.

1 Like
6

I would stay away from BTRFS, atleast if you want to use Timeshift and restore your snapshots… You need a diplom to get your system from working again, while on EXT4 is so awesome user friendly.

You can also easily destroy your own BTRFS Snapshots with timeshift, since BTRFS allows booting right into this snapshots and it has no write protection… for me this sounds not reliable.

At least this is just my noob opinion after i saw few month ago a painfull long help topic in this forum about BRTFS Snapshot restoring… i have absolute no idea who wants this? Maybe because BTRFS is so much better than EXT4? I have no idea.

Only 106 Pages long till the Problem could be solved… Ultimate user experience i would say :rofl:

1 Like
7

I agree - now on ext4.

The appeal of BTRFS is the instant snapshot/restore, though in practice I didn’t use it too much.

The idea that you can easily create the snapshots is great - but then setting up to back up those snapshots or import them again is, frankly, just too complicated.

8

Not true. That only applies to btrfs snapshots. If you use rsync snapshots, then /home can be anywhere and anything.

False. btrfs snapshots are only writable when mounted, and only according to the applying permissions. Furthermore, you can easily switch a snapshot into read-only mode (and back again). Read the manual.

For n00bs, yes. btrfs can do a whole lot more than that, but virtually nobody here at the forum knows about that.

2 Likes
9

Since my information’s are only second hand and not first hand experience, im easy to defeated here. They coming from this linked BTRFS Topic above.

I expect that all your infos should be very true, but does it change the difficulty to restore your snapshots, when you using a BTRFS partition?

When i look at this endless Topic, i think the answer should be a clear no… excluded the owner/developer from BTRFS himself and some other crazy Linux Hardcore Veteran Rambo’s like you :wink:

When someone running into a big problem and look for a escape, you want a reliable restore function to get your system running again without much hassle.

But instead you get a additional layer of difficulties and for me it looks like a nightmare that most people would love to evade.

I rough remember few years ago, there was several people hyping BTRFS how much nicer this filesystem should be, and the noobs can finally choose their Snapshot’s from Grub without booting into a Live Boot and restore from there.

Time has gone since then and you can just search the Forum, how many people or noobs? Deleted their Snapshots there by mistake and run into additional issues.

Isn’t BTRFS today the default choosen filesystem when installing Manjaro with calamares? Please God give us strengh :pray:

Together with KDE Preconfig Wayland, the newcomer would have alot of fun, i guess.

10

This is why I cannot emphasize enough that btrfs snapshots are not backups. They are rollback points.

I use btrfs — but as explained higher up, in a different way — but I have set up timeshift to make rsync backups on a physically separate drive, not snapshots. That way, if anything happens to my main drive, I’ll still have my backups.

I don’t think so. There are a couple of distributions — and Manjaro spins — that offer btrfs as the default filesystem, but to the best of my knowledge, the Manjaro ISOs still default to ext4 as the filesystem for your to-be-installed system.

I could be wrong, but I don’t think so. :thinking:

I’m already holding my breath for that one… :slightly_frowning_face: :fearful:

1 Like
11

So i guess, you using BTRFS outside Root. When there is some kind of strengh in relation to a seperate partition, it could total make sense.

When i think around a new filesystem, im always a little bid worried that more bugs or corrupted files can coming from that… but at the end, it depends on the situation and some files are temporary anyways… i would instant replace my nvme gaming EXT4 partition, when i would see the performance is just better with BTRFS.

Example faster reading, smaller files, there are always Pro’s and Con’s right?

I use also rsync on a physically separate drive with timeshift.
But i just included the /home folder (Partition in my case) for my snapshot… im aware this settings comes with a downgrade… because if im going to restore my snap… it should be pretty damn fresh… otherwise i would lose my last changed files.

But how do you make a difference between timeshift snaps and backups? Is there a additional setting, where im not aware of?

Probably it isnt available from the GUI and require CLI?

12 
NAME    FSTYPE MOUNTPOINT
sda            
├─sda1  vfat   /boot/efi
├─sda2  ext4   /boot
├─sda3  btrfs  /
├─sda4  btrfs  /usr
├─sda5  btrfs  /usr/local
├─sda6  btrfs  /opt
├─sda7  btrfs  
├─sda8  btrfs  /srv
├─sda9  btrfs  /home
├─sda10 swap   
└─sda11 btrfs  /var

/dev/sda7 is my old /var partition, which proved too small, so I created a new one at /dev/sda11, and /dev/sda7 is not mounted anymore. It’s only about 3 GiB or so.

btrfs has been around for quite a long time already by now, and it’s very stable.

I don’t think the performance would be better for small files, or for that matter, for gaming.

So do I. But I also make separate, manual copies of my /home.

If you choose the restore function, yes, but rsync snapshots are readable just as other files, and if you mount the volume with the backups, then you can manually copy back parts of the filesystem. I’ve already done that a few times; for instance after having made a typo that messed up my permissions in /etc. So then I copied back the entire /etc from the backup with “cp -RPp”, which preserves ownership and permissions.

Yes, it’s in the configuration section in the timeshift GUI.

1 Like
13

I could of worded that better, but I didn’t say that.

The brtfs option in Timeshift, implies snapshots. And I saw that you brought up Timeshift rsync in your first reply. I liked that it was simple to setup, if he wants to stick with Timeshift. (Though I admit, I hate the thought of rsync pretending to be snapshots, hogging space and taking forever… On a HDD even.)

I was kind of of hoping something from @thiago . I was refraining myself from saying anything with all the btrfs hatred or that it’s too hard.

I remember my first day with btrfs, I was struggling with it until I mounted it without any subvol option. At the time, not even knowing you could mount it more than once. For me, everything clicked when I ls’d that no option mount. (Sounds dumb, but the wikis weren’t as comprehensive as they are now! Umm, yeah… That! :smirk:)

Once you know a couple things, I find btrfs is actually easier. And everything is practically in one place, unlike ext.

14

Off topic

@Kobold and @Ben, I guess you don’t know what features there are.
Just FYI, If you are interested in some features that Btrfs can offer:

  • Compression and deduplication of data help reduce writes on SSDs, improving their lifespan, especially when not using snapshots

  • The checksum function detects random bitflips and bitrots in damaged RAM, CPU cache, cables, mainboard-bus or hard disk. The dmesg log informs you about this. In addition, a app btrfs-desktop-notification-git can notify you automatically, when corrupted data appears.

  • The comparison between two snapshots can show you which data has been changed, deleted or added. I often use this, for example:
    I install any app in my system. If I don’t like the app, I want to delete it completely (including config files, cache and binary files) but don’t know where they are stored. That is why the comparison between the before and after snapshots helps me to identify/find all unnecessary files of the app.
    I use snapper for the comparison tool:

$ sudo snapper -c <name> status <before snapshot>..<after snapshot>
$ sudo snapper -c <name> diff <before snapshot>..<after snapshot>

If these features are not a concern for you or you don’t care about them, a traditional filesystem like Ext4 or XFS is a better choice.

4 Likes
15

But it doesn’t make sense to me. If I’m mounting the subvolume in /mnt, it will be using / (SSD) and not more HDD. I’m right?

1 Like
16

Mounting is not the same thing as storing data. Any directory can be a mountpoint to any volume with a filesystem, regardless of where this volume is physically located — even if it’s on another computer across the network. A mountpoint is merely a directory in your own filesystem that acts as the access point for the other volume.

3 Likes
17

I got it. So I think the @Zesko recommendation could work, even though it’s not practical at all.

1 Like
18

I care alot about the checksum feature!

This one feature alone sounds awesome, but the complicated snapshot restoring is still there or not?

I would love to switch to BTRFS, when i could have the same flawless snapshot restoring experience as with the Timeshift GUI for EXT4.

19

Nothing is stopping you from using rsync snapshots with btrfs. It’s what I do too. :man_shrugging:

When using the rsync method of timeshift, the type of the source and target filesystems doesn’t matter, as long as they both support POSIX hard-links, file ownership and permissions.

20

And there is no drawback, when i still use my /home partition and and adjust timeshift to backup root and home partition in my snapshots?