In addition to the excellent advice from Florian and Antonio:

Knowing the filesystem on this partition would be of great help.

If the partition is NTFS, you can use Ddru_ntfsfindbad from the
*ddrutility* toolset [1] to determine a list of incomplete files from
your copy and the logfile, as Florian wrote. This does not require to
mount the volume.

If Step 1) shows that you're still missing important files, you will
want to make sure to rescue the most important data first. Especially
with a read speed of ~2KB/s.
These are (in that order): Boot sector, Filesystem structures (For NTFS:
$MFT, $Bitmap), lastly any vital user data of which no backup exists
Irrelevant portions which you should exclude are: Unused space, OS
files, program files, temp files, ...
This might bring the remaining 32GB down to a manageable amount, even at

Such selective data rescue is done by creating a domain mapfile and
using it with ddrescue (-m /path/to/domain.map).

Again, you want to have this created by external tools. ddrutility and
partclone can generate Used-Space domain mapfiles. For NTFS, I use
ddru_ntfsbitmap from the *ddrutility* toolset, which can also create a
$MFT-only domain mapfile that you should use first.

Rescuing manually specified sets of files gets a bit more involved. I
have a script for generating such domain mapfiles for NTFS, again with
help from Ddru_ntfsfindbad, but it's not in a publishable state. Let me
know if you need further help.

Kind regards,

[1] https://sourceforge.net/projects/ddrutility

Florian Sedivy wrote:
Hello Jason!

Another possibility would be to generate a file list from the logfile directly. 
How to exactly do that depends on the filesystem used on the damaged volume. I 
already used it for HFS and NTFS in the past.

The general workflow is:
1. Generate a list of „bad blocks“ from the mapfile using ddrescuelog (as 
Antonio wrote you can include all not-rescued statuses, so you don’t need to 
„finish“ the rescue) with --list-blocks='?*/-'
2. Use a filesystem tool to get a file list from that block list.
Details to pay attention to in both steps are offsets, block size, filesystem 
cluster size and such.

This approach is less universal than Fill Mode + grep, but it can be much 
faster, it includes special files not visible in userspace, and it potentially 
works on volumes that won’t mount.

On volumes that are not very full, this technique can also be used in reverse 
at the start of the rescue, to generate a rescue domain that only includes used 
space, or even only a subset of data.

BTW, Antonio: Some filesystem tools produce or expect a volume bitmap (for used 
space mostly). Could ddrescuelog get that as an alternative in-/output format 
in addition to „block list“?

Greetings, Florian

Reply via email to