Kai Krakow <hurikhan77@xxxxxxxxx> schrieb: > Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx> schrieb: > >> Hey. >> >> I've seen that this has been asked some times before, and there are >> stackoverflow/etc. questions on that, but none with a really good >> answer. >> >> How can I best copy one btrfs filesystem (with snapshots and subvolumes) >> into another, especially with keeping the CoW/reflink status of all >> files? >> And ideally incrementally upgrade it later (again with all >> snapshots/subvols, and again not loosing the shared blocks between these >> files). >> >> send/receive apparently also works for just one subvolume,... and >> documentation is quite sparse :-/ > > You could simply "btrfs device add" the new device, then "btrfs device > del" the old device... > > It won't create a 1:1 clone, if that is your intention. But it will > migrate all your data over to the new device (even a bigger/smaller one), > keeping shared extents (CoW/reflink status), generation numbers, file > system uid, label, each subvolume, etc... And it can be done while the > system is running. > > It looks like this way fulfills all your requirements. That same way you > can later incrementally update it again. BTW: I've done that when migrating my 3-device btrfs pool to bcache. I simply removed one device, reformatted with bcache, then added it. I repeated those steps for each device. It took a while (like 24 hours) but it worked. In the end I just did a balance to rebalance all 3 devices. That last step is not needed if you are migrating only one device. As a safety measurement I did a backup first, then ran "btrfs check" to ensure file system integrity, and did start into the rescue shell to have only a minimum set of processes running. Due to a bug in the Intel graphics stack the system froze sometimes, and I didn't want that to happen during data migration. -- Replies to list only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
