Using ddrescue to recover a broken drive. Can I check the progress before the run is complete?

I am currently running ddrescue on a drive that failed on me. It's been running for maybe 16 hrs now and is still in the splitting failed blocks stage but has been running at 0 B/s for sometime now. I am copying directly onto another drive, not making an image.

Can I check to see what progress has been made or will that upset something? There is only one project on the failed drive that I really need, I just want to check if those files have copied over yet.

The command I ran was:

ddrescue -d -f -v /dev/sda5 /dev/sdc2 /media/username/USB/rescue.logfile

I am running on Ubuntu, and the old drives OS was Arch if that matters.

Solution 1:

In theory you can terminate (ctrl+C) ddrescue and run it later with the same logfile to make it continue rather than start over. I have seen some posts claiming that this method not always works – in these cases ddrescue ignored former work and started from the beginning for the reason unknown.

Try to mount the target partition read-only:

sudo mount -o ro /dev/sdc2 /mnt/foo

As read-only, it shouldn't mess with ddrescue operation. There is a risk that data crucial for the filesystem is not recovered yet, in this case mount will fail. With some luck you may be able to mount, then read the files you need, yet the files may be corrupted even if you get no error from mount and (e.g.) cp. Inspect them or their copies. Do not terminate ddrescue unless you make sure the files are valid and without non-recovered/messed fragments inside.

In case of any problems you can wait for ddrescue to recover more data (if any). I wouldn't wait for the non-corrupted files to appear under the mountpoint, because the system may cache the metadata or the files themselves, etc. Do umount, wait for more data recovered, mount again and check the files.

Edit: answering additional questions.

Is there a way to tell ddrescue to specify a particular folder?

No. The tool works on block level. It knows nothing about filesystem and files. Your statement "ddrescuelog says 99.73% of my files have been recovered" should say "99.73% of the blocks".

Also, is it possible that the data has been recovered, since it is saying 99.73% rescued, but it is just too damaged to be recognized as files? If this is the case is there some program to view damaged files, maybe I can recover some of it manually.

Possible scenario: file content is recovered but corresponding filesystem entry is not (note: in general the opposite is also possible, but obviously it is not your case). You said the whole folder is gone. I think some of the files may appear in lost+found after fsck (or in a similar way depending on your filesystem – I don't know what it is).

More information here: What is the purpose of the lost+found folder in Linux and Unix?

This fsck operation is not read-only, it shouldn't be performed when ddrescue is working. Terminating ddrescue, running fsck and resuming ddrescue is also a bad thing to do. It is better to wait for ddrescue to finish. It may take some time – read this and this.

In general you should work with fsck (or any other non-readonly tool) on a copy of your recovered data. Good way to go, for future reference:

1. Write to a file, not a device. Use a filesystem with copy-on-write (COW) feature.
2. Make a COW copy with cp --reflink=always. You can do this during ddrescue operation. This copy is like a snapshot of your target file.
3. Use any tool(s) on the copy, including non-readonly ones.
4. In case of a failure you still have the original target file (maybe with more data recovered, if ddrescue is still running) to start over with another COW copy (and maybe with different tools).

You may also try to search for deleted files and undelete them. The choice of a tool depends on the filesystem.

Another hint: maybe your software was using temporary files somewhere else in filesystem hierarchy. Check /tmp/, /var/tmp/.

Edit, answering additional question.

When ddrescuelog says 99.73% of the blocks have been rescued what does that mean exactly? It sounds like I should expect some results not an empty home drive.

Note: an example below is not meant to cover all filesystem issues and scenarios, nor to distinguish disk sectors from filesystem allocation units; it is to answer the question only.

Imagine your partition being a book – an encyclopedia, not a novel with a plot. Files are articles within. Disk block (or sector) is like a page in the book. Filesystem is a general way to place articles on pages. Some pages hold the Table of Contents (ToC) which is a filesystem issue in our picture and may look something like that:

article #289: pages 2076, 2077, 2078, 402, 403.

Note that this article is fragmented as a file can be. On another page, yet still within ToC we have something like folder structure:

…
people/: see ToC on page 43.
…
(page 43)
mathematicians/: see ToC on page 80.
famous Poles/: see ToC on page 82.
Adam and Eve: see article #14.
…
(page 80)
Euclid: see article #289.
Banach Stefan: see article #4380.
…
(page 82)
Banach Stefan: see article #4380.
Kościuszko Tadeusz: see article #2208.
…

This structure is an example of hardlinked files. There are at least two paths that point to a single article: ./people/mathematicians/Banach Stefan and ./people/famous Poles/Banach Stefan. Here I placed the dot at the beginning of each path because my example deliberately hides the information: which section does people/ section belong to? (it may as well be /people/ or /full articles/people/ or /stubs/people/ or /foo/bar/people/).

The ToC may also have a section that says:

"empty" pages: 567, 568, 569, 2070, 2071…

A given page has text on it (i.e. data) even if it doesn't belong to any article existing at a time. This is because an article deletion process affects only Table of Contents. The ToC is the only certain way to tell whether a given page belongs to an article, which article, or it can be treated as empty and overwritten. Moreover: there is no way to spot "empty page" without ToC. It feels strange about encyclopedia to have a blank page to be a part of an article, but the sector full of 0s or spaces or anything else can be a part of a file. It's all about ToC.

Some of your pages (blocks) have not been rescued (yet). Any one of them may be a page with article-data or Toc-metadata. Possibilities:

• Missing block is data block (say, page 2078). You know the path to the article about Euclid and on which pages it is, but one of the pages is blank while it shouldn't. The article is invalid.
• Missing block is metadata block. Some scenarios:
  • You lost track about free space.
  • You know there is ./people/mathematicians/Euclid path but you lack the information on which pages the article is. It is impossible to find the article unless you already know something about it (e.g. an entry about a person most probably has a word "born" in it; PDF files start with "%PDF").
  • You know there is a single article on such-and-such pages but there is no complete path to it. In that case you can place it under lost+found and that is what fsck will do. In our picture there are possibilities (among others):
    • Missing page 80: you know (from page 43) there is mathematicians section (folder), but you don't know the article #289 should be in it under the name "Euclid".
    • Missing page 43: you don't know there should be article #14 about Adam and Eve, nor sections with mathematicians nor famous Poles; but you can see (on page 80) that there is some section with articles about Euclid and Banach, and there is some other section (page 82) with articles about Banach and Kościuszko. This is what may be happening with your /home. The articles (files) are there and may be valid. They cannot be reached by path because you have no Toc of your /home.
• Any combination of the above problems may occur if there are multiple blocks not recovered.
• Missing block may be marked as empty. In this case you lose nothing.