3

It seems that ddrescue tries to recover all blocks on a disk or partition, even ones that don't contain files. Wouldn't it be possible for it to find out which blocks actually hold files by looking at the filesystem, e.g. master file table on NTFS?

Edit: It seems it might be possible in combination with partclone:

http://partclone.org/features/

For rescue situation, the rescue mode of Partclone would try to skip bad blocks and backup all good blocks for the partitions. The ddrescue program is another better solution to save bad disk while with partclone's help by listing all used blocks as domain file, it could make ddrescue smarter and faster when dumping a partition.

See also: http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[email protected]/

1
  • Are you sure there already isn't possible with perhaps a parameter option?
    – Ramhound
    Jan 17, 2014 at 18:25

5 Answers 5

8

Short answer: because it’s not its purpose. Ddrescue does one thing (1:1 copying a failing HDD), and does it well.

1
  • 1
    Exactly. "Do One Thing and Do It Well" is a part of Unix philosophy. Nov 9, 2016 at 7:48
3

I do not believe this is possible, as ddrescue, like dd itself, is meant to operate on any block device, even those with no filesystem, or a damaged one. Looking at the filesystem if it exists would just complicate it.

3

Old thread but might be helpful to others...

If the input is a NTFS formatted volume, you can use ddru_ntfsbitmap from ddrutility, to generate a mapfile for ddrescue by using the $Bitmap system file, which is precisely a map of the used / unused clusters on a NTFS partition. Of course it requires that the $Bitmap file be intact, located in a fully readable area, to work properly (generally it's located at the begining of the partition). If that is the case it proceeds quickly (in my first and so far only experience it took about 2min. to generate the mapfile from a 1TB partition). Then you run ddrescue with this basic command :

ddrescue [options] [input path] [output path] [logfile] -m [mapfile]

In recent versions of ddrescue, the term “logfile”, as in, the file where the rescued / non-tried / bad areas of the input volume are saved during the recovery, has been replaced with “mapfile”, which makes this quite confusing. So, if for instance you want to recover a HDD called /dev/sdc to an image on /media/sdd1 called Recovery, using a mapfile generated by ddru_ntfsbitmap called Recovery_bitmap.log, the command should be :

ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
1
  • Oh neat, thanks for letting me know about this. Would have been useful a few years ago when I was trying to recover a 3TB disk... I created a short program that would create a map/logfile for ddrescue, marking the unused sectors already recovered. It also allowed specifying file names you didn't need to recover (handy for big files like old VM images, downloaded ISOs, etc.), and would look up their extents and mark them as recovered as well. I should put it up on GitHub or something...
    – CBHacking
    Oct 8, 2017 at 20:46
2

Nowadays it is possible, as the thread mentioned in the question have been implemented. You can use the Parclone utility to create a file which tell what parts should be scanned.

Here is an example of how to use it from the thread mentioned:

# produce a domain file for NTFS partition on /dev/sda1
partclone.ntfs -s /dev/sda1 -D -o sda1.domain
# copy /dev/sda1 to /dev/sdb1 using ddrescue with domain log file
ddrescue --domain-log sda1.domain /dev/sda1 /dev/sdb1 rescue.log
1
  • This really should be the top answer to the question. Wasting time trying to read unused blocks is not "doing it well" if the purpose of ddrescue is to save data from a failing drive, which might not have much useful operating time left.
    – myxal
    May 1, 2023 at 11:14
0

The main reason is probably that it would make ddrescue's code significantly more complex, as it would need to incorporate information on various filesystems, and parse their internal structures.

However, even ignoring the additional development effort, trying to find out which blocks have data is difficult in general. ddrescue is typically used in situations where the data is already damaged and possibly inconsistent. Trying to find used blocks is risky in that situation - what if the list of free blocks itself is corrupted (but still readable)? Or maybe the current version of a file is no longer recoverable, but an old version of the file is still present in free blocks (because the file system did not overwrite in place).

In that case, the only safe option is to grab everything, and sort out the details later.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .