3

I'm trying to transfer a 4 TB Time Machine backup from one USB 3 hard drive to another. I'm currently using SuperDuper to do it, and it's going to take upwards of two full days to perform the copy, if not longer.

That's significantly slower than the usual maximum speed for copying over USB 3, and I suspect that what's slowing things down is the overhead of copying each file individually, rather than just copying the raw data on the drive, sector by sector.

Given that I just need to duplicate a partition on to another drive:

  1. Would it result in a usable partition if I did a sector-by-sector copy?
  2. Would that be faster than using SuperDuper?
  3. And if yes to both of the above, what are some methods I could use to do that?

I already tried using Disk Utility's restore feature to clone feature, but it got about 5% of the way in and then failed with a weird error about a drive being busy. So I don't think it's reliable enough, and it has no option for resuming where it left off. But that said, it did seem like it was going much faster, and if it didn't fail, it would've taken around 8 hours for it to finish.

edit: for posterity, the reason Disk Utility failed to copy the drive is because my destination drive was dying and loaded with bad sectors. Under normal circumstances it would probably work and be about as fast as dd. However I like Allan's answer the most because, in case something causes dd to stop mid-copy, you can restart it from where it left off.

Improve this question

2 Answers 2

Reset to default
4

Use dd to clone your drive/partition.

The syntax is simple:

dd if=inputfile.foo of=outputfile.bar bs=blockSize

This will do a bit for bit copy of your drive. Whatever your drive "looks like", including partition tables, will be copied.

For example, assuming your Time Machine drive's identifier is /dev/disk3 and your second USB drive's identifier is /dev/disk4, your command would be:

dd if=/dev/disk3 of=/dev/disk4 bs=1M

You can also write directly to the raw device by using /dev/rdiskX

sudo dd if=/dev/rdisk3 of=/dev/rdisk4 bs=1M

Keep in mind, you will need to unmount the devices first with the command sudo diskutil unmountDisk diskX

Copy Speed

You are correct in assuming that there is some overhead associated with copying files. However, what you may not be aware of is that USB 3 speeds aren't what they are cracked up to be. USB 3 is upto 5Gbs (gigabits per second)... in a lab, on a clear day, with a really strong tail wind, going downhill.

The actual speed of USB 3.0 is closer to 100Mbps1

So, doing a little calculation, we find that to transfer a 4TB file at 100Mbps means it will take roughly 10 and a half hours at best (it could go slower!)

What I have found to be the most reliable for me is that I copy the file to an internal drive (or a network share as a 1Gbs wired connection is significantly faster than USB will ever be) and once I have the image, I then copy it to my target.

Breaking it up into two separate processes:

sudo dd if=/dev/rdisk3 of=/Volumes/Some/Network/Share/file.img bs=1M

sudo dd if=/Volumes/Some/Network/Share/file.img of=/dev/rdisk4  bs=1M

This has the added benefit that if anything happens, there is a copy in a safe place.

1 PC World: USB 3.0 speed: real and imagined

Improve this answer
5
  • If I use dd to copy the partition, e.g. dd if=/dev/disk1s1 of=/dev/disk2s1 will that actually result in a usable partition?
    – Bri Bri
    Jun 15, 2017 at 1:12
  • Yes....I'll add to the answer.
    – Allan
    Jun 15, 2017 at 1:13
  • Your answer does work, and it is indeed much faster than copying files using something like SuperDuper or rsync. Even better, it seems that if you're cloning a drive onto a larger driver, macOS automatically sees the extra space on the drive and adds it to the last partition. However, the drive I was copying from is loaded with bad blocks which is why using Disk Utility originally failed, and dd fails too. Oh well!
    – Bri Bri
    Jun 15, 2017 at 15:02
  • Great answer, but the PC World article states an average of 100 MBps (800 Mbps), not 100 Mbps. So the copy process would (theoretically) take in the vicinity of 1-2 hours.
    – user11633
    Jun 15, 2017 at 15:33
  • @GuyGizmo Using dd to copy to a larger volume does not reliably expand the volume, and can leave the volume in strange states. See [this question[(apple.stackexchange.com/questions/108795/…) for example. I'd only recommend using dd between volumes (or disks) of exactly the same size.
    – Gordon Davisson
    Jul 28, 2017 at 0:16
0

In addition to Allan's answer, I should mention that using Disk Utility's restore feature does indeed seem to have similar performance to using dd. It's not so much that it's unreliable as the hard drive I was copying from is dying and has tons of bad sectors. dd failed on it too.

That said, dd allows you to resume a transfer part way through, so when cloning a drive I'm going to prefer that, even if it doesn't have nice UI like Apple tools.

Improve this answer

You must log in to answer this question.

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