6 ms·

>Even though I was using tar (and not dd, thank you very much) And from that linked article ( https://rachelbythebay.com/w/2011/12/11/cloning/ https://rachelby

>Even though I was using tar (and not dd, thank you very much) And from that linked article ( https://rachelbythebay.com/w/2011/12/11/cloning/ https://rachelbythebay.com/w/2011/12/11/cloning/ ): >Even if you tell it to continue after read errors ("noerror"), you've just silently corrupted something on the target disk. The idea of using `dd` / `ddrescue` is to get the contents of the drive off it ASAP before it fails. You don't want to mount it. You don't even know if the filesystem on it is sane. The priority right now is to get all the bytes off that you can, then analyze it at your leisure to recover what you can. For the same reason you would also not `dd` directly to the new disk. You'd do it to a storage area where you can inspect and manipulate it first. And: >Finally, there is the whole matter of geometry. [...] Will the partition table wind up in the right place? What about the boot sector data and secondary stuff like the locations where your boot loader might be looking? ... is not a problem for the same reason. Once you have the disk image off the failing drive, you're welcome to inspect it and copy individual files off it to the target drive at the filesystem layer (rsync, cp, etc). And so: >Second, you're dealing with individual files. If your tar or rsync (or whatever) fails to read a file due to some disk issue, you'll know about it. This is the right idea. It's just not optimal to do it from the failing drive itself.

djbusby 2y ago
I generally dd to an image file. (dd of=/data/bad-drive.dump) Then try tools to inspect fix the partition and FS, mount that and then rsync. That's what you're saying too, right?
- Arnavion 2y ago
  Yes, exactly.
  - MadnessASAP 2y ago
    Nevermind trying to copy off of a failed drive that's still in use. Madness! Madness I say!
- fencepost 2y ago
  ddrescue might be a good change for you, in particular specifying to not retry (because you're going to come back later) and to specify the 'log' file that's actually a map of every sector on the source drive and whether it's been successfully imaged. I don't think I've ever imaged an SSD, but for HDDs your ideal is a single pass through with no retries on bad blocks, possibly skipping ahead if you hit a bad block, and a log file writing to the destination drive where you're also storing the image in a file (NOT doing direct output of the input disk). This gets you everything you can get with minimal disruption of the source. After that first run you'll specify the same log file for every time you run it, and (on HDDs) you can tell it to do things like trying to read the higher-numbered sectors first (so if you got an error on block 10,000 and told it to skip 100 on errors, now you start at 10,099 and work backwards, perhaps getting down to 10,005 before you get another error. Basically, get the dropped fruit, then the low-hanging fruit, then work harder for anything remaining. Before you do those followup runs though, it's a good idea to look at things with the 'ddrutility' tools to see if you even need to bother. ddru_findbad will let you use the image file and 'log' file to identify what files might have pieces missing so you can decide if you need to progress further; ddru_ntfsfindbad does basically the same thing for NTFS volumes. It's always nice to determine that 1) yes there's a chunk of bad blocks and 2) we don't have to care because they're all in the Hibernation file so we can restore that image to a new drive, boot, disable and re-enable hibernation just to be cautious, and have no concerns about lost data on the old drive without having to beat the crap out of the drive hoping that on the 1000th attempt it's finally going to read that one failing sector. sorry if the latter part of that got preachy, I've seen some bad advice in the past on imaging failing drives and it's made me sensitive....
  - RGamma 2y ago
    I recently had the pleasure to work with ddrescue. Unfortunately the SSD disappeared on encountering read errors and could only be brought back by power cycling (at least as far as I found out in the time allotted) :/, so it went to my 'defect hardware' pile.
Sakos 2y ago
My god, that article is actually filled with terrible advice. I hope they don't do this professionally. It's bad enough they're misinforming people and directing them to do things in a worse, more fraught failure-prone way. > First of all, 'dd' is going to try to read the entire drive, including the parts which currently do not contain any useful data. This happens because you have probably told it to read /dev/hdc. That refers to the entire readable portion of the disk, including the partition table and the parts which are not associated with living files. Make a sparse image with dd. Then you have a 1:1 copy while skipping all the unused sectors to save space. You can then mount the image read-only or write it to a new disk for recovery. That means that you have all the time in the world and you can start over if need be without affecting the source data. Doing all this on a possibly actively failing drive, particulary an SSD which can literally die 100% into an unrecoverable state without access to a lab in the blink of an eye? That's insanity. And it's even worse SUGGESTING that to random people who don't know any better. You want to read everything off the SSD or HDD once. As fast as possible. As completely as possible. In fact, make sure you do a non-trim pass first, so you can be sure you have as much as possible before you try retrying sectors which might actually kill the drive dead. Once all the recoverable data is off the failing drive as an image, you're free to do whatever you want however you want without fear of any data loss caused by possible mistakes, oversights, hardware issues, etc.
- 1992spacemovie 2y ago
  > My god, that article is actually filled with terrible advice. I hope they don't do this professionally. That’s pretty par for Rachel by the bay. Her blog is basically just HN-endorsed ramblings at this point.
- derefr 2y ago
  > 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 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.

djbusby 2y ago

I generally dd to an image file. (dd of=/data/bad-drive.dump) Then try tools to inspect fix the partition and FS, mount that and then rsync. That's what you're saying too, right?

Arnavion 2y ago
Yes, exactly.
- MadnessASAP 2y ago
  Nevermind trying to copy off of a failed drive that's still in use. Madness! Madness I say!
fencepost 2y ago
ddrescue might be a good change for you, in particular specifying to not retry (because you're going to come back later) and to specify the 'log' file that's actually a map of every sector on the source drive and whether it's been successfully imaged. I don't think I've ever imaged an SSD, but for HDDs your ideal is a single pass through with no retries on bad blocks, possibly skipping ahead if you hit a bad block, and a log file writing to the destination drive where you're also storing the image in a file (NOT doing direct output of the input disk). This gets you everything you can get with minimal disruption of the source. After that first run you'll specify the same log file for every time you run it, and (on HDDs) you can tell it to do things like trying to read the higher-numbered sectors first (so if you got an error on block 10,000 and told it to skip 100 on errors, now you start at 10,099 and work backwards, perhaps getting down to 10,005 before you get another error. Basically, get the dropped fruit, then the low-hanging fruit, then work harder for anything remaining. Before you do those followup runs though, it's a good idea to look at things with the 'ddrutility' tools to see if you even need to bother. ddru_findbad will let you use the image file and 'log' file to identify what files might have pieces missing so you can decide if you need to progress further; ddru_ntfsfindbad does basically the same thing for NTFS volumes. It's always nice to determine that 1) yes there's a chunk of bad blocks and 2) we don't have to care because they're all in the Hibernation file so we can restore that image to a new drive, boot, disable and re-enable hibernation just to be cautious, and have no concerns about lost data on the old drive without having to beat the crap out of the drive hoping that on the 1000th attempt it's finally going to read that one failing sector. sorry if the latter part of that got preachy, I've seen some bad advice in the past on imaging failing drives and it's made me sensitive....
- RGamma 2y ago
  I recently had the pleasure to work with ddrescue. Unfortunately the SSD disappeared on encountering read errors and could only be brought back by power cycling (at least as far as I found out in the time allotted) :/, so it went to my 'defect hardware' pile.

Sakos 2y ago

My god, that article is actually filled with terrible advice. I hope they don't do this professionally. It's bad enough they're misinforming people and directing them to do things in a worse, more fraught failure-prone way. > First of all, 'dd' is going to try to read the entire drive, including the parts which currently do not contain any useful data. This happens because you have probably told it to read /dev/hdc. That refers to the entire readable portion of the disk, including the partition table and the parts which are not associated with living files. Make a sparse image with dd. Then you have a 1:1 copy while skipping all the unused sectors to save space. You can then mount the image read-only or write it to a new disk for recovery. That means that you have all the time in the world and you can start over if need be without affecting the source data. Doing all this on a possibly actively failing drive, particulary an SSD which can literally die 100% into an unrecoverable state without access to a lab in the blink of an eye? That's insanity. And it's even worse SUGGESTING that to random people who don't know any better. You want to read everything off the SSD or HDD once. As fast as possible. As completely as possible. In fact, make sure you do a non-trim pass first, so you can be sure you have as much as possible before you try retrying sectors which might actually kill the drive dead. Once all the recoverable data is off the failing drive as an image, you're free to do whatever you want however you want without fear of any data loss caused by possible mistakes, oversights, hardware issues, etc.

1992spacemovie 2y ago
> My god, that article is actually filled with terrible advice. I hope they don't do this professionally. That’s pretty par for Rachel by the bay. Her blog is basically just HN-endorsed ramblings at this point.
derefr 2y ago
> 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 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.