I generated a domain_logfile with

ddru_ntfsbitmap /dev/sdc1 ddru_ntfsbitmap.mapfile

(This way ddrescue knows, which blocks are empty and don’t need to be read)

Then I ran ddrescue:

ddrescue --sparse --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile

But after a very short time ddrescue froze and I disconnected the drive.

This is an excerpt from the log: https://danielhammocks.uk/Collabin/#18092022KLBkvwn1

I tried it again:

ddrescue --no-scrape --no-trim --idirect --sparse --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile

it froze again. Then I tried different --input-positions, So that I could overcome the part on the HDD, which caused the freeze:

ddrescue --no-scrape --no-trim --idirect --sparse -i 3333 --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile

ddrescue --no-scrape --no-trim --idirect --sparse --input-position 3333 --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile

ddrescue --no-scrape --no-trim --idirect --sparse --input-position 993333 --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile

ddrescue --no-scrape --no-trim --idirect --sparse --mapfile-interval 30s --timeout 2m--input-position 993333 --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile
ddrescue --no-scrape --no-trim --idirect --sparse --mapfile-interval 30s --timeout 2m --input-position 993333 --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile
ddrescue --no-scrape --no-trim --idirect --sparse --mapfile-interval 30s --timeout 1m --input-position 99999999999 --domain-mapfile=ddru_ntfsbitmap.domain_mapfile /dev/sdc1 sdc1.img mapfile

That last one worked and finished:

rescued: 0 B, tried: 0 B, bad-sector: 0 B, bad areas: 0

Current status
     ipos:    1000 GB, non-trimmed:        0 B,  current rate:    393 kB/s
     opos:    1000 GB, non-scraped:        0 B,  average rate:    125 MB/s
non-tried:        0 B,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:  866603 MB,   bad areas:        0,        run time:  1h 55m  3s
pct rescued:  100.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Copying non-tried blocks... Pass 1 (forwards)
Finished

I compared the mapfile I got from ddrescue with the one I generated from the ntfs filesystem and was shocked to see that there was an offset. The ddrescue mapfile: The ddrescue mapfile

There the Block is 6718

The ntfs mapfile: The ntfs mapfile

and here the block is 8817. But both report the same Start 0x123BAAE000 and Length.

I compared the two mapfile outputs and there are some differences: https://www.textcompare.org/?id=62adebff3cb0dd7a1816303b

(thanks @Zerush@Zerush@lemmy.ml for the recommendation of textcompare )

However other parts are identical.


Now to my Questions:D

Is this offset bad? Can I continue to use ddrescue and try to get the remaining parts, where ddrescue froze? How can and should I correct it? Whats the cause? I read that

Modern [HDDs] tend to handle the simple BadBlocks automatically, for example by writing a disk sector that was read with difficulty to another area on the media. […] such a remapping can be done by a disk drive transparently

https://www.smartmontools.org/wiki/BadBlockHowto

Was the slow freezing of ddrescue caused by the drive trying to read bad blocks and reallocating them somwhere else? Was it stupid to unplug the USB-HDD while ddrescue was freezed? Did this cause the mismatch of the mapfile I generated from ntfs with the one generated during the ddrescue run?

Or was the mismatch caused by the input-positions not aligning to the Blocks on disk? Or because I used the --sparse option, so 0 values will be compressed on disk?

(This was my source, on how to use ddrescue: https://wiki.ubuntuusers.de/gddrescue/ )