How do I copy my system partition to a new partition on a different disk? FS is btrfs. How do I make sure that all btrfs subvolumes are correctly copied?
thanks,. Kusi
The copying is not the problem. You can always copy a partitions contents to another partition (of the same size!!) with e.g. dd. And what is inside the partition is of no interest. Of course the partition must not be in use. Thus when youwantto copy the root partition, you must run anotther sytem (live system or rescue system) to do the copying.
But the problems arise when you copy your root partition to another place and want to tun the system from there. Grub should know where it is, else it will not boot. Your fstab must be adapted, else / will not be mounted correctly.
I wrote up some notes on the rootfs structure and how to how to create it from scratch here:
The notes include how to use snapshots to copy the contents (for the part of rootfs which is subject to snapshots).
If you have an existing rootfs as a template, the btrfs-image command would also be worth a look. I’ve not actually used btrfs-image and its man page lacks examples, so you might have to google or experiment a bit.
Although hcvv writes “The copying is not the problem” - I think it is a bit of a puzzle to ensure the subvolume structure is properly reproduced and initialised. But hcvv is correct that grub and grub UEFI NVRAM entries add a bunch more to puzzle over.
If the higher level tools the installer uses to create the rootfs and make it bootable were made into stand alone tools, it might be very useful for assisting with backup and recovery.
Why? dd does a byte by byte copy of the partition. All bytes. Without any knowledge of what a byte is used for. Thus whatever other software might think those bytes and their sequence represent is exactly the same on the copy. Being it a file system of any type or not. It is just a sack full of bytes in sequence. Nothing more, nothing less.
And a Btrfs on a partition is a complete, self contained, structured thing. No information about it and it’s contents is stored outside the partition (when not in use of course). Thus wen you copy it byte by byte, you have all the information that you need: files and directories, inodes, data, subvolume information, …
Sorry, you are correct in the case of dd. I was referring to the problem when using other commonly used approaches such as tar and rsync.
Personally I’d not too keen on dd because a block copy may do a lot more writes than necessary and take a bit longer than just copying the content. When I previously attempted to look into the problem of how to copy the btrfs rootfs, I was looking to use btrfs send/receive or rsync, or both, hence the task was much more puzzling.
For my ext4 rootfs I rsync to USB3 disks to be rotated offline. This has always worked quite well for desktop recovery and is very quick to perform. I was looking for something for btrfs that was as efficient and as reliable.
Tools like tar and rsync copy files, not partitions (as the OP’s title of this thread gave as the subject of the discussion).
Of course you can use those tools to copy only the files in a file system to another, empty, file system. I do that a lot because the new file system can then be on a volume of a different type (partition, logical volume, …) and size and on a file system of a different type. But, as said, that was not the subject and, IMHO, reading the OP’s first post, that was what he wanted to do.
BTW, mark that the terms “partition” and “file system” are not synonymous.
A partition is one of the several types of volumes (I often denote them as “containers”) of mass-storage. These volumes can be used in different ways. One of those ways is to put a file system on it.
A file system a way of using such a volume in an structured way to store and retrieve data files.
I’ve been doing some experiments with dd and btrfs-image in a VirtualBox. Noting your warnings concerning grub and fstab, I like to add an additional warning concerning uuids.
If dd is used to copy a btrfs partition, or any partition with the partition listed in /dev/disk/by-uuid, the partition’s uuid will be duplicated. Because Leap defaults to using uuids in /etc/fstab, duplicate uuid’s may confuse the running system. Immediately after the doing a dd, mount may report the wrong device as being mounted. This may happen even if you make no attempt to mount the copy. The confusion will persist if you do a boot. Uuid’s can be set by using uuidgen and btrfstune. Btrfstune may consider the duplicate to be mounted, so you may have to move the disk to another machine to successfully set the uuid. If you’re desperate to dig yourself out of this situation and don’t mind destroying the copy, wipefs -a --force /dev/yourCopyDevice can nuke out the identifying metadata of the copy.
I think btrfs-image also duplicates the uuid, so again, you need to deal with that, or it may lead to a similar situation.
I feel nostalgic for the simpler world of Linux 0.11.
Filesystem UUID gets duplicated, not partition UUID. Or, in general, UUID of content of partition. Please be more accurate, especially if you intend to write some sort of howto. “Partition UUID” does exist and means something entirely different (and will not be duplicated in this case unless you copy full disk).
Thanks - the internal UUID in the filesystem metadata is what I meant. Having just moved to UEFI I’d overlooked the partition UUID’s. I’m definitely out of my depth here, hopefully someone can use some of the above as a basis for a better write up in the future.
Linux also supports fake partition UUIDs on MBR. They are not that persistent as GPT though (as they use partition number so deleting (logical) partition will shift all subsequent numbers and change UUIDs).
Sigh!
Yes, the sloppy behaviour we see often in human people and that does not work very good together with computer strictness.
Do not confuse the container which the contained.
Do not confuse the partition with the file system.
Partitions can contains things other then file systems (e.g. swap, but also “raw” data, recovery systems).
File systems can be contained by other things then partitions (whole disks, logical volumes).