Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
AidenShaw, I'm going to be doing it in osx as subsonix has helped me get ddrescue set up in osx, a few things I need to know..

1) With the OSX method, it is creating a disk image, and is not actually moving the files to a destination, as was done in your linux example. Is this ok? Will I still get the same benefit you mentioned of not applying any stress to the disk?

If you can mount and repair the .dmg file, then it should work. Note that there will be some missing sectors - so if you can't repair the drive .dmg you might not be able to read a read-only disk image (although you could restore the .dmg to a real disk, and repair the real disk - which takes twice as long as copying directly to a different disk).

This is the only code I'm going to be using is
Code:
sudo ./ddrescue -v /dev/disk4s2 MyVolImage.dmg MyVolRescue.log

2) What about the second line? To recover the rest of the data? The linux line you provided was "ddrescue -d -b512 -c1 --retrim /dev/sda /dev/sdb rescue.log" But I cannot figure out how to make it do that in mac. It was in that mac world link you sent, or at least I didn't figure out which one it was.

Thanks!!!

The parameters of the first command in my example basically say "quickly read the disk in large chunks, skipping any chunk with an error". This is to get as much data off while not causing a lot of stress.

The parameters of the second command say "re-read the bad chunks sector by sector, retrying as necessary". If the disk has surface defects, this will stress the disk, and you may find that it gets worse. (But that's OK, because the first command got most of the data.)

If your version of ddrescue does something similar then you should be fine.

ps: Sorry about misunderstanding "re-reading"
 
Last edited:
If you can mount and repair the .dmg file, then it should work. Note that there will be some missing sectors - so if you can't repair the drive .dmg you might not be able to read a read-only disk image (although you could restore the .dmg to a real disk, and repair the real disk - which takes twice as long as copying directly to a different disk).



The parameters of the first command in my example basically say "quickly read the disk in large chunks, skipping any chunk with an error". This is to get as much data off while not causing a lot of stress.

The parameters of the second command say "re-read the bad chunks sector by sector, retrying as necessary". If the disk has surface defects, this will stress the disk, and you may find that it gets worse. (But that's OK, because the first command got most of the data.)

If your version of ddrescue does something similar then you should be fine.

ps: Sorry about misunderstanding "re-reading"
That's the thing I'm not sure if "my" version does the same thing. As far as I can tell all it does is make a disk image. I'm not sure if it skips over files or not. If it does, then I still need to know how to do the second part.

Another question: when it skips over sfuff with errors is it skipping over entire files? I'm not 100% sure how it works. In other words, will I be missing whole files or the fragments inside the file. In other words there is a .wav file which is partially transferred. So in the middle of the song it's missing.

Excuse my ignorance I just don't know how this works.
 
By the way, reading that link you sent for mas osx hints, someone posted that there are two programs which do the same thing as ddrescue. I was not sure if that person knew what they were talking about or no. But these are the two programs: for the simple fact that clearly I'm not 100% understanding how this whole ddrescue thing works, can you tell or do you know of these programs if they will work in the same way? meaning low stress copy while ignoring bad stuff??

https://www.prosofteng.com/datarescue4/
http://subrosasoft.com/OSXSoftware/index.php?main_page=product_info&products_id=1
 
That's the thing I'm not sure if "my" version does the same thing. As far as I can tell all it does is make a disk image. I'm not sure if it skips over files or not. If it does, then I still need to know how to do the second part

It's the same tool, the process already is multi pass, if you read the manual you'll see this.. Since you use the logfile I think you should be able to go back and attempt more later, there are lots of options but the more specific you get the more it asks of you. So perhaps a simple default is a good starting point..

It makes a disk image, which is what it is suppose to do, the alternative, to write to a disk, if you hadn't already formatted it and had three partitions on it, would mean that it did nothing as far as you could tell, no?

Another question: when it skips over sfuff with errors is it skipping over entire files? I'm not 100% sure how it works. In other words, will I be missing whole files or the fragments inside the file. In other words there is a .wav file which is partially transferred. So in the middle of the song it's missing.

Excuse my ignorance I just don't know how this works.

You may miss entire files, part of files and/or part of the filesystem. That's why when you are done, you'll need to check and attempt to repair the filesystem, but now removed from the faulty disk. If you can't mount the diskimage read/write from Finder, then that's because the owner of the disk is root and only the user (i.e root) has write access. After you have managed to mount the diskimage (if it's not too damaged) and tried to repair the filesystem on it, you should be able to move files individually to the target disk filesystem in Finder if eveything works out.
 
That's the thing I'm not sure if "my" version does the same thing. As far as I can tell all it does is make a disk image. I'm not sure if it skips over files or not. If it does, then I still need to know how to do the second part.

Another question: when it skips over sfuff with errors is it skipping over entire files? I'm not 100% sure how it works. In other words, will I be missing whole files or the fragments inside the file. In other words there is a .wav file which is partially transferred. So in the middle of the song it's missing.

Excuse my ignorance I just don't know how this works.

The filesystem is opaque to "ddrescue" - it deals with the raw sectors. If a sector is bad, that sector contains 512 bytes of zeroes in the copy. Whatever file was using that sector has a "hole" in it.

If a bad sector is being used for meta-data (like a directory), that directory would have a "hole" in it. If you try to access the directory, you'll get an error about a corrupt directory. (On the original disk that sector would give a hardware disk error - on the copy there's no disk error, but the data is corrupted.)

That's why it is necessary to be able to "repair" the copy of the disk - the repair utility should notice the corruption and try to reconstruct the directory - at least so it no longer gives an error. Some of the files may show up in a "lost file" directory, where you can move them back to where they belong. (Some filesystems keep a pointer to the directory in the file metadata - those can usually fully reconstruct the directory.)
 
To both Aiden and subsonix, I appreciate your help. Do you have any suggestion as to using prosoft data rescue 4? This ddrescue route just seems too complicated for someone like me who doesn't fully understand it and has never done anything remotely similar to it before.
 
I just recently installed all new pci-e flash/ssd hard drives to replace my disk drives. I planned on using the disk drives as backups as I have the trays in my mac pro (3,1 mac pro 8 core maxed out ram osx mavericks). So one of the drives, which has a ton of samples as well as my entire itunes library of .wavs from hundreds and hundreds of cds I use to reference audio mixing. I was in the process of copying them to a new destination drive. But in the middle I kept getting -36 errors and then all of a sudden it would either cease to be recognized at all, or all the folders would be empty. It's worth noting that the file transfers were huge, and also, the drive itself used to be me my scratch/project drive and it's been like 7 years of heavy use.



So I did some googling and downloaded a program to do the S.M.A.R.T. test and it failed (also failed in disk utility as the smart status is not verified). When I restart my computer it shows up again and all the files show up, and some of them can even be loaded such as wav files. But some seem to be corrupt randomly. Any time I try to copy files, it freezes quickly after being very very slow for like 20 minutes.



So my goal here is just to get the files off, I don't care to save the drive. Once the files are off I can just buy a new drive, which I was gonna do anyway. I just gotta get there files off. And since the drive is not fully dead (yet), I don't believe this warrants paying the super high fees of data recovery. I'm hopeful someone can guide me in the right direction.



Below I posted all the specific results in case someone is super technically fluent and it can help them solve my problem.


View attachment 569667 View attachment 569668 View attachment 569669 View attachment 569670

I'm probably a little late to this party, but what the heck. I use a product named Scannerz and it comes with a utility called Phoenix. Phoenix can clone off data by stepping over bad files or attempt to recover them during the copy process. Phoenix can be bought by itself or with Scannerz. Here are some links:

http://scsc-online.com/Scannerz.html
http://scsc-online.com/Phoenix.html

From my experience, you're better off just trying to get the good data off the drive as fast as possible without attempting to recover it. Recovery can take a long time per sector and since you have thousands of bad sectors already it means attempting to recover the data may literally take days, and your drive may die in the process. If you go to the Phoenix page I linked above you can see that in the middle of the user interface is the option to attempt to recover data.

The nice thing about Phoenix is that it generates a log file and tells you exactly what files went bad so you'll know exactly what's missing and it's easy to use. I don't see anything wrong with the ddrescue attempts others mentioned, it just seems like a lot more complexity…but it is free.:)
 
I'm probably a little late to this party, but what the heck. I use a product named Scannerz and it comes with a utility called Phoenix. Phoenix can clone off data by stepping over bad files or attempt to recover them during the copy process. Phoenix can be bought by itself or with Scannerz. Here are some links:

http://scsc-online.com/Scannerz.html
http://scsc-online.com/Phoenix.html

From my experience, you're better off just trying to get the good data off the drive as fast as possible without attempting to recover it. Recovery can take a long time per sector and since you have thousands of bad sectors already it means attempting to recover the data may literally take days, and your drive may die in the process. If you go to the Phoenix page I linked above you can see that in the middle of the user interface is the option to attempt to recover data.

The nice thing about Phoenix is that it generates a log file and tells you exactly what files went bad so you'll know exactly what's missing and it's easy to use. I don't see anything wrong with the ddrescue attempts others mentioned, it just seems like a lot more complexity…but it is free.:)


So basically this does what ddrescue does exactly in the same way, just easier to deal with?
 
So basically this does what ddrescue does exactly in the same way, just easier to deal with?

I couldn't answer whether or not they do what they do in exactly the same way. What I do know is that Phoenix will properly copy resource forks, and with ddrescue being linux based, I don't know if it would (someone else could probably be better suited to answer that). Also, if the recover option is selected in Phoenix, its recovery attempt is inline, meaning it does it as it encounters files.

What I did with Phoenix once was make two partitions on an external drive and I did a volume clone from the bad drive with no recovery options selected to the first partition. It took longer than normal even though it's jumping over corrupt files because every time it hits one it still slows the thing down. Then I did it again with the option to attempt 10 recovery attempts and did that by using the bad drive as the source and the second volume as the target. It took over a day. It did recover some additional information, but like the manual says, you're dealing with a dying drive so don't expect miracles.

My advice would be to use whichever tool you prefer and just skip trying to recover bad files unless the data is really, really critical.
 
I saved a drive once that just wouldn't let you look at any thing, put it in a USB drive enclosure ( I had a new drive already installed with the correct OS for start up) I plugged in the usb, it showed up on the desktop, I then copied every thing over to the new drive, saved every thing, this worked for me, just saying. I also agree with the other posts, Disk Warrior is the way to go.
 
So basically this does what ddrescue does exactly in the same way, just easier to deal with?

I have saved a lot of data following the script that I recommended for ddrescue on:
  • XFS filesystems
  • NTFS filesystems
  • EXT* filesystems
  • Disks in software RAID-1 arrays, with various filesystems
  • Disks in software RAID-0 arrays, with various filesystems
  • Disks in software RAID-5 arrays, with various filesystems
  • Non-filesystems (databases utilizing RAW disk access)
Never used it with any FAT* filesystem, but that's because I would never put any data that I cared about on a FAT* filesystem.

The most recent one (within the last two weeks) was a 16TB RAID-0 array on a SATA port multiplier controller that responded to a simple read error by timing out the drive and dissolving the 16 TB array. I figured out from S.M.A.R.T and error logs which drive was triggering the timeout. Moved that drive to my Linux "service" machine, connected an identical drive that was error free, used the script that I presented to clone the RAID slice to the new drive.

After one try of the first command and a number of the second command - the replacement drive had one sector that was damaged. 512 bytes of a 4,000,000,000,000 drive had failed.

Put the replacement drive in the server, booted - everything is happy. Disk repair (chkdsk) didn't find any issues, RAID volume seems fine. There's one bad sector in there, but that might only mean that one money shot splatters a bit more or less than the cinematographers intended.

To me, "easier to deal with" means "might makes some assumptions that are incorrect and destroy all of my data", or "fail to recover as much of my data as is possible".

My advice is to find a friend who understands this thread (or hire a consultant who understands it). Don't lose all of your data because the "right thing" seemed too complicated.
 
Last edited:
I now do beta testing for SCSC, the company that makes Phoenix and Scannerz (going on almost 2 years now, actually.)

ddrescue and Phoenix do not work alike at all. Oddly, Scannerz works closer to ddrescue because its drive scanning is at the raw drive level beneath the file system. In fact, Scannerz has to query the system to get stuff like volume and partition information because as far as it's concerned it's hardware, not a file system. Years ago, Scannerz was originally a scan module for Unix based systems and OS X just happens to be one of them.

That said, ddrescue works at the raw drive level, Phoenix works at the file system level. Which one would work better? It's a total crap shoot.

ddrescue will attempt to do a binary block recovery of every sector on a drive. If the data is garbage it will zero the sector leaving it in the middle of a file with possibly unpredictable results, especially if the file is something like a dynamic library that gets loaded by the system. That's a VERY serious problem.

Phoenix can attempt to recover the file but I don't know what the algorithms are, but if it succeeds it should be a good file. What Phoenix recovers can almost be guaranteed to be usable. I think the real difference would be that Phoenix would explicitly tell you which files failed and I'm not sure ddrescue would (I don't know.)

Any way you look at it, you're going to be losing data. Disk Utility won't allow you to do this because if you try to use it to clone a drive it will fail any time it encounters bad sectors. If the SMART status is registering a failure, which it is, I'm not even sure it would allow you to proceed with the operation.

One way to circumvent a SMART check might be to put the drive into an external enclosure as gdbolling suggested above(USB, FireWire) and unload any SAT SMART drivers if you're using them. This would stop Disk Utility from getting the SMART status of the drive and you may be able to get away with performing some operations on the drive with it if you need to. Don't hold your breath though, a failing drive is a failing drive.

If the drive failure is due to a one time serious head crash it may be able to be put back into use by partitioning out the bad sectors, but as old as the drive is the failures may actually be the signs of mechanical wear causing the heads to drag across the platters, and such a failure will just continue to get worse and worse.
 
Last edited:
ddrescue will attempt to do a binary block recovery of every sector on a drive. If the data is garbage it will zero the sector leaving it in the middle of a file with possibly unpredictable results, especially if the file is something like a dynamic library that gets loaded by the system. That's a VERY serious problem.

Phoenix can attempt to recover the file but I don't know what the algorithms are, but if it succeeds it should be a good file. What Phoenix recovers can almost be guaranteed to be usable. I think the real difference would be that Phoenix would explicitly tell you which files failed and I'm not sure ddrescue would (I don't know).

The ddrescue log file contains a list of bad sectors.

If there is a tool for HFS that will tell you which file is using a given sector, you could build the list of bad files easily. (Such tools exist for other filesystems, perhaps one of the existing OSX utilities has a "lookup by sector" feature.)

The OP said that it was a sample/project drive, not an OS drive. If any applications are installed on the drive, it would be a good idea to reinstall them.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.