| 1 |
Thanks to both Rich and Grant for suggestions. Part of my issue is |
| 2 |
that I currently have two different failing/failed HDDs to deal with, |
| 3 |
and one of them has two different problems. At this point, although |
| 4 |
there are files I would really love to recover from each of them, it's |
| 5 |
not critical, so I'm taking my time. I'll post more details or at |
| 6 |
least status upste later, depending on how things work out. |
| 7 |
|
| 8 |
On 2018.12.15 19:19, Rich Freeman wrote: |
| 9 |
> On Sat, Dec 15, 2018 at 6:33 PM Jack |
| 10 |
> <ostroffjh@×××××××××××××××××.net> wrote: |
| 11 |
> > |
| 12 |
>> So, I removed that HDD for safekeeping (completely reinstalled the |
| 13 |
>> laptop on a new drive) and now I'm trying to recover data from an |
| 14 |
>> intact partition on the old drive, the problem being that the drive |
| 15 |
>> is giving some read errors, so I want to minimize access, lest it |
| 16 |
>> die completely. |
| 17 |
> |
| 18 |
> Ok, step 1 - make a copy of the drive before you go messing with it. |
| 19 |
> I suggest using ddrescue for this. Basically it works like dd |
| 20 |
> (creates an image of the drive), but it is persistent in the face of |
| 21 |
> read errors. |
| 22 |
ddrescue has now been running for almost 22 hours, and it's been 47 |
| 23 |
seconds less than that since its last successful read. The odd thing |
| 24 |
(to me, although it probably should not be) is that the first issue |
| 25 |
with this drive was my own stupidity for trying to move a partition in |
| 26 |
a way I should have known would not work. (Simplified if inaccurate |
| 27 |
description is a 300GB drive with 100GB free and then a 200GB |
| 28 |
partition, which I tried to move to the beginning of the drive.) That |
| 29 |
garbled the partition, but the drive itself still worked fine. Since |
| 30 |
then, the drive itself has started giving lots of read errors, thus the |
| 31 |
slow progress of ddrescue.) The other drive failed over a shorter |
| 32 |
period of time, even though SMART testing said all was OK. One of the |
| 33 |
failures led to fsck "fixing"lots of stuff, but truncating or otherwise |
| 34 |
effectively destroying lots of files. It's a SATA drive, now connected |
| 35 |
to a laptop (only place I have enough recovery space on a good drive) |
| 36 |
by a SAS to USB adaptor. |
| 37 |
> |
| 38 |
> Once you have a copy of the drive you can now start experimenting. |
| 39 |
> Obviously keep that copy safe and if you want to write to it create |
| 40 |
> another copy. |
| 41 |
understood and agreed. |
| 42 |
> |
| 43 |
> As far as fixing dates goes - the touch suggestion might work but |
| 44 |
> honestly unless you're in a super hurry I'd just do another copy. |
| 45 |
once the ddrescue works, any approach will work. However, neither is |
| 46 |
likely to be very helpful with the number of read failures I'm getting. |
| 47 |
> |
| 48 |
> If you've lost any kind of drive metadata such that files are missing |
| 49 |
> completely there are utilities that can scan disk blocks looking for |
| 50 |
> things like text files, or jpegs. That is going to be a massive |
| 51 |
> headache but if you've lost something indispensible it is an option. |
| 52 |
I did one run of testdisk on one partition on the drive months ago. |
| 53 |
One problem is that the extension on the recovered files is not |
| 54 |
necessarily the original extension (even if the file is actually |
| 55 |
recoverable) and there seem to be some file types is doesn't (or didn't |
| 56 |
then) know about. I may well try it again after much more reading on |
| 57 |
tuning its behavior. |
| 58 |
> |
| 59 |
> Ultimately your goal is going to be to get the files you care about |
| 60 |
> off the drive. Then you can just copy/rsync them to a completely |
| 61 |
> fresh filesystem - I wouldn't go trying to copy the old filesystem |
| 62 |
> using dd if it has been subject to read errors or especially partial |
| 63 |
> overwrites of metadata. You want the metadata to be clean. |
| 64 |
right. |
| 65 |
> |
| 66 |
> And then once you have your data back on a disk give some thought to |
| 67 |
> your backup strategy. If you care about data enough to be going |
| 68 |
> through trouble to rescue it, you should probably have a backup of |
| 69 |
> it. When I was messing around with btrfs and the filesystem ate my |
| 70 |
> data I wasn't messing around with hex editors - I just wiped the |
| 71 |
> filesystem and rsynced from a backup. Sure, it takes time, but you |
| 72 |
> know the filesystem is completely clean when you're done. |
| 73 |
Someone (on this list?) had a signature "There are two kinds of people: |
| 74 |
those who do backups and those who have never had a hard drive fail." |
| 75 |
I guess there's actually a third..... |
| 76 |
> |
| 77 |
> -- |
| 78 |
> Rich |
| 79 |
Jack |
Archives