dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
484

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu to thender

MVM

to thender

Re: Why doesn't ddrescue copy partitions over properly?

The reason I use a destination location of a file, and not a disk, is 1) quite often I need to actually review the raw disk dump (with a hex editor) to see what happened/got lost/is missing, and 2) when I have no way of guaranteeing that the destination disk is healthy (i.e. it may too have issues).

First thing is first: OS X is probably going to throw all sorts of nonsensical madness complaints/failures if you do this. Apple's partitioning tools actually look at vendor strings of hardware (disks I think) and will reject you if you try to work on a "non-Apple-approved" disk. OS X also uses some very bizarre partitioning scheme that I cannot even begin to explain (it's some weird form of like EFI plus GPT, or EFI plus MBR -- I forget). I only know 2 people who use OS X (one is in the process of getting off of it entirely). So because of the OS that's utilising the disks, you're actually fighting multiple battles at once. (Thanks, Apple!)

Second thing: GPT, along with some other partitioning schemes has two copies of the partition header: one set goes at the front of the drive (LBAs 0-33), and one set goes at the very end of the drive. MBR does not work this way (there's only one copy, at the start), but I am certain there are other partitioning schemes that operate similarly to GPT.

Step back for a moment and think about what happens when you copy LBA-to-LBA a 250GB drive to a 320GB drive: every LBA is copied in the same linear order as the source material. So effectively you have the last 70GB of the 320GB drive "untouched", right?

Now read what I just said about the GPT scheme, where the secondary header goes at the very end of the drive. With your copying method, it's not going to work -- the secondary GPT header would be at the 250GB mark, instead of at the 320GB mark. Some OSes will throw hissy fits about this but still work, while others will throw hissy fits and refuse to work.

All I remember about OS X is that it's partitioning scheme is really bizarre/unique in some way.

Thirdly and finally: you just confirmed that the source drive (250GB) has some unreadable LBAs on it. That means there is already guaranteed data loss. What makes you think some of that data isn't used for, say, the boot loader? Or the kernel? Or some other key part of the OS? This could in turn bite you in the butt.

This is one of the reasons why I tend to recommend that when losing a drive, the individual reinstall the OS on a new drive, and then proceed to use a file-based copying mechanism (ex. rsync -avH) to copy their data from old to new. This has many advantages (including being able to see which files return I/O errors due to unreadable LBAs -- now you know which files can't be recovered, while with dd/ddrescue you have no idea), particularly that you know you don't have to fight with the OS regarding partitioning schemes. This is even more important with Apple's stuff, because for whatever reason they love making things painfully difficult + forcing you to use "their stuff". That's what you get when you buy Apple -- you have to rely on them 100% of the time.

If you were on Windows or an *IX, this situation would be more foregiving.

If you really must stick with the drive-to-drive method, I recommend you find a replacement 250GB drive of the same source type (maybe on eBay, etc.). Same brand, same model number, and if at all possible same firmware number -- it's very important the drives be the EXACT same. Do not just go out and buy another drive that claims 250GB capacity (LBA counts may not be identical). There are complications when going from a smaller-to-larger drive; dd (along with ddrescue) has no concept of partition tables, so it doesn't do things like "resize partitions". And while that may work, partition-wise, it may not work when it comes to things like the partitioning scheme (see above, re: GPT, EFI, etc.).

I would also consider seeing if you can find (certainly commercial) software that is known to be able to copy a disk used by OS X to another disk also to be used by OS X. That, to me, is honestly your best bet -- such tools should be able to handle all the nuances I describe above, in the "Apple-proprietary way". I know that's not what you want to hear, but it's probably the safest avenue.

In the meantime, I'd use rsync -avH to get all the data off the existing drive anyway, just in case something goes catastrophically wrong. And like I said: this will also allow you to know which files are using LBA ranges which are unreadable (i.e. data loss).

Else scrap this entire project and just restore from backups (i.e. take that 320GB drive, install OS X on it, then begin restoring your files/etc. from backups). :-)