I'm an Ubuntu newbie that has tinkered around with it just a tiny bit, but ultimately don't know much about it except how powerful it could be for super users! Also, if this is the wrong place to post this to, any ideas where it would be better suited? Anyway, I have a friend that needs help getting some data off a hard drive that has gone bad on him. Windows is pretty much a lost cause for this type of problem, so I went straight to Ubuntu. (Looks like Parted Magic is no longer open source?)

So I found a couple tutorials, and the one that seems to be working the best can be found here:


I've also played around with this tutorial, but didn't have as much luck with it:


Long story short, from the first tutorial, I determined that the command I should send in terminal would be as follows:

sudo ddrescue -f /dev/sdc /dev/sdb /media/ubuntu/ExtraSpace/Sailor/Sailor.log

When I executed that command, it was the first time that I got ddrescue to start doing its thing. It has now been running for a full day, and is reporting 22% recovered! So I think I'm making progress! (Of course I'll let it run until it's done...maybe 2 or 3 more days)

My question is this though. In the folder /ExtraSpace/Sailor I see a log file. So I believe my log file was created properly. But I'm curious where the data itself (or image file) is being saved? I don't see it anywhere, but I may just not know where to look! I thought a disk image should be created from what I read in that second tutorial...but maybe I executed the command wrong? And for what it's worth, I have made sure that /dev/sdc is the bad drive, and /dev/sdb is the drive, with sufficient space, that I am trying to get data over to.

Thanks for any help you can offer!

  • 1
    Welcome to Ask Ubuntu. Your command said to save it to device /dev/sdb - so you're overwriting whatever was on that drive with what it grabs from /dev/sdc. The format from man ddrescue says "ddrescue [options] infile outfile [mapfile]" so -f was your options, drive sdc was your infile, sdb your outfile and /media/../Sailor.log your mapfile. It's not saved as a file, but being written to a device (drive) as you specified /dev/sdb – guiverc Jan 5 '19 at 4:16
  • Ugh...I was worried about that. So as soon as I saw your comment, I quickly stopped the process. (Pretty sure I have a backup of that drive but also not the end of the world if I lose what's on it.) But, I just booted back into windows, and now windows doesn't recognize the drive that I was copying onto anymore. So I guess I'm really confused at what is going on. What do you mean by "It's not saved as a file, but being written to a device" Is it copying all the files one by one? Should I be seeing lots of files appearing? (Instead of just one image file) Because I wasn't seeing those either. – Trevzilla Jan 5 '19 at 4:49
  • You specified "/dev/sdb" as your "outfile" (output-file), the /dev tells you were specifying a device, so it was written to device sdb. If you'd provided a /directory/path name it would have been written to a file, but /dev means to a device. It was overwriting the whole device with data from your 'infile' or device sdc. Windows (or any OS) needs the partition-table to recognize the disk (with limited exceptions), and if this was overwritten it won't recognize it. It was copying inodes (sectors/blocks) from sdc to sdb; both your disks were 'files' in your command. – guiverc Jan 5 '19 at 5:17
  • In *nix (unix, posix, GNU/linux, etc) everything can be treated as a file. If you look in /dev/ you'll recognize many of your devices, if you use ls -la /dev/ you'll note in the 'type' there are 'c' (character devices), 'b' (block devices which include disks) etc & not just '-' (files) or 'd' directories we see in our usual folders. It allows us to do almost everything (when we know what we're doing; as you noted at the start of your question), but can also mean it's easy to make mistake, as we have no 'safety' net (or nanny safety system telling us we shouldn't do that) – guiverc Jan 5 '19 at 5:34
  • Alright, so it seems as if my problem has now been compounded. Of course I'm a bit trigger shy all of a sudden. I'm just curious what y'all think the next steps should be? I figure maybe reformatting the good drive once again (is the data there as good as gone now?) so that windows will be able to recognize it again. Then trying ddrescue again but this time specifying a path instead of a device? Which commands can I use to just write to some arbitrary directory? And can I use my log file that I've already started creating? – Trevzilla Jan 5 '19 at 9:16


add-apt-repository ppa:hamishmb/myppa
apt-get update
apt-get install ddrescue-gui -y

It might make your life easier. /dev/sdX are block devices, you tried to copy disk-to-disk.

Also try

sudo apt install testdisk
testdisk /dev/sdX

And use the file recovery utilities in there.


If the drive you need to recover data from is dying (as indicated by increasing numbers of bad sectors) any read access will make things worse. In this case a last read with ddrescue may get you an image of the drive you can then safely use for data recovery software.

In all other cases, and if the drive was healthy you can perform recovery directly from that drive. This would be much faster.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.