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:
There the Block is 6718
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/ )