6

I want to clone my internal drive to an external one, byte for byte, partition table to partition table. My MBP is using GPT with APFS, the standard now-a-days. I do not have a T2 chip, but I do have a T1 chip. My internal drive is 500GB as is the external drive. Though, I think the issue may lie in the fact that my internal drive has a sector size of 4086 bytes and my external drive has a sector size of 512 bytes.

I tried to use dd in recovery mode using the command dd if=/dev/disk0 of=/dev/disk4 bs=100m but it was going super slow at 18 - 19 MB/s. (USB 3.1 SSD).

I booted into Linux and did a copy of the drive (using dd if=/dev/nvme01 of=/dev/sdb) and it was much faster at 270 MB/s. I also was able to test within a virtual machine and got the same 270 MB/s speed. I confirmed that the first 100 MB between the drives were the same (used dd and md5sum).

I also confirmed the same way in recovery using dd and md5. But the drive didn’t have a partition table and macOS just read the drive as having something like 65 GB and refused to mount it.

So I recreated the partition map using parted and then restored the partitions. But macOS still refused to do anything with it. I’m guessing I need to dd the synthesized disk from macOS but there is obviously something wrong with the USB driver since it’s writing so slowly.

I also tried copying the partition tables using sfdisk but it failed because “first lba specified by script is out of range”.

I've also tried using cat (cat /dev/disk0 > /dev/disk4) and that didn't change the speed at all, so it's not dd.

Here is the output of diskutil list:

-bash-3.2# diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         500.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk2         500.0 GB   disk0s2

/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk1
   1:                  Apple_HFS macOS Base System       2.0 GB     disk1s1

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            288.0 GB   disk2s1
   2:                APFS Volume Preboot                 64.6 MB    disk2s2
   3:                APFS Volume Recovery                1.0 GB     disk2s3
   4:                APFS Volume VM                      1.1 GB     disk2s4

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     disk3

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk4
   1:                        EFI EFI                     314.6 MB   disk4s1
   2:                 Apple_APFS Container disk5         500.0 GB   disk4s2

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +ERROR      disk5
                                 Physical Store disk4s2

/dev/disk6 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk6

/dev/disk7 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk7

/dev/disk8 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk8

/dev/disk9 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk9

/dev/disk10 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk10

/dev/disk11 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk11

/dev/disk12 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +12.6 MB    disk12

/dev/disk13 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +4.2 MB     disk13

/dev/disk14 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk14

/dev/disk15 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk15

/dev/disk16 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk16

/dev/disk17 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk17

/dev/disk18 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk18

/dev/disk19 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk19

/dev/disk20 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk20

/dev/disk21 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk21

/dev/disk22 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk22

/dev/disk23 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk23
Improve this question
9
  • 2
    The disk is GPT not APFS. APFS is a filessystem stored in one (or more) partitions. You can definitely use dd command to copy the whole disk (including partition tables, EFI partition etc). You would want to copy the physical disk not synthesized. If it was slow please edit question with exact dd command including bs parameter. If you just want to copy APFS to an existing partition on backup disk you could use free version of superduper or use dd to copy just the partition and make sure destination had type AF0A
    – lx07
    Commented Jan 31, 2020 at 9:07
  • [continued] note superduper doesn't do a 1:1 copy like dd - it leaves out some temp files etc as recommended by Apple but it depends what you are trying to achieve - it will make a bootable copy of APFS container.
    – lx07
    Commented Jan 31, 2020 at 9:13
  • 2
    Thanks for the edit. Please update your question with diskutil list but if you did dd if=/dev/disk1 then most likely you are copying from the synthesized disk. This will not copy the partition table and will put unreadable information on the destination. You want to copy from the physical disk (disk0). Try dd if=/dev/disk0 of=/dev/disk4 bs=100m (assuming *disk4` is your second physical drive).
    – lx07
    Commented Jan 31, 2020 at 16:24
  • 1
    In my opinion the best method is: 1) shrink (apfs container) disk0s2 slightly 2) reformat disk4 to 1 hfs+ partition 3) asr -source disk2 -target disk4s2 -erase
    – klanomath
    Commented Jan 31, 2020 at 22:52
  • 1
    @Kyle, just FYI, Restic is a great incremental/snapshot-based backup tool with POSIX filesystem support as one of its main features. It currently supports POSIX file permissions, and does support symlinks, but doesn't support hard links.
    – Jivan Pal
    Commented Feb 1, 2020 at 15:23

3 Answers 3

Reset to default
7

The asr command is the native tool to clone data and handles all Apple metadata, file systems and APFS / core storage structures. If no one can help, worst case is to restore from a backup and use asr rather than dd the data destroyer.

I partially joke about dd - it’s more useful than just destroying disks, but on several macOS filesystems, you don’t want a perfect clone of the drive identifiers in almost all cases - you want the data moved and not the entire structure and instantiation of what was designed as a unique filesystem identifier and the associated data that you do want to move.

Improve this answer
3
  • 2
    @lx07 dd actually bit-for-bit copies everything. But sometimes/often this isn't a good idea because all UUIDs (partition/volumes/apfs (container/physical etc.)) are identical/exist twice afterwards. So it depends on the scenario/intention...
    – klanomath
    Commented Jan 31, 2020 at 21:11
  • @klanomath I’ve linked to your superior answer on using asr with core storage to illustrate volume copies and not disk copies as the correct path for general cloning.
    – bmike ♦
    Commented Feb 2, 2020 at 14:17
  • I've tested both asr cases (cs > external disk partition & apfs > external disk partition) in VMs. They ended differently: a cs source LV converts to an hfs+ partition on the target disk; an apfs container scheme source (no localsnapshots allowed - if I understand the man pages correctly)! is just "replicated/copied" to a new container scheme (with system/data/recovery/preboot - vm is created automatically after booting from the target disk) on the target disk.
    – klanomath
    Commented Feb 2, 2020 at 14:39
1

You can absolutely use dd to clone your MacOS disk that has an APFS partition. The issue is that your source and target do not share the same sector size. This isn't a huge issue, though, as the only thing that matters is that the partitions are aligned to the sectors, not the data within them. So if you erase the target disk in Disk Utility selecting GUID and APFS as the scheme and format, then the partitions will be aligned. Then use dd to clone the individual partitions. That's it!

Also, regarding the slow copy, you need to use /dev/rdisk0 and not /dev/disk0.

Improve this answer
8
  • 3
    Not really true: the gpt of 512B disks are slightly smaller than the gpt of 4k disks! So a disk0(512) to disk4(4k) with the same size will fail (or better: the gpt is somehow irregular). GPT(512) is 1 pmbr + 1 gpt header + 32 table: first new block (alligned to 4k)=40. GPT(4k) is 1 pmbr + 1 gpt header + 4 table: first new block=6 (=48 (512blocks)). Keep in mind: block numbering starts with block0!
    – klanomath
    Commented Jan 31, 2020 at 23:12
  • @klanomath Got a source for this? To my knowledge, physical sector size is irrelevant, since GPT assumes a logical block size of 512 bytes, regardless; the partition tables are always typically 34 blocks, i.e. 17KiB.
    – Jivan Pal
    Commented Feb 1, 2020 at 15:20
  • @JivanPal I simply compared the GPT of a 512 and a 4096 disk (at home) with hexdump/hexfiend. The reason is the "waste of space" for the PMBR and the GPT header. Each requires 512 Byte but occupies a whole 4096 block.
    – klanomath
    Commented Feb 1, 2020 at 15:25
  • 2
    @JivanPal I have some at home (e.g. an external 10TB Western Digital). Sometimes the USB2SATA controller intervenes and reports a 512e device as 4Kn only device to the system - which is a problem if you format the disk internally and use this disk in such an enclosure later. Other example: Recover Corrupt SSHD
    – klanomath
    Commented Feb 1, 2020 at 16:39
  • 1
    @klanomath Good to know — for that kind of cross-compatibility reason, among others, I assumed that the GPT spec defined a block as 512 bytes in all cases. It kind of seems like an oversight that they didn't define it that way, especially given that UEFI has to read 128-byte partition entries anyway.
    – Jivan Pal
    Commented Feb 1, 2020 at 16:45
-2

Best solution I found is to use Paragon Hard Disk Manager 17 Advanced in Windows. Simply clone to new drive. It does require a Windows boot partition or putting the source and destination drives in external cases but not really deal.

Improve this answer
1
  • 1
    It can't even read APFS… & what possible use is a Windows boot partition on a Mac. You didn't even read the question.
    – Tetsujin
    Commented Aug 23, 2021 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .