Copy an APFS Formatted Disk
Copy an APFS Formatted Disk
NOTE: Bootable Volumes REQUIRE a different method!
Copy the Disk?
Say you have a disk drive (or two) formatted with APFS that you use for backups and data storage.
Say these disks are almost full.
Say you’ve set up multiple volumes on these disks to partition data.
You can manually copy the data on each of these volumes, one by one until you’ve recreated the entire structure. You can then manually go and find any references you made to these volumes (perhaps by their UUID) and update those. You can configure them as new Time Machine destinations and go to the individual clients and setup new Time Machine destinations on those. You can tell Time Machine to use the old backups… you can do a lot of things. Or you can just copy the disk.
Copy the Disk
The goal is to take a new (bigger?) disk and make it a drop in replacement for an old (smaller?) disk.
Actually Copy the Disk
dd bs=1g if=/dev/rdiskX of=/dev/rdiskY
What Source (if)?
When you use diskutil list to see the disks attached to your Mac, you will see two disks for each APFS formatted.One is “physical” (probably) while the other is “synthesized”. The physical disk would be the logical choice for your source, but that doesn’t seem to work and, if you are copying multiple terabytes of data, is a HUGE waste of time.
You should use the synthesized disk as your source.
What Destination (of)?
Use the physical disk here, you really do want to nuke the whole thing and replace it with what you’ve got.
Block Size (bs)
Block size is generally set to 16m (16 megabytes), but you can play around with it. Blocks are the units on which dd acts and the right block size will maximise speed. However, the correct size is difficult to determine because it involves a number of factors (RAM size and speed, read speed of the source, write speed of the destination, and a few others). The default size is usually too small, 16m works, and 1g does too.
One side effect of a large block size is that dd will update it’s status infrequently. It seems to “publish” statistics as each block completes and a large block means more infrequent statistics.
rdisk
macOS provides two devices for each disk, /dev/diskX and /dev/rdiskX. The rdisk entries are closer to the “raw” disk. You can check superuser for more details or man hdiutil to see what Apple has documented.
Post Copy Issues
After the disk is copied you will find yourself with two issues:
- The disk is not the right size (i.e. extra space is not available)
- The both disks have the same UUIDs
Size
Fixing the size is relatively easy
- Use
diskutil listto determine the size macOS thinks the disk is. - Use
diskutil apfs resizeContainer diskX Y.Ztto set the disk size explicitly to what macOS THINKS the disk should be. - Use
diskutil apfs resizeContainer diskX 0to set the disk size to all of it.
UUID
Fixing the UUIDs may be a bit touchier. What I did to avoid anything unpredictable is shutdown the machine used to copy the disks and removed the old disk. I physically unplugged it.
- Shutdown the machine which generally uses the disk
- Remove the old disk
- Startup the shutdown machine (you can stop here if you wish)
- Verify that things look good
- Use another Mac
- Attach the old disk
- Use
diskutil listto find the disk - Use
/System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -s diskXto “set container UUID and its volumes(s) UUID(s) to new random values” - Put the old disk somewhere safe to act as a snapshot
You can substitute the current Mac booted into it’s recover partition for another Mac. The main idea is to have a machine that doesn’t care about the disk in question and won’t try to do things with the disk via the UUIDs.