How to move btrfs subvolumes to another drive

In my system I have 2 ssd drives
120GB for root
240GB for @home and @/cache
I’m afraid that bigger one can die.

How can I check my ssd condition?

Is it possible to connect another disk in usb case, format it as btrfs and rsync data from 240GB to this drive on usb?

Then I would change UUIDs from my old drive to the new one.

Should it work I do I have to do this in a different way?

man smartctl

You could do that, but changing the UUID could be tricky while your old /home is still mounted.

Well, considering that you plan on using btrfs on the target drive, you could use…

btrfs send

… instead. See… :arrow_down:

man btrfs

… for details.

2 Likes

So to do that I could chroot into the system I believe.

I know about its existence but didn’t use it before. Will see if I’ll be able to understand the manual about it :slight_smile:

I’d do it from the live session, but without chrooting, just to be on the safe side. :wink:

It’s not that difficult, and it’s a great feature. :wink:

1 Like

Ok so one more thing

As I said I have two disks
sda - root subvolume
sdb - home and cache subvolumes

I’ve been thinking about moving them to new drive.

Could I just dd sda to new disk?
If yes what bs should be set?

Both are ssd disks with.

I assune that I’ll need to reinstall grub after this action. Am I right?

I prefer not to do system reinstall

I used to post numerous how-to on that topic on the old forum. Maybe care to search there?

1 Like

Ok
I did it.
Little btrfs send and receive
a little work with fstab and grub and it seems that system works

During send and receive process NOCOW attribute disappeared from directories in my home folder.
Don’t know if this is normal.

I know. Remember. You helped me a lot too.

So maybe a little more help.

Now after every reboot when I do:
btrfs subvolume list /
I get:
ID 461 gen 496 top level 5 path @
ID 462 gen 496 top level 5 path @home
ID 463 gen 490 top level 5 path @cache
ID 464 gen 490 top level 461 path var/lib/portables
ID 465 gen 490 top level 461 path var/lib/machines

The first 3 are ok. I created them.
Have no idea what are var/lib… subvolumes
I deleted them but after every reboot something is recreating them.

The last ones are created by systems, you can mostly ignore them. Only when you want to delete @ you will need to delete them first.

Ok but maybe you could tell me.
As I said
I had two disks with subvolumes on them.
I merged everything to one disk without any other changes.

I checked
When I insert (to compute) “old” disks there are no additional subvolumes
When insert new disk new subvolumes are being created.

I didn’t change any system settings during and after whole process

Use btrfs send instead.

Yes. And you may also need to adjust the UUIDs in /etc/fstab and /etc/default/grub, and possibly rebuild your initramfs.


Why did you set the nocow attribute on them in the first place?

I did

I did

nocwo was set to my virtualbox folder. It was long time ago but I red somewhere that cow should be disabled for virtualbox machnines

1 Like

Okay, yes, that makes sense. :wink:

glad to hear that :slight_smile:

Maybe you could tell me solve this puzzle

As I asked above.
What are:
ID 464 gen 490 top level 461 path var/lib/portables
ID 465 gen 490 top level 461 path var/lib/machines

At the source I have only @, @home, @cache

After doing send and receive form source to target I disconnected source disks and connected terget as the main one.
Now whel I list subvolumes I always get those additional two.

So what? Simply ignore them, they are empty.

1 Like

I would ask you one more thing.

In timeshift, I had 3 snapshots
Two scheduled and one created on demand (before system upgrade)
After upgrade, I wanted to delete the third snapshot. I couldn’t because nested snapshots
var/lib/portables
var/lib/machines

What I did:
I mounted subvolume that I wanted to delete to /mnt
from /mnt I deleted subvolumes portables and machines
I unmounted /mnt and then I was able to delete the subvolume created befotre system upgrade.

What I noticed.
After reboot when I do:
sudo btrfs subvolume list /
I don’t have subvolumes
var/lib/portables
var/lib/machines

I checked and in /var/lib there are directories portables and machines
So it seems that everything is exactly like before data migration. I’m happy but I don’t understand what happened. Why after reboot instead of subvolumes now there are directories.

No need to mount them, you can delete nested subvolume if the parent subvolume is mounted.

1 Like

In timeshift I had snapshots:
M - monthly
D - daily
O - on demand

I couldn’t delete O because it had nested subvolumes.
So as I said.

  • I mounted O to /mnt
  • deleted nested subvolumes
  • umounted O
  • deleted O

Should I do it differently?

1 Like

Now I understood. You did it correctly! :+1:
/var/lib/machines is meant to contain virtual machines which you could set nocow or exclude from snapshots because the size.
/var/lib/portables are meant for portable service (simlar to containers), but not yet used AFAIK

And as I said:

I don’t understand what happened.
Before I tried to get rid of portables and machines subvolumes but after reboot system (if I understand correctly systemd) recreated them.

Now, when I deleted them from one of timeshift snapshots, after reboot system didn’t create subvolumes. Now there are directories.
I should (and am) be happy because I like order on my laptop and now I have it. But I like to understand things also. And I don’t understand what happened :slight_smile:

By which command did you delete them? btrfs subvolume delete?

I suspect when you delete the nested subvolumes you don’t have the folders. When systemd nitices that those folders are missing it creates them, in case of btrfs fielsystem it creates subvolumes.

I never really came accross the issue, because I used to create snapshots of @ and then use to mount the snapshot on / by fstab. The snapshot had folders instead of nested subvolumes /var/lib/machines and portables.

I think now we are coming close to answering your question.