Migrating btrfs @home subvolume to a separate raid disk for /home

[binarydepth]

The installer was crashing with manual partitioning so I made my install on my nvme which is 250 GB in capacity. I use a separate btrfs raid disk for /home. In fstab the home folder has a subvolume and I want to transfer it to the separate disk and fix fstab for it. Help needed

[soundofthunder]

Hi @binarydepth

I’m sure someone will help when they are able.

In the meantime;

Please take some time to familiarise yourself with Forum requirements; in particular, the many ways to use the forum to your benefit:

• How to Post
• How to Request Support
• Forum Rules
• Manjaro Wiki

The Update Announcements should be checked frequently for important update related information.

These announcements contain a Known Issues and Solutions section and should generally be checked before posting a request for support.

Output of the following command formatted according to forum requirements (see links above) may be useful for those wishing to help:

inxi --admin --verbosity=8 --filter --no-host --width

Be prepared to provide more information and outputs from other commands when asked.

Regards.

[Nachlese]

If you tag your post with “btrfs”, at least one of the people here who know btrfs very well will see you post and perhaps be able to assist you.

[megavolt]

@binarydepth

I use a separate btrfs raid disk for /home. In fstab the home folder has a subvolume and I want to transfer it to the separate disk and fix fstab for

So both are BTRFS? Just use this method to copy/move a subvolume:

[HowTo] Copy/Move a subvolume from one partition to another

Difficulty: ★★★☆☆ While there are a some applications, which provide a tooling for doing incremental backups, yet there is no simple tutorial which just explain how to move a subvolume. That is the reason why I try to explain the basic steps here. Preparation Install pv: pamac install pv pv is needed to monitor the progress, when streaming or piping on the terminal, but is rather optional. Switch to root: sudo --shell --user root Set the source and target path: export SOUR…

In /etc/fstab you would just need to change the UUID. Everything else would be the same.

Since BTRFS RAID, you would need to add btrfs to the HOOKS at /etc/minitcpio.conf just before autodetect, so that the RAID devices are scanned very early.

[binarydepth]

In the end instead of deleting it I can mv @home @home_bkp ?

[Nachlese]

no - not with BTRFS - but I know next to nothing about it

probably btrfs send to yet another subvolume

[Molski]

The minimum for this type of help would start with the output of lsblk -f, and the contents of /etc/fstab. (Make sure you paste those here as a code block.)

@binarydepth

I made my install on my nvme which is 250 GB in capacity. I use a separate btrfs raid disk for /home.

Just more questions. The above would help. Is raid a problem in any of this?

@binarydepth

In fstab the home folder has a subvolume and I want to transfer it to the separate disk and fix fstab for it.

To migrate your home. If you have a fresh btrfs file system ready, the simplest method is to just:

• btrfs device add the new one
• btrfs device remove the old
• Modify /etc/fstab

(The data is forced to move to the new drive when you remove it.)

[megavolt]

@binarydepth

In the end instead of deleting it I can mv @home @home_bkp ?

Sure, but it would make no sense to do this on the root partition, since the new mount point is on another partition with the same subvolume. For safety reasons, sure.

[andreas85]

@binarydepth

I use a separate btrfs raid disk for /home.

I do have the complete btrfs filesystem on a (btrfs-)Raid.

You should clarify what type of raid you mean:

• Is it a Btrfs raid, or
• is it a hardware raid, or
• is it an other type of raid

@Molski

To migrate your home. If you have a fresh btrfs file system ready, the simplest method is to just:

• btrfs device add the new one
• btrfs device remove the old
• Modify /etc/fstab

This would not work, because this would transfer a volume (with @home and @) to the new partition (that would need to be unformatted for this scenario). But in this case we want to move only @home, and leave @ where it is. So the way to go is rsync (or anything as good as rsync)

@binarydepth

In fstab the home folder has a subvolume and I want to transfer it to the separate disk and fix fstab for it.

If your home subvolume is already filled with the correct data, it is sufficient to replace the UUID of the desired partition in the fstab.

If the raid-volume is empty, best would be to

• fill it (copy with rsync) with what is in your current @home subvolume.
• change the UUID in fstab
• reboot

If you want more help, post your fstab.

P.S. be aware, that volume and subvolume are special terms of btrfs

You find good Information about Btrfs in the wiki

Btrfs

[Molski]

@andreas85

This would not work, because this would transfer a volume (with @home and @) to the new partition (that would need to be unformatted for this scenario). But in this case we want to move only @home, and leave @ where it is

He has already said home is, or will be on a raid set, so you need two file systems. He has not said in great detail, but most people want a mirror for this. This usually starts with @home having it’s own btrfs file system, (Created home as a JBOD through the installer). So I started at that step. This is the easiest way in this scenario.

But we really do need more information before we attempt more mind reading.

@andreas85

If the raid-volume is empty, best would be to

• fill it (copy with rsync) with what is in your current @home subvolume.

Really? Over, btrfs send’ing the volume?

I wouldn’t doubt that it would be quicker, but more robust (along with everything else)?

[andreas85]

@Molski

Really? Over, btrfs send’ing the volume?

Sending has its advantages (there is no more efficient way to back up a subvolume).

But one disadvantage is that a received subvolume has slightly different values ​​in its UUID pointers than a natively created subvolume. At least that’s what I found when using Send. So you can later determine that it was a backup and where it came from. I’m not sure if that can have an impact later. But I don’t know of any way to undo this difference in the backup subvolume.

And of course sending only works if you really know your way around btrfs paths (So you and me, we can do)

[Molski]

@andreas85

Sending has its advantages (there is no more efficient way to back up a subvolume).

But one disadvantage is that a received subvolume has slightly different values ​​in its UUID pointers than a natively created subvolume. At least that’s what I found when using Send

Since I jumped into btrfs, I’ve used btrfs-send hundreds (thousands?) of times.) @root, @home, or anything. The UUIDs always stay the same. (It’s the parent UUID where I’ve dealt with mismatches, but that will not be used by most btrfs users, or here. And it should be empty on this type of btrfs send.)

The only part I left out is you would have to change the UUID of the old home after, then mount. To be fair, I didn’t want to go too in depth without more information.