7

I have a btrfs partition on a drive which I would like to move to a new bigger drive. I would like to move the volume pretty much as is, retaining all the subvolumes and (snapper) snapshots.

What is the best way to do this, ideally with some way to check the integrity and fidelity of the copy?

Some things I have looked at:

btrfs send

I'm not sure how to rebuild the snapshot structure (I have to specify parents manually?), how sending multiple subvols at once works, how to best check the integrity (maybe just a diff of the directories including the .snapshot directories?), or whether I should be using the "clone" argument and what it does.

buttersink

Seems to be abandoned. Designed for backups. Not sure if it offers much more than btrfs send.

btrbk

Designed for backups, not sure it fits my use case.

dd

Probably too low-level, might have problems with block size, partition sizing, etc.

My impression at the moment is that "btrfs send" followed by a diff is the best bet but I don't know how to handle sending the numerous snapshots that are on each subvol.

Improve this question
1
  • dd or cat should work, especially if you do it on just the filesystem, not the partition table. (Partition the destination first if you're using partitions on the source.) The downside is wasting time copying free space, not the blocks that are in use. Commented Dec 13, 2024 at 9:56

1 Answer 1

Reset to default
4

Assuming that both the original btrfs partition and the new, bigger drive or partition are on the same system, the easiest/best way is probably to use btrfs replace.

See man btrfs-replace for details. Here's an extract, reformatted slightly to improve readability:

btrfs replace start [options] <srcdev>|<devid> <targetdev> <path>

Replace device of a btrfs filesystem.

On a live filesystem, duplicate the data to the target device which is currently stored on the source device.

If the source device is not available anymore, or if the -r option is set, the data is built only using the RAID redundancy mechanisms. After completion of the operation, the source device is removed from the filesystem.

If the <srcdev> is a numerical value, it is assumed to be the device id of the filesystem which is mounted at <path>, otherwise it is the path to the source device. If the source device is disconnected, from the system, you have to use the devid parameter format.

The <targetdev> needs to be same size or larger than the <srcdev>.

Note the filesystem has to be resized to fully take advantage of a larger target device; this can be achieved with

btrfs filesystem resize <devid>:max /path

BTW, even if you want to use all of the new drive for this btrfs volume, I recommend creating a partition table with one huge partition instead of just using the bare, un-partitioned drive. It's a convenient way of labelling and reserving the disk space, so that other programs don't assume it's unused free space and helpfully offer to partition and format it for you.

Improve this answer
2
  • Thx. To get devid for that <devid>:max btrfs filesystem show can be used. Also parted /dev/nvme0n1 followed by print, resizepart 3 2000G did it for me on a 2TB disk. Parted must be using GB rather than GiB. Commented May 6, 2024 at 21:39
  • What state is the old disk left in? It still has your data on it, but is there any easy way to mount it? Or to copy from it again, if you experiment with something that doesn't go well on the copy. Or for example if you want to duplicate a disk, then move the copy to a different system while keeping a working disk in this system, can you re-enable the filesystem on the old source? Commented Dec 13, 2024 at 9:54

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.