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