Ddrescue on macOS?

[toke lahti]

Hi,
Might not be the pest place to ask.
If you can suggest a forum or anything where are discussions about using Ddrescue with macOS, please tell!

I've been trying to clone a bad drive.
I did it in linux, but now my live-OCS does not see the drive at all.
On the other hand windows and macOS do see it after a small delay.

Running Ddrescue on macOS (Sonoma in my case) is quite a bit slower than in linux, but the main annoyance is that somehow in macOS, Ddrescue thinks that the drive size is 9223 PETAbytes!
Which makes using ddrescueview not practical.
Maybe it even wastes time to read that area that does not exist?

Is there a fix for telling Ddrescue the right size?
Or how could I tell it to find the right size by itself?

On linux I've run version 1.23. On mac, I've installed 1.29.1 via Homebrew.

 

[Slartibart]

what file system are you trying to recover? Besides, run in the terminal:

diskutil list

and identify the drive (with its size) you want to recover.

unmount the drive via:

diskutil unmount /dev/disk2recover/ (unmounting /Volumes/disk2recover can fail depending on the drive; unmounting via/dev/ should do the trick 🙃 )

Then use the drive info obtained and provide the size of the disk to recovery, as e.g.:

ddrescue -v -f -n -s500GiB /dev/disk2recover /Volumes/external_emptyssd/hd.dmg ~/your_logfile.log

you can provide the block size ddrescue uses to speed up things, e.g., -b 4096

 

[toke lahti]

what file system are you trying to recover? Besides, run in the terminal:

diskutil list

and identify the drive (with its size) you want to recover.

unmount the drive via:

diskutil unmount /dev/disk2recover/ (unmounting /Volumes/disk2recover can fail depending on the drive; unmounting via/dev/ should do the trick 🙃 )

Then use the drive info obtained and provide the size of the disk to recovery, as e.g.:

ddrescue -v -f -n -s500GiB /dev/disk2recover /Volumes/external_emptyssd/hd.dmg ~/your_logfile.log

you can provide the block size ddrescue uses to speed up things, e.g., -b 4096

First, thank you for replying.

I got the drive recognized by OSC-live by brute force: unpluggin and replugging enough times.
So, I'm running it in linux again.

Owner has said that it was in mbr/ntfs, but there were clues of gpt/exfat.
Problem is that partition table of the drive or MFT of the ntfs partition is the place which is messed up.

With quick OCS run (almost a month ago) and then with a bit of probing with DMDE showed that the file system is not recoverable, so I need to handle the disk as RAW and just find individual files from it.
The results were so partial, that I decided to (finally) get a grab on ddrescue and try to clone the drive "better".

I talked in Reddit about it and I still can't beleive that some people thinks that OSC read the drive "perfectly" in 10 hours and ddrescue can't do any better in 1000 hours.
But since I now know how to still get the drive connected, I will try several options.

The drive is Toshiba's usb-drive without sata-connection.
I've learned that when it gets power, but no connection to computer, its led will stay lit. When the drive notices a problem the led will blink rapidly. And when the data connection is succesful and the drive is read, the led will blink slowly.

When disk showed up in any of 3 os'ses, it was always showing up in GUI and in command line.

I've noticed also that somehow it behaves better, when read backwards.
My command at the moment is:

sudo ddrescue -v -v -v -v /dev/sdc /dev/sdd  ddr-osc.txt -f -n -N --cpass=1 -a 10k -R --mapfile-interval=5

So yes, I'm cloning it to another physical drive.
62% rescued, average speed is now 150kB/s.
But it drops very often under 5kB/s.
Next time I will learn to use Partclone for not to clone the whole drive, just the parts that have real data.
Maybe that's not, on the other hand, possible, when partittion or fs table is messed up?

The real problem with macOS was ddrescueview, which was horroble under macPorts.
And I fing ddrescueview essential to see if the progress is good enough.
Also strange thing that in linux, ddrescue immediately recognises the disk size and in macOS it does not.
You can't use ddrescueview, when it maps 9223 petabytes to a grid. The real blocks are just first few dots.

 

[toke lahti]

you can provide the block size ddrescue uses to speed up things, e.g., -b 4096

Does that keep all data in mapfile, if you change block size in the middle of cloning?