8

I'm trying to rescue data from a failing external USB drive from a friend. The problem with the drive is that it cannot be read, not in windows, not in linux. But I do manage to run ddrescue on the drive and build an image of the drive for later processing.

However, I started the process in January this year, and it has been running non stop, and still running. So over 5 months now. First it was running at about 2000 b/s, now it fell back to 200 b/s. It rescued about 27gb of data (drive is 2TB) and according to friend this is also more or less the amount of data that was stored on the drive. The rescued size is still increasing, but veeeeeeeeeery slowly. Eg in the past 3 weeks it increased by 200mb.

Is there any way to stop the process and just continue with what has been rescued until now, or does ddrescue really has to complete the entire process in order to work with the img file ?

Today ddrescue stopped, because the drive went missing. Below is a picture of what I have on the screen, with ddrescue log viewer running, not sure if it gives an idea of the situation. I restarted ddrescue and it's running again at the same slow speed as before. enter image description here

Baz
  • 81
  • 2
    similar question: https://unix.stackexchange.com/q/366901/30851 - but every failure is different, sometimes it's just a dead drive. – frostschutz May 29 '17 at 18:02
  • 1
    I'm sure you meant MB=megabyte and not mb=milibits... (sorry, had a teacher who harped on this, so I can't help myself... ;-) – Baard Kopperud May 29 '17 at 18:04
  • If I read your screenshot correctly it's no longer running btw. ("input file disappeared") – frostschutz May 29 '17 at 18:05
  • Yes, correcy Baard Kopperud :) And also correct frostschutz. I restarted the command, and it's running again now, still at the same slow speed.

    At this point I'm not so interested anymore in processing the full drive, as my friend says there was only around 25-30GB on the drive. So the amount rescued is already a lot, if it can all be read.

    Can I work with the img file before ddrescue finished processing, or should I wait until it reaches 100% completion?

    Can I switch to the extra parameters in the command now, or does that mean I have to start all over again?

     – Baz May 29 '17 at 18:10
  • You can change the parameters and keep the log file so it doesn't start again from scratch. On a drive like that, it's also worth trying to run ddrescue backwards. BTW you wrote it's an external USB drive... did you try removing the drive from its case (probably SATA) and using a brand new SATA-to-USB cable? – Andrea Lazzarotto May 30 '17 at 23:30

2 Answers2

5

You should probably wait until 100% completion before attempting recovery. According to the log viewer, ddrescue has managed to recover a scattering of blocks from various parts of the disk (the green areas), has found bad sectors in many areas (the red areas), and hasn't even looked at large parts of the disk (the yellow and blue areas).

The viewer shows the first part of the disk as having bad sectors. This means that ddrescue hasn't managed to recover the filesystem header or related metadata. Additionally, most filesystems scatter their data around the disk for performance reasons, so it's unlikely that many of the sectors that have been recovered correlate with the sectors that have data on them.

You might be able to speed up the "recover the easy parts" phase of ddrescue's operation by passing the --no-scrape or --no-trim options to entirely omit trying damaged sectors, or the --reverse option to read the disk back-to-front. You could also try playing around with values for the --skip-size option to see if larger or smaller values than the default (20 MB for your disk) will speed things up.

Mark
  • 4,244
1

I'm having some improvement by using option: -c, --cluster-size=<sectors> sectors to copy at a time [128] and increasing it to 2048 or 4096. Above some value there is no improvement.

Pietro C
  • 121
  • 1