I've used dd on Linux to make a block for block bootable copy of a LUKS encrypted volume which created a bootable encrypted clone. I'm trying to achieve the same on a Filevault2 volume, disk0 as internal disk. I want to write this to an identically sized partition on an external USB disk.

I made the destination partition a GUID Journaled extended HFS+ journaled to match the original volume. The dd finished but the partition is unusable, doesn't unlock, mount or boot.

I'm thinking of reformatting the partition as DOS and writing over it with dd again. Would it be safe to hope the partition will inherit the desired scheme from the source? It takes 4 hours to write 250GB and wanted to see if anyone else had done this before.

Filevault2 reconfigures the single partition on disk0, to add the recovery partition after 10.7 giving you something like this:

#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *250.1 GB   disk0
1:                        EFI                         209.7 MB   disk0s1 
2:          Apple_CoreStorage                         249.2 GB   disk0s2 
3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
#:                       TYPE NAME                    SIZE       IDENTIFIER 
0:                  Apple_HFS Macintosh HD           *248.9 GB   disk1

disk1 is the encrypted data of the core storage logical volume. This is similar to what happens in LUKS on Linux.

So my hope is to get this into a partition on a shared 1 TB external drive. Any thoughts on what format to make that partition would be appreciated.

  • Welcome to Ask Different! Please could you copy-paste Terminal output into a code block - one long line of output is very difficult to read.
    – grg
    Jan 5 '14 at 7:16
  • OK, I've edited the output to be more readable...
    – alex
    Jan 12 '14 at 23:34

Just to rectify one thing: disk1 is not the encrypted data. Disk1 is a mounted "virtual" volume with its own disk identifier. This volume is unlocked and as such unencrypted if you are a legitimate user. It's based on inferior encrypted data structures residing in disk0s2.

To clone (and subsequently decrypt) FileVault2 volumes successfully three objects/data structures are important:

  1. Superior LVM structures in disk0s2 (the CoreStorage Volume Group)
  2. The Recovery HD partition. It contains some intermediate keys which are necessary to extract the final keys to unlock the FileVault2 volume.
  3. The encrypted data itself

To clone a FileVault2 volume you may either dd the CoreStorage LVG and the Recovery HD or copy the unlocked FileVault2 volume to a second volume with rsync or Disk Utility/a disk cloner like Carbon Copy Cloner.


  1. Open Terminal and enter diskutil list.
  2. Enter sudo gpt -r -vv show /dev/diskX with diskX: the disk with the CoreStorage LVG containing the FileVault2 Logical Family/Volume
  3. Now attach a second (external) disk (diskY) and replicate the GUID partition table of the source (diskX) to the target disk (size, type etc.) with gpt.
  4. Recheck the identity of the GUID partition table of diskX and diskY
  5. Enter:
    dd if=/dev/rdiskXs1 of=/dev/rdiskYs1 to copy the EFI partition
    dd if=/dev/rdiskXs2 of=/dev/rdiskYs2 to copy the CoreStorage LVG
    dd if=/dev/rdiskXs3 of=/dev/rdiskYs3 to copy the Recovery HD
  6. done

Disk Cloner

This will not create an identical disk (same intermediate/final keys etc.) but a volume containing identical data.

  1. Boot to a Recovery HD, an installer thumb drive or a second full-blown OS X volume.
  2. Enter the unlock key of the FileVault2 volume while booting.
  3. Attach the external disk and create a sufficiently dimensioned normal volume with an appropriate tool.
  4. Open Disk Utility (or Carbon Copy Cloner if use a full OS X system)
  5. Restore the source volume (the unlocked FileVault2 volume) to the destination disk.
  6. Reboot to the external drive.
  7. Open System Preferences -> Security and enable FileVault.
  • Should not dd if=/dev/rdiskX of=/dev/rdiskY replace steps 2..5 of dd variant?
    – tig
    Jan 3 '16 at 0:38
  • I understand if the destination is smaller, but should not it work is destination is equal or bigger?
    – tig
    Jan 3 '16 at 15:00
  • Small test of copying 4 partitions from a smaller ram disk to a bigger ram disk seems to move everything as expected
    – tig
    Jan 3 '16 at 18:30
  • @tig You are right for most cases. But the usage of dd is error prone - especially for non-pros. I prefer to publish the 1 partition to 1 partition dd command here. Think of an encrypted volume & Recovery HD and a subsequent BOOTCAMP partition or non-allocated disk space as source and a already partitioned disk with some free space (just enough space for the three partitions at the beginning of the target disk or in between).
    – klanomath
    Jan 3 '16 at 18:48

You must log in to answer this question.

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