Good Morning, I am currently helping a good friend to recover her broken 1TB external HDD. She dropped the drive and now, it cannot be mounted anymore. After some research I gave safecopy a try. I am working with a Kali Linux live CD and an internal 3TB HDD that is connected and mounted via USB station. The external drive has less than 100GB space occupied. SafeCopy collects ~30GB per day. My first try aborted after ~260GB with an "location not found" error, the drive has reconnected to another mount path. The current try is at ~280GB. Since the drive is brand new, all stored data should already be collected in the output ISO. However, when I try to mount the 260GB ISO I get an file error, something about corrupted file and I/O error I used this command for safecopy: sudo safecopy --stage1 /dev/sda1 /path/to/3tb/drive/data.iso /dev/sda1 is the place where the external HDD is detected. Is there a way to manually finish the build of the ISO file? This would save me a lot of time, since safecopy would need ~34 days to complete the job. EDIT: As mentioned in the comments, I had to abort the process for some time. I've now set it all up again and after some difficulties, this is what fdisk produced: sudo fdisk -l /dev/sdc1 Disk /dev/sdc1: 931.5 GiB, 1000169537536 bytes, 1953456128 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x69205244 Device Boot Start End Sectors Size Id Type /dev/sdc1p1 ? 218129509 1920119918 1701990410 811.6G 72 unknown /dev/sdc1p2 ? 729050177 1273024900 543974724 259.4G 74 unknown /dev/sdc1p3 ? 168653938 168653938 0 0B 65 Novell Netware 386 /dev/sdc1p4 2692939776 2692991410 51635 25.2M 0 Empty Partition table entries are not in disk order. I forgot to save the stage1.badblocks file, so I cannot really continue the first run. I now started a new stage1 safecopy run, hope it will be a bit faster than before since I now run a Debian Linux directly from this notebook. Since then, is there a way to use the iso files from the first run and make it readable? EDIT2: Ok, after 3 hours, this is the output so far: (+0){XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX 8-X 0% the drive makes terrible clicking noises. If I interprete the fdisk output form earlier, the data seems to be written way more back on the drive, not from sector 0 onwards. Is it possible to read and rescue the data by starting at the end of the disk? I fear I am more or less dependant on extracting the data from the iso file I created so far. Again, i it somehow possible to extracxt portions from an unfinished iso file and build a valid one from it? EDIT 3: I now tried ddrescue. It now runs for ~ 23h. The output file has a size of 134MB, the size I already knew from safecopy to be ok. gmesg | tail produces the following output: [80840.705000] usb 2-1.1: reset high-speed USB device number 8 using ehci-pci [80880.711821] usb 2-1.1: reset high-speed USB device number 8 using ehci-pci [80920.718561] usb 2-1.1: reset high-speed USB device number 8 using ehci-pci [80922.888408] sd 8:0:0:0: [sdb] Unhandled error code [80922.888413] sd 8:0:0:0: [sdb] [80922.888415] Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK [80922.888417] sd 8:0:0:0: [sdb] CDB: [80922.888419] Read(10): 28 00 49 a5 38 80 00 00 08 00 [80922.888426] end_request: I/O error, dev sdb, sector 1235564672 [80922.888430] Buffer I/O error on device sdb1, logical block 154445328 So what I can see there is that there are difficulties with the usb access and something with hostbyte=DID_TIME_OUT dd has this output so far: rescued: 123928 kB, errsize: 0 B, current rate: 12976 kB/s rescued: 134742 kB, errsize: 39649 kB, current rate: 0 B/s ipos: 635829 MB, errors: 605, average rate: 1688 B/s ago opos: 635829 MB, run time: 22.17 h, successful read: 22.01 h ago Copying non-tried blocks... Pass 1 (forwards) After dd has finished I will try to extract at least a little bit with tsk_recover from the dd image. As mentioned in the comments I looked up the hardware specs of the drive. THe problem is that the USB connector (USB 3.0 Type B Micro) is placed on the main PCB so I cannot access a ATA/SATA connection. Or at least thats what I found out (I didn't open the case so far). I couldn't find a data sheet with circuit diagram. The product number is WDBHHG0010BBK-04. I found a video of a similar looking (!) drive that has pins next to the usb port. I don't know enough about hard drives and electronics to see if I could use these. As soon as dd finished I will open the case. I am asking myself what could have damaged the drive that bad. My friend told me she just dropped it. It seems like the rw head is damaged or has smashed the disk. As far as I know, HDDs move their heads aside while idle or powered off. My attempts of rescue seem to have not dealt much more damage since the result of readable sectors are the same as from the start. So, much text. my current question is what the syslog entries should tell me. Some Pics of the drive:

I've got a 2.5 inch 5200RPM 320G HDD to recover data from. As I've been told, a child has stepped on the laptop and broke it. They gave me the laptop and motherboard seems to be completely fine. There's no any signs of being stepped on. The HDD also seems fine at the first glance. I connected it over a satausb cable and started a ddrescue (without specifying mapfile). It took 13 days to complete the first stage and go to trimming. At that point, ddrescue told that 99.39% of disk was rescued, but unfortunately, the disk moved and the fragile connection broke, leaving me with I/O errors and this message:

ipos:    8623 MB, non-trimmed:  837763 kB,   current rate:       0 B/s                                                                                                                                         
     opos:    8623 MB, non-scraped:    1095 MB,   average rate:    280 kB/s                                                                                                                                         
non-tried:        0 B,  bad-sector:    2449 kB,     error rate:   13824 B/s                                                                                                                                         
  rescued:  318137 MB,   bad areas:       4784,       run time: 13d  3h 34m                                                                                                                                         
pct rescued:   99.39%, read errors:     45_212, remaining time: 19d 16h 16m                                                                                                                                         
                               time since last successful read:          6s                                                                                                                                         
Trimming failed blocks... (forwards)                                                                                                                                                                                
ddrescue: /dev/sda: Unaligned read error. Is sector size correct?

For now, I've started the ddrescue again on the same outfile, but as far as I know, it will take another 13 days to scan it through. I'm aware that it's a bad idea to connect it over such cable and without mapfile, but I thought that the process will be faster. Anyways, I have a backup outfile for any experiments and I think that 99.39% is pretty much enough, so I'd like to try to mount the file and take a look at the data inside. Unfortunately, I cannot:

[root@foxserver ~]# mount -o loop sda.iso /mnt/iso
mount: /mnt/iso: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

What I tried so far: 1. ntfsfix. It couldn't recover and told me to use chkdsk. 2. fsck. But I couldn't even run it, it just always prints the help message no matter what options I pass. I've got another 2.5 inch 320GB HDD and I could try to write this image to that disk, boot into windows installation and try to chkdsk, but I don't really want to, because I'd like to use free, libre and open source software to do my job.

New here but hopefully my question will be helpful to others. I'm trying to recover a very old CD. There are total 15 files (out of many, many) that are unreadable by Windows copy. I've used a tool called Roadkil's Unstoppable Copier on 3 of those files, and it successfully reconstructed 2 of them, which is impressive (the 3rd file was really small - 1 Kb - and its corresponding sectors were giving read error as per Unstoppable Copier). Equally impressive is ddrescue which has so far managed to rescue 99.93% of the CD - so that 415774 bytes of bad sector is remaining. I was thinking - hypothetically if the actual physical CD had only 415 Kb of unreadable data (which I'm sure is distributed among those 15 files), then Unstoppable Copier's error correction algorithm would be able to reconstruct those files with much higher probability. Hence my question - suppose there's some bad sectors still remaining after ddrescue's 3 retries, they get filled with zeroes in the resulting .iso file. If I mount that .iso image in a virtual drive and run Unstoppable Copier on it, it won't see the bad sectors as "bad" since they're just zeroes. Is there a way to force those residual sectors to be marked "bad" in the resulting .iso file? So that the Copier can try to reconstruct them based on its error correction algorithm?

This question addresses the **first pass** of ddrescue on the device to be rescued. I had to rescue a 1.5TB hard disk. The command I used is: # ddrescue /dev/sdc1 my-part-img my-part-map When the rescue is started (with no optional parameters) on a good area of the disk, the read rate ("current rate") stays around 18 MB/s. It occasionally slows a bit, but then comes back to this speed. However, when it encounters a bad area of the disk, it may slow down significantly, and then it never comes back to the 18 MB/s, but stays around 3 MB/s, even after reading 50 GB of good disk with no problem. The strange part is that, when it is currently scanning a good disk area at 3 MB/s, if I stop ddrescue and restart it, it restarts at the higher reading rate of 18 MB/s. I actually saved about 2 days by stopping and restarting ddrescue when it was going at 3 MB/s, which I had to do 8 times to finish the first pass. My question is: why is it that ddrescue will not try to go back to the highest speed on its own. Given the policy, explicitly stated in the documentation, of doing first and fast the easy areas, that is what should be done, and the behavior I observed seems to me to be a bug. I have been wondering whether this can be dealt with with the option -a or --min-read-rate=… but the manual is so terse that I was not sure. Besides, I do not understand on what basis one should choose a read rate for this option. Should it be the above 18 MB/s? Still, even with an option to specify it, I am surprised this is not done by default. Meta note --------- Two users have voted to close the question for being primarily opinion based. I would appreciate knowing in what sense it is? I describe with some numerical precision the behavior of an important piece of software on an actual example, showing clearly that it does not meet a major design objective stated in its documentation (doing the easy parts as quickly as possible), and that very simple reasoning could improve that. The software is well know, from a very trusted source, with precise algorithms, and I expect that most defects were weeded out long ago. So I am asking experts for a possible known reason for this unexpected behavior, not being an expert myself on this issue. Furthermore, I ask whether one of the options of the software should be used to resolve the issue, which is even more a very precise question. And I ask for a detailed aspect (how to choose the parameter for this option) since I did not find documentation for that. I am asking for facts that I need for my work, not opinions. And I motivate it with experimental facts, not opinions.

So a friend called me in January as his PC couldn't boot into Win10 and ended up in BIOS every time on startup. Since no boot device was found, I removed the SSD from the tower and connected it to my laptop (Ubuntu 23.04) with an USB-caddy. The SSD got mounted as /dev/sda but wasn't visible in the file manager. I then: - checked with "Disks" which showed the drive as "OK" but "Unknown": (this screenshot is from now, but I'm pretty sure it was the same back then) - tried to mount it with mount /dev/sda /mnt - no success - did a SMART check, the result of which I can't remember exactly, but it wasn't really helpful - fdisk -l:

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: PSSD T7         
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 18DA2570-EC92-4A71-A1B7-346EF89B0795

- tried ntfsfix /dev/sda - no success - tried ddrescue -d -r3 /dev/sda /media/user/Samsung T7/copy2.img /media/user/Samsung T7/status2.log twice - first time ended up with an img of 29.7 MB which I tried to recover with photorec, but no success:

# Mapfile. Created by GNU ddrescue version 1.27
# Command line: ddrescue -d /dev/sda /media/user/Samsung T7/copy.img /media/user/Samsung T7/status.log
# Start time:   2024-01-09 22:31:12
# Current time: 2024-01-09 22:31:12
# current_pos  current_status  current_pass
0x00000000     ?               1
#      pos        size  status
0x00000000  0x1BF2976000  ?

second time I kept it running for 16 hours, then interrupted - returned an empty img file - see logs:

# Mapfile. Created by GNU ddrescue version 1.27
# Command line: ddrescue -d -r3 /dev/sda /media/nicu/Samsung T7/copy2.img /media/nicu/Samsung T7/status2.log
# Start time:   2024-01-09 22:38:33
# Current time: 2024-01-10 14:36:39
# Copying non-tried blocks... Pass 5 (forwards)
# current_pos  current_status  current_pass
0x00690000     ?               5
#      pos        size  status
0x00000000  0x00690000  *
0x00690000  0x001E0000  ?
0x00870000  0x00020000  *
0x00890000  0x00970000  ?
0x01200000  0x00020000  *
0x01220000  0x012F0000  ?
0x02510000  0x00020000  *
0x02530000  0x025F0000  ?
0x04B20000  0x00020000  *
0x04B40000  0x04BF0000  ?
0x09730000  0x00020000  *
0x09750000  0x097F0000  ?
0x12F40000  0x00020000  *
0x12F60000  0x12FF0000  ?
0x25F50000  0x00020000  *
0x25F70000  0x25FF0000  ?
0x4BF60000  0x00020000  *
0x4BF80000  0x478B0000  ?
0x93830000  0x00010000  *
0x93840000  0x478B0000  ?
0xDB0F0000  0x00010000  *
0xDB100000  0x478B0000  ?
0x1229B0000  0x00010000  *
0x1229C0000  0x478B0000  ?
0x16A270000  0x00010000  *
0x16A280000  0x478B0000  ?
0x1B1B30000  0x00010000  *
0x1B1B40000  0x478B0000  ?
0x1F93F0000  0x00010000  *
0x1F9400000  0x478B0000  ?
0x240CB0000  0x00010000  *
0x240CC0000  0x478B0000  ?
0x288570000  0x00010000  *
0x288580000  0x478B0000  ?
0x2CFE30000  0x00010000  *
0x2CFE40000  0x478B0000  ?
0x3176F0000  0x00010000  *
0x317700000  0x478B0000  ?
0x35EFB0000  0x00010000  *
0x35EFC0000  0x478B0000  ?
0x3A6870000  0x00010000  *
0x3A6880000  0x478B0000  ?
0x3EE130000  0x00010000  *
0x3EE140000  0x478B0000  ?
0x4359F0000  0x00010000  *
0x435A00000  0x478B0000  ?
0x47D2B0000  0x00010000  *
0x47D2C0000  0x478B0000  ?
0x4C4B70000  0x00010000  *
0x4C4B80000  0x478B0000  ?
0x50C430000  0x00010000  *
0x50C440000  0x478B0000  ?
0x553CF0000  0x00010000  *
0x553D00000  0x478B0000  ?
0x59B5B0000  0x00010000  *
0x59B5C0000  0x478B0000  ?
0x5E2E70000  0x00010000  *
0x5E2E80000  0x478B0000  ?
0x62A730000  0x00010000  *
0x62A740000  0x478B0000  ?
0x671FF0000  0x00010000  *
0x672000000  0x478B0000  ?
0x6B98B0000  0x00010000  *
0x6B98C0000  0x478B0000  ?
0x701170000  0x00010000  *
0x701180000  0x478B0000  ?
0x748A30000  0x00010000  *
0x748A40000  0x478B0000  ?
0x7902F0000  0x00010000  *
0x790300000  0x478B0000  ?
0x7D7BB0000  0x00010000  *
0x7D7BC0000  0x478B0000  ?
0x81F470000  0x00010000  *
0x81F480000  0x478B0000  ?
0x866D30000  0x00010000  *
0x866D40000  0x478B0000  ?
0x8AE5F0000  0x00010000  *
0x8AE600000  0x478B0000  ?
0x8F5EB0000  0x00010000  *
0x8F5EC0000  0x478B0000  ?
0x93D770000  0x00010000  *
0x93D780000  0x478B0000  ?
0x985030000  0x00010000  *
0x985040000  0x478B0000  ?
0x9CC8F0000  0x00010000  *
0x9CC900000  0x478B0000  ?
0xA141B0000  0x00010000  *
0xA141C0000  0x478B0000  ?
0xA5BA70000  0x00010000  *
0xA5BA80000  0x478B0000  ?
0xAA3330000  0x00010000  *
0xAA3340000  0x478B0000  ?
0xAEABF0000  0x00010000  *
0xAEAC00000  0x478B0000  ?
0xB324B0000  0x00010000  *
0xB324C0000  0x478B0000  ?
0xB79D70000  0x00010000  *
0xB79D80000  0x478B0000  ?
0xBC1630000  0x00010000  *
0xBC1640000  0x478B0000  ?
0xC08EF0000  0x00010000  *
0xC08F00000  0x478B0000  ?
0xC507B0000  0x00010000  *
0xC507C0000  0x478B0000  ?
0xC98070000  0x00010000  *
0xC98080000  0x478B0000  ?
0xCDF930000  0x00010000  *
0xCDF940000  0x478B0000  ?
0xD271F0000  0x00010000  *
0xD27200000  0x478B0000  ?
0xD6EAB0000  0x00010000  *
0xD6EAC0000  0x478B0000  ?
0xDB6370000  0x00010000  *
0xDB6380000  0x478B0000  ?
0xDFDC30000  0x00010000  *
0xDFDC40000  0x478B0000  ?
0xE454F0000  0x00010000  *
0xE45500000  0x478B0000  ?
0xE8CDB0000  0x00010000  *
0xE8CDC0000  0x478B0000  ?
0xED4670000  0x00010000  *
0xED4680000  0x478B0000  ?
0xF1BF30000  0x00010000  *
0xF1BF40000  0x478B0000  ?
0xF637F0000  0x00010000  *
0xF63800000  0x478B0000  ?
0xFAB0B0000  0x00010000  *
0xFAB0C0000  0x478B0000  ?
0xFF2970000  0x00010000  *
0xFF2980000  0x478B0000  ?
0x103A230000  0x00010000  *
0x103A240000  0x478B0000  ?
0x1081AF0000  0x00010000  *
0x1081B00000  0x478B0000  ?
0x10C93B0000  0x00010000  *
0x10C93C0000  0x478B0000  ?
0x1110C70000  0x00010000  *
0x1110C80000  0x478B0000  ?
0x1158530000  0x00010000  *
0x1158540000  0x478B0000  ?
0x119FDF0000  0x00010000  *
0x119FE00000  0x478B0000  ?
0x11E76B0000  0x00010000  *
0x11E76C0000  0x478B0000  ?
0x122EF70000  0x00010000  *
0x122EF80000  0x478B0000  ?
0x1276830000  0x00010000  *
0x1276840000  0x478B0000  ?
0x12BE0F0000  0x00010000  *
0x12BE100000  0x478B0000  ?
0x13059B0000  0x00010000  *
0x13059C0000  0x478B0000  ?
0x134D270000  0x00010000  *
0x134D280000  0x478B0000  ?
0x1394B30000  0x00010000  *
0x1394B40000  0x478B0000  ?
0x13DC3F0000  0x00010000  *
0x13DC400000  0x478B0000  ?
0x1423CB0000  0x00010000  *
0x1423CC0000  0x478B0000  ?
0x146B570000  0x00010000  *
0x146B580000  0x478B0000  ?
0x14B2E30000  0x00010000  *
0x14B2E40000  0x478B0000  ?
0x14FA6F0000  0x00010000  *
0x14FA700000  0x478B0000  ?
0x1541FB0000  0x00010000  *
0x1541FC0000  0x478B0000  ?
0x1589870000  0x00010000  *
0x1589880000  0x478B0000  ?
0x15D1130000  0x00010000  *
0x15D1140000  0x478B0000  ?
0x16189F0000  0x00010000  *
0x1618A00000  0x478B0000  ?
0x16602B0000  0x00010000  *
0x16602C0000  0x478B0000  ?
0x16A7B70000  0x00010000  *
0x16A7B80000  0x478B0000  ?
0x16EF430000  0x00010000  *
0x16EF440000  0x478B0000  ?
0x1736CF0000  0x00010000  *
0x1736D00000  0x478B0000  ?
0x177E5B0000  0x00010000  *
0x177E5C0000  0x478B0000  ?
0x17C5E70000  0x00010000  *
0x17C5E80000  0x478B0000  ?
0x180D730000  0x00010000  *
0x180D740000  0x478B0000  ?
0x1854FF0000  0x00010000  *
0x1855000000  0x478B0000  ?
0x189C8B0000  0x00010000  *
0x189C8C0000  0x478B0000  ?
0x18E4170000  0x00010000  *
0x18E4180000  0x478B0000  ?
0x192BA30000  0x00010000  *
0x192BA40000  0x478B0000  ?
0x19732F0000  0x00010000  *
0x1973300000  0x478B0000  ?
0x19BABB0000  0x00010000  *
0x19BABC0000  0x478B0000  ?
0x1A02470000  0x00010000  *
0x1A02480000  0x478B0000  ?
0x1A49D30000  0x00010000  *
0x1A49D40000  0x478B0000  ?
0x1A915F0000  0x00010000  *
0x1A91600000  0x478B0000  ?
0x1AD8EB0000  0x00010000  *
0x1AD8EC0000  0x478B0000  ?
0x1B20770000  0x00010000  *
0x1B20780000  0x478B0000  ?
0x1B68030000  0x00010000  *
0x1B68040000  0x478B0000  ?
0x1BAF8F0000  0x00010000  *
0x1BAF900000  0x43070000  ?
0x1BF2970000  0x00006000  *

- switched to an old Win10 laptop and tried to scan the drive with “AOMEI Partition Assistant Demo Edition”, but it didn't work because an error occurred or the drive wasn't even recognized (I can't remember exactly) - also on the Win10 laptop tried to scan the drive with R-Linux, which failed because of a read error on a sector: - switched back to Ubuntu laptop and also tried there with R-Linux - no succuess - sent the SSD to “KLDiscovery Ontrack” where it was analyzed in a lab (at least that's what they told us). They then wrote to us that 100% of the sectors could be read but were either filled with zeros or some kind of pattern, making it impossible to recover data. (After some time I got unsure if we can trust them and kept trying.) - tried with dd if=/dev/sda of=dump.dd conv=noerror,sync (for details see: https://unix.stackexchange.com/questions/782796/cant-dd-broken-ssd) with disabled UAS, since the dmesg logs implied some issue related to that. - tried again with ddrescue, also with UAS disabled and with another caddy (RSHTECH instead of ugreen). This also returned an img with 29.7 MB, on which photorec also couldn't recover something:

user@ubuntu:~$ sudo ddrescue -d /dev/sda /home/user/Downloads/copy.img /home/user/Downloads/status.log
GNU ddrescue 1.27
Press Ctrl-C to interrupt
     ipos:  118939 MB, non-trimmed:    2276 kB,  current rate:       0 B/s
     opos:  118939 MB, non-scraped:        0 B,  average rate:    1506 B/s
non-tried:  120002 MB,  bad-sector:        0 B,    error rate:      87 B/s
  rescued:   29687 kB,   bad areas:        0,        run time:  5h 28m 28s
pct rescued:    0.02%, read errors:      109,  remaining time:         n/a
                              time since last successful read:  5h 25m 22s
Copying non-tried blocks... Pass 1 (forwards)
     ipos:   68550 kB, non-trimmed:    7495 kB,  current rate:       0 B/s
     opos:   68550 kB, non-scraped:        0 B,  average rate:     770 B/s
non-tried:  119996 MB,  bad-sector:        0 B,    error rate:     364 B/s
  rescued:   29687 kB,   bad areas:        0,        run time: 10h 41m 47s
pct rescued:    0.02%, read errors:      213,  remaining time:         n/a
                              time since last successful read: 10h 38m 41s
Copying non-tried blocks... Pass 2 (backwards)

logs:

# Mapfile. Created by GNU ddrescue version 1.27
# Command line: ddrescue /dev/sda /home/user/Downloads/copy.img /home/user/Downloads/status.log
# Start time:   2024-11-18 10:48:16
# Current time: 2024-11-18 17:43:51
# Copying non-tried blocks... Pass 5 (forwards)
# current_pos  current_status  current_pass
0x02590000     ?               5
#      pos        size  status
0x00000000  0x01C50000  +
0x01C50000  0x00940000  *
0x02590000  0x008C0000  ?
0x02E50000  0x00020000  *
0x02E70000  0x012F0000  ?
0x04160000  0x00020000  *
0x04180000  0x025F0000  ?
0x06770000  0x00020000  *
0x06790000  0x04BF0000  ?
0x0B380000  0x00020000  *
0x0B3A0000  0x097F0000  ?
0x14B90000  0x00020000  *
0x14BB0000  0x12FF0000  ?
0x27BA0000  0x00020000  *
0x27BC0000  0x25FF0000  ?
0x4DBB0000  0x00020000  *
0x4DBD0000  0x478B0000  ?
0x95480000  0x00010000  *
0x95490000  0x478B0000  ?
0xDCD40000  0x00010000  *
0xDCD50000  0x478B0000  ?
0x124600000  0x00010000  *
0x124610000  0x478B0000  ?
0x16BEC0000  0x00010000  *
0x16BED0000  0x478B0000  ?
0x1B3780000  0x00010000  *
0x1B3790000  0x478B0000  ?
0x1FB040000  0x00010000  *
0x1FB050000  0x478B0000  ?
0x242900000  0x00010000  *
0x242910000  0x478B0000  ?
0x28A1C0000  0x00010000  *
0x28A1D0000  0x478B0000  ?
0x2D1A80000  0x00010000  *
0x2D1A90000  0x478B0000  ?
0x319340000  0x00010000  *
0x319350000  0x478B0000  ?
0x360C00000  0x00010000  *
0x360C10000  0x478B0000  ?
0x3A84C0000  0x00010000  *
0x3A84D0000  0x478B0000  ?
0x3EFD80000  0x00010000  *
0x3EFD90000  0x478B0000  ?
0x437640000  0x00010000  *
0x437650000  0x478B0000  ?
0x47EF00000  0x00010000  *
0x47EF10000  0x478B0000  ?
0x4C67C0000  0x00010000  *
0x4C67D0000  0x478B0000  ?
0x50E080000  0x00010000  *
0x50E090000  0x478B0000  ?
0x555940000  0x00010000  *
0x555950000  0x478B0000  ?
0x59D200000  0x00010000  *
0x59D210000  0x478B0000  ?
0x5E4AC0000  0x00010000  *
0x5E4AD0000  0x478B0000  ?
0x62C380000  0x00010000  *
0x62C390000  0x478B0000  ?
0x673C40000  0x00010000  *
0x673C50000  0x478B0000  ?
0x6BB500000  0x00010000  *
0x6BB510000  0x478B0000  ?
0x702DC0000  0x00010000  *
0x702DD0000  0x478B0000  ?
0x74A680000  0x00010000  *
0x74A690000  0x478B0000  ?
0x791F40000  0x00010000  *
0x791F50000  0x478B0000  ?
0x7D9800000  0x00010000  *
0x7D9810000  0x478B0000  ?
0x8210C0000  0x00010000  *
0x8210D0000  0x478B0000  ?
0x868980000  0x00010000  *
0x868990000  0x478B0000  ?
0x8B0240000  0x00010000  *
0x8B0250000  0x478B0000  ?
0x8F7B00000  0x00010000  *
0x8F7B10000  0x478B0000  ?
0x93F3C0000  0x00010000  *
0x93F3D0000  0x478B0000  ?
0x986C80000  0x00010000  *
0x986C90000  0x478B0000  ?
0x9CE540000  0x00010000  *
0x9CE550000  0x478B0000  ?
0xA15E00000  0x00010000  *
0xA15E10000  0x478B0000  ?
0xA5D6C0000  0x00010000  *
0xA5D6D0000  0x478B0000  ?
0xAA4F80000  0x00010000  *
0xAA4F90000  0x478B0000  ?
0xAEC840000  0x00010000  *
0xAEC850000  0x478B0000  ?
0xB34100000  0x00010000  *
0xB34110000  0x478B0000  ?
0xB7B9C0000  0x00010000  *
0xB7B9D0000  0x478B0000  ?
0xBC3280000  0x00010000  *
0xBC3290000  0x478B0000  ?
0xC0AB40000  0x00010000  *
0xC0AB50000  0x478B0000  ?
0xC52400000  0x00010000  *
0xC52410000  0x478B0000  ?
0xC99CC0000  0x00010000  *
0xC99CD0000  0x478B0000  ?
0xCE1580000  0x00010000  *
0xCE1590000  0x478B0000  ?
0xD28E40000  0x00010000  *
0xD28E50000  0x478B0000  ?
0xD70700000  0x00010000  *
0xD70710000  0x478B0000  ?
0xDB7FC0000  0x00010000  *
0xDB7FD0000  0x478B0000  ?
0xDFF880000  0x00010000  *
0xDFF890000  0x478B0000  ?
0xE47140000  0x00010000  *
0xE47150000  0x478B0000  ?
0xE8EA00000  0x00010000  *
0xE8EA10000  0x478B0000  ?
0xED62C0000  0x00010000  *
0xED62D0000  0x478B0000  ?
0xF1DB80000  0x00010000  *
0xF1DB90000  0x478B0000  ?
0xF65440000  0x00010000  *
0xF65450000  0x478B0000  ?
0xFACD00000  0x00010000  *
0xFACD10000  0x478B0000  ?
0xFF45C0000  0x00010000  *
0xFF45D0000  0x478B0000  ?
0x103BE80000  0x00010000  *
0x103BE90000  0x478B0000  ?
0x1083740000  0x00010000  *
0x1083750000  0x478B0000  ?
0x10CB000000  0x00010000  *
0x10CB010000  0x478B0000  ?
0x11128C0000  0x00010000  *
0x11128D0000  0x478B0000  ?
0x115A180000  0x00010000  *
0x115A190000  0x478B0000  ?
0x11A1A40000  0x00010000  *
0x11A1A50000  0x478B0000  ?
0x11E9300000  0x00010000  *
0x11E9310000  0x478B0000  ?
0x1230BC0000  0x00010000  *
0x1230BD0000  0x478B0000  ?
0x1278480000  0x00010000  *
0x1278490000  0x478B0000  ?
0x12BFD40000  0x00010000  *
0x12BFD50000  0x478B0000  ?
0x1307600000  0x00010000  *
0x1307610000  0x478B0000  ?
0x134EEC0000  0x00010000  *
0x134EED0000  0x478B0000  ?
0x1396780000  0x00010000  *
0x1396790000  0x478B0000  ?
0x13DE040000  0x00010000  *
0x13DE050000  0x478B0000  ?
0x1425900000  0x00010000  *
0x1425910000  0x478B0000  ?
0x146D1C0000  0x00010000  *
0x146D1D0000  0x478B0000  ?
0x14B4A80000  0x00010000  *
0x14B4A90000  0x478B0000  ?
0x14FC340000  0x00010000  *
0x14FC350000  0x478B0000  ?
0x1543C00000  0x00010000  *
0x1543C10000  0x478B0000  ?
0x158B4C0000  0x00010000  *
0x158B4D0000  0x478B0000  ?
0x15D2D80000  0x00010000  *
0x15D2D90000  0x478B0000  ?
0x161A640000  0x00010000  *
0x161A650000  0x478B0000  ?
0x1661F00000  0x00010000  *
0x1661F10000  0x478B0000  ?
0x16A97C0000  0x00010000  *
0x16A97D0000  0x478B0000  ?
0x16F1080000  0x00010000  *
0x16F1090000  0x478B0000  ?
0x1738940000  0x00010000  *
0x1738950000  0x478B0000  ?
0x1780200000  0x00010000  *
0x1780210000  0x478B0000  ?
0x17C7AC0000  0x00010000  *
0x17C7AD0000  0x478B0000  ?
0x180F380000  0x00010000  *
0x180F390000  0x478B0000  ?
0x1856C40000  0x00010000  *
0x1856C50000  0x478B0000  ?
0x189E500000  0x00010000  *
0x189E510000  0x478B0000  ?
0x18E5DC0000  0x00010000  *
0x18E5DD0000  0x478B0000  ?
0x192D680000  0x00010000  *
0x192D690000  0x478B0000  ?
0x1974F40000  0x00010000  *
0x1974F50000  0x478B0000  ?
0x19BC800000  0x00010000  *
0x19BC810000  0x478B0000  ?
0x1A040C0000  0x00010000  *
0x1A040D0000  0x478B0000  ?
0x1A4B980000  0x00010000  *
0x1A4B990000  0x478B0000  ?
0x1A93240000  0x00010000  *
0x1A93250000  0x478B0000  ?
0x1ADAB00000  0x00010000  *
0x1ADAB10000  0x478B0000  ?
0x1B223C0000  0x00010000  *
0x1B223D0000  0x478B0000  ?
0x1B69C80000  0x00010000  *
0x1B69C90000  0x478B0000  ?
0x1BB1540000  0x00010000  *
0x1BB1550000  0x41420000  ?
0x1BF2970000  0x00006000  *

dmesg:

[Sa Nov 16 22:35:01 2024] I/O error, dev sda, sector 11924992 op 0x0:(READ) flags 0x800 phys_seg 13 prio class 2
[Sa Nov 16 22:38:02 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:38:02 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:38:02 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:38:02 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:38:02 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 92 30 00 00 00 61 00
[Sa Nov 16 22:38:02 2024] I/O error, dev sda, sector 9580544 op 0x0:(READ) flags 0x800 phys_seg 13 prio class 2
[Sa Nov 16 22:41:02 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:41:02 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:41:02 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:41:02 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:41:02 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 6e 6a 00 00 00 61 00
[Sa Nov 16 22:41:02 2024] I/O error, dev sda, sector 7236096 op 0x0:(READ) flags 0x800 phys_seg 13 prio class 2
[Sa Nov 16 22:44:03 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:44:03 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:44:03 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:44:03 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:44:03 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 4a a4 00 00 00 61 00
[Sa Nov 16 22:44:03 2024] I/O error, dev sda, sector 4891648 op 0x0:(READ) flags 0x800 phys_seg 13 prio class 2
[Sa Nov 16 22:47:04 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:47:04 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:47:04 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:47:04 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:47:04 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 26 dd 80 00 00 80 00
[Sa Nov 16 22:47:04 2024] I/O error, dev sda, sector 2547072 op 0x0:(READ) flags 0x800 phys_seg 16 prio class 2
[Sa Nov 16 22:50:04 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:50:04 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:50:04 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:50:04 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:50:04 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 13 dd 00 00 00 80 00
[Sa Nov 16 22:50:04 2024] I/O error, dev sda, sector 1301760 op 0x0:(READ) flags 0x800 phys_seg 16 prio class 2
[Sa Nov 16 22:53:05 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:53:05 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:53:05 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:53:05 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:53:05 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 0a 5c 80 00 00 80 00
[Sa Nov 16 22:53:05 2024] I/O error, dev sda, sector 679040 op 0x0:(READ) flags 0x800 phys_seg 16 prio class 2
[Sa Nov 16 22:56:06 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:56:06 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:56:06 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:56:06 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready
[Sa Nov 16 22:56:06 2024] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 05 9c 00 00 00 80 00
[Sa Nov 16 22:56:06 2024] I/O error, dev sda, sector 367616 op 0x0:(READ) flags 0x800 phys_seg 16 prio class 2
[Sa Nov 16 22:59:06 2024] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[Sa Nov 16 22:59:06 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=180s
[Sa Nov 16 22:59:06 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Not Ready [current] 
[Sa Nov 16 22:59:06 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Logical unit is in process of becoming ready

- tried photorec directly on the SSD: So now I'm giving up (unless someone has another idea). My question now: is it possible that the data on an SSD can suddenly be zeroed or filled with a pattern (like Ontrack said)? Was it me who caused the issue because of the things/tools I tried or is it possible that this happened already before? Of course I know it's hard to say, but I want to at least try to understand what might have been going on. The SSD (Kingston SA400S37/120G, SBFK71E0) has been used for more than 10 years and my friend had installed a new router before the boot problem occurred and therefore had to plug/unplug some devices to the same socket that the PC was connected to. Is it possible that some voltage peak could have caused the issue? Thanks for any help! **Edit:** Thanks to @telcoM ! The controller most likely blocks the access due to an internal error on the SSD and that's why it's identified as SATAFIRM S11. This seems to be a known thing for those Kingston Models. The only chance to recover some data seems to be with a "PC-3000". For more details see: https://www.elektroda.com/rtvforum/topic3859967.html https://youtu.be/xvBJzIo_PTk The only odd thing remaining is that Ontrack ignored or didn't realize that it's a controller issue and not zeroed data.

I have two ddrescue images created from sequential recovery attempts of the same media. The two images are the same size but have complementary data: $ od part-one/ddrescue_image --skip-bytes 227966006774 --read-bytes 32 3242365232766 113056 016517 102014 074371 144073 000000 000000 000000 3242365233006 000000 000000 000000 000000 000000 000000 000000 000000 3242365233026 $ od part-two/ddrescue_image --skip-bytes 227966006774 --read-bytes 32 3242365232766 000000 000000 000000 000000 000000 124616 163450 064251 3242365233006 074567 134433 012742 022160 044301 054235 140604 020633 3242365233026 How can I merge them into a single, complete image? ## Details - The second image is simply a continuation of the first recovery attempt, à la: $ ddrescue corrupt-partition part-one/ddrescue_image part-one/ddrescue_log $ mkdir part-two; cp part-one/ddrescue_log part-two/ddrescue_log $ ddrescue corrupt-partition part-two/ddrescue_image part-two/ddrescue_log - The second image is almost entirely zeros, but contains 18 KB of recovered data spread across 1847 isolated regions. - I tried using the technique mentioned on this mailing list , $ ddrescue --domain-logfile=part-two/ddrescue_log part-two/ddrescue_image part-one/ddrescue_image part-one/ddrescue_log GNU ddrescue 1.16 Press Ctrl-C to interrupt Initial status (read from logfile) rescued: 937286 MB, errsize: 62976 B, errors: 122 Current status rescued: 937286 MB, errsize: 62976 B, current rate: 0 B/s ipos: 0 B, errors: 122, average rate: 0 B/s opos: 0 B, time since last successful read: 0 s Finished but it doesn't appear to have changed anything.

I have run ddrescue on a disk that has multiple partitions. One of these partitions is an ext4 file system, and several files inside that didn't make it because they have bad blocks. I'd like to give the list of blocks that couldn't be copied to fsck -l, so it is aware of the damage. Is there a readymade tool that can parse the map file, adjust the list of lost blocks by partition offset, and convert to file system block numbers?

I had a burnt disc from the 2000s, I tried backing it up, but it had issues. So went out and purchased another copy, a box set in fact. It was released 20 years ago. When I used dvdbackup some of the .VOB files had issues and wouldn't play. I can't use ddrescue because it doesn't understand what is dodgy data and CSS confusion. The dvds seem to play okay with VLC. I can't find away to get around this, I know VLC has a convert feature, but it doesn't work. Surely there is a way to use ddrescue with CSS or pipe out of something which can can open CSS dvds into something which can do error checking, like rsync? This situation that 'you can have a CSS playing programme or a data recovery/backup programme but not both' seems crazy.

I'm doing a backup operation on a SD-card. This card has been used for almost 8 y with regular write operation. Chances are that it is damaged somehow. That's why I choose ddrescue to get the content. # sudo ddrescue /dev/mmcblk0 /tmp/backup.img ddrescue runs with no perceivable slowdowns (4 GiB) and gives no errors. However I was curious and ran # sudo cmp /dev/mmcblk0 /tmp/backup.img which ends up in a byte differing amid the file. I thought I could do another image and compare them. However the images keep differing from the card and from each other. How comes that I cannot see any errors, warnings or strange behaviour during the rescue operation? dmesg doesn't show any errors either. What should I assume? That a backup isn't possible? What should I do to get an image with most similarities to the original? **Update** I made eight backups, all differ. There is an extremely large number of differences. If I do a cmp -l | wc -l between any two of the eight backups I made, the number is always greater than 100000. So showing the output doesn't make much sense. The differences start from varying points in the file but there seem to be some statistic correlations. I'm not done analyzing that yet.