> You want to read everything off the SSD or HDD once.
I mean, no, not really. You want to read everything off at least once. Because a "corrupt sector" is actually often in a non-deterministic state, reading differently with each read — but that state may still be floating just far enough toward logical 0 or 1, that you can get a bit-pattern out of it through statistical analysis, over multiple reads.
You do want to capture the whole disk once first, in case the disk spindle motor is about to die. (This isn't usually the problem with a dying disk... save for certain old known-faulty disk models — the "DeathStar" et al. But it's good to be safe!)
But after that, you want to read it again, and again, and again. And save the outputs of those reads. And then throw them into a tool like ddrescue that will put the results together.
Basically, it's the same principle that applies to archival preservation of floppy disks (see e.g. https://www.youtube.com/watch?v=UxsRpMdmlGo). Magnetic flux is magnetic flux! (And even NAND cells can end up with approximately the same "weak bits" problems.)
---
Mind you, it'd be even better if we could get several analogue dumps of the disk, and then merge those together using analogue-domain tools, like the ones used for floppy preservation mentioned in the video above.
Sadly, unlike with floppy preservation, it'd be very difficult to get an analogue dump of an HDD or SSD. With floppies, the flux is right there for the reading; you just need a special drive. HDDs and SSDs, meanwhile, are far more self-contained. For an HDD, there might be a path to doing it, at least on a disk-specific basis... it would likely involve tapping some signal lines between the disk controller and the read head. But for an SSD, I don't think it would be possible — IIRC with most NAND/NOR flash packages, the signal is already digitized by the time it comes off the chip.
---
Also, I should mention that if your HDD disk spindle motor is about to die, then you're actually on a bit of a ticking clock. You want to get your data off that disk as quickly as possible, before the motor locks up and the head crashes on the platter.
Tools like ddrescue have the option to first read a disk's filesystem metadata to build a map; and then use that map to only bother to read filesystem-allocated sectors, seeking past any unallocated ones.
Doing this can greatly speed up the time it takes to make a complete copy of "any potentially-useful data on the disk" (as opposed to "the entire disk".) Which means you might be able to get a capture done on a disk "just under the wire" using this method — where otherwise the disk would have died in the middle of reading some unused sectors, with some good data stored further down the disk left un-captured.
But of course, there's the counterpoint that the filesystem metadata itself might have holes in it, where that would mean that the map made by the tool will fail to capture some of the data.
I think this isn't a weighing-pros-and-cons situation, though, but pretty clearly a "right tool for the job" situation:
• If you're getting fsck errors, weird data corruptions, or files are just disappearing — and it's clear that you're going to need to run one of those forensic data recovery programs against the disk image to extract what you can from it — then you'll need the whole disk, including the "seemingly unallocated" parts.
• If all your data seems fine, but you're getting SMART errors, writes are slowing down, and your disk is making funny noises... then you're probably better off grabbing just the filesystem-allocated sectors ASAP, before your drive stops talking to you.
> Tools like ddrescue have the option to first read a disk's filesystem metadata to build a map; and then use that map to only bother to read used sectors, skipping the unused ones.
I don't know how many versions of "ddrescue" there might be, but GNU ddrescue doesn't know anything about filesystems.
The "map" file is just a list of device LBAs (extents) and recovery status.
I've seen a tool for NFTS that can pre-populate a GNU ddrescue map file with unused extents to avoid ddrescue reads of unused areas, but you have to find this tool and manage it yourself.
I mean, no, not really. You want to read everything off at least once. Because a "corrupt sector" is actually often in a non-deterministic state, reading differently with each read — but that state may still be floating just far enough toward logical 0 or 1, that you can get a bit-pattern out of it through statistical analysis, over multiple reads.
You do want to capture the whole disk once first, in case the disk spindle motor is about to die. (This isn't usually the problem with a dying disk... save for certain old known-faulty disk models — the "DeathStar" et al. But it's good to be safe!)
But after that, you want to read it again, and again, and again. And save the outputs of those reads. And then throw them into a tool like ddrescue that will put the results together.
Basically, it's the same principle that applies to archival preservation of floppy disks (see e.g. https://www.youtube.com/watch?v=UxsRpMdmlGo). Magnetic flux is magnetic flux! (And even NAND cells can end up with approximately the same "weak bits" problems.)
---
Mind you, it'd be even better if we could get several analogue dumps of the disk, and then merge those together using analogue-domain tools, like the ones used for floppy preservation mentioned in the video above.
Sadly, unlike with floppy preservation, it'd be very difficult to get an analogue dump of an HDD or SSD. With floppies, the flux is right there for the reading; you just need a special drive. HDDs and SSDs, meanwhile, are far more self-contained. For an HDD, there might be a path to doing it, at least on a disk-specific basis... it would likely involve tapping some signal lines between the disk controller and the read head. But for an SSD, I don't think it would be possible — IIRC with most NAND/NOR flash packages, the signal is already digitized by the time it comes off the chip.
---
Also, I should mention that if your HDD disk spindle motor is about to die, then you're actually on a bit of a ticking clock. You want to get your data off that disk as quickly as possible, before the motor locks up and the head crashes on the platter.
Tools like ddrescue have the option to first read a disk's filesystem metadata to build a map; and then use that map to only bother to read filesystem-allocated sectors, seeking past any unallocated ones.
Doing this can greatly speed up the time it takes to make a complete copy of "any potentially-useful data on the disk" (as opposed to "the entire disk".) Which means you might be able to get a capture done on a disk "just under the wire" using this method — where otherwise the disk would have died in the middle of reading some unused sectors, with some good data stored further down the disk left un-captured.
But of course, there's the counterpoint that the filesystem metadata itself might have holes in it, where that would mean that the map made by the tool will fail to capture some of the data.
I think this isn't a weighing-pros-and-cons situation, though, but pretty clearly a "right tool for the job" situation:
• If you're getting fsck errors, weird data corruptions, or files are just disappearing — and it's clear that you're going to need to run one of those forensic data recovery programs against the disk image to extract what you can from it — then you'll need the whole disk, including the "seemingly unallocated" parts.
• If all your data seems fine, but you're getting SMART errors, writes are slowing down, and your disk is making funny noises... then you're probably better off grabbing just the filesystem-allocated sectors ASAP, before your drive stops talking to you.