0

The question has been answered but it's unclear. Why can't I just dd an entire APFS disk?

The original question posts the dd command that was used to perform a byte-for-byte copy of a block device. As pointed out, that command resulted in a incorrect clone. The accepted answer explains why it failed but doesn't provide the correct dd command.

If I understand the explanation correctly, I should use the following dd command:

dd if=/dev/rdisk0 of=/dev/rdiskX bs=4096 obs=512

Or should I first re-initialize the target block device with a GPT partition scheme, create an APFS partition, and then perform a dd?

The goal is to take /dev/rdisk0 (source block device) and perform a byte-for-byte copy to a brand new external SSD (target block device).

Related Questions:

  • I haven't been able to find a clear answer as to whether or not using dd is possible if the source block device has encrypted APFS partitions.

  • Should I be using rdiskX or just diskX?

Tuaris
  • 3
  • Is there a reason you can't use Disk Utility? Or if you need a command-line solution, diskutil or possibly asr? IMO, trying to clone APFS is more trouble than its worth. – At0micMutex Apr 15 '21 at 21:16
  • In Disk Utility the imaging options are grayed out. – Tuaris Apr 15 '21 at 21:46
  • You should be using CCC (or similar). See 2nd answer in linked article. – Gilby Apr 15 '21 at 22:09

1 Answers1

1

Neither is actually correct.

The problem has nothing at all to do with APFS. As the linked answer describes, it has to do with the location of the partitioning tables.

If your source and destination drives have the same sector sizes, you can just copy using ordinary dd without any special parameters.

If they do not have the same sector size (as in the linked example with an old traditional hard drive and a newer flash-based drive), the partitioning table needs to moved.

Essentially the computer will try to read the GPT partitioning table at the location of the second sector. For some drives that will be at byte 512 on the drive, for others it will be at byte 4096 on the drive.

The dd command you suggest with two different block sizes won’t here. It means that dd will read in data in blocks of 4096 bytes, and write them out in blocks of 512 bytes - thus performing 4 writes for each read. However that still places all the data as the exact same byte indices on the target drive as they had on the source drive.

For your purpose you need to move the data that was previously at index 4096 to be at index 512.

Regarding your other questions:

Yes, encrypted partitions can be cloned with dd.

For this type of work you want to use rdisk instead of disk. The r means “raw” meaning that you’re bypassing the disk cache. You’ll end up with the same result, but it will go quicker that way.

jksoegaard
  • 77,783