A relative’s laptop came back from a Göreme trip in September with a swollen battery and a 480 GB SSD that would mount read-only. The drive held roughly 61,000 CR2 files and 14,000 JPEGs from eight years of trips, about 390 GB. The laptop had been left in a car overnight near Ürgüp; condensation got in, then the machine was powered on cold the next morning. SMART showed reallocated sectors climbing from 0 to 1,240 in ten minutes of idle. I told them to stop plugging it in, which is the only advice that mattered.
I put the SSD in a USB 3.0 bridge with an external 5 V supply and attached it to a Linux box with libata.force=noncq on the kernel command line, which has saved me on two other dying drives. Then I used ddrescue with a mapfile, two passes, no retries on the first:
sudo ddrescue -f -n -b 4096 /dev/sdb /mnt/backup/trip.img /mnt/backup/trip.map
sudo ddrescue -f -r3 -b 4096 /dev/sdb /mnt/backup/trip.img /mnt/backup/trip.map
First pass took 6h40m and rescued 388 GB; the second took another 3h and recovered 1.1 GB more. About 700 MB never came back, concentrated in one 10 GB region where the platters had physical damage. I mounted the image read-only with mount -o ro,loop,offset=$((2048*512)) and ran exiftool -r -if '$fileType eq "CR2"' -p '$directory/$filename' . to list what was readable before copying anything, because copying 55k files to a healthy disk just to find out half are truncated wastes a day.
The reason for the two-pass approach is that a damaged drive responds worse the longer it stays powered. The first pass maps the good regions fast without hammering bad sectors; the second only revisits what failed. The cost is that you need free space equal to the whole drive plus the image, and the mapfile means you can resume after a power cut or a controller reset — which happened twice here, both times after about 40 minutes of continuous reads.
Where this falls apart: ddrescue cannot help if the bridge itself resets the USB link, which some cheap SATA-USB chips do under sustained load. I hit that on an earlier job and had to move to a direct SATA port. Also, if the filesystem metadata lives in the damaged region, you get a perfect image of a filesystem you cannot mount, and then you are into photorec, which loses filenames — for a photo archive that is a real loss, since the date is often only in the filename. Here the metadata survived, so I could rebuild folder structure, but I would not count on that twice.
One thing I am still unsure about: the recovered CR2 files pass exiftool but roughly 40 of them fail to decode in darktable with a truncated-file error, so checksums are not enough to call a file good. Has anyone found a cheap way to validate raw files after recovery without opening each one by hand?
0 条评论
还没有评论，写下第一条。