Hello, In addition to the excellent advice from Florian and Antonio:
Knowing the filesystem on this partition would be of great help. 1) 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. 2) 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 elsewhere. 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 2KB/s. 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, Martin [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
