Help, my disk array has one dead member

[Kevin O'Gorman]

Hmmm.  I thought I had sent this, but just discovered it was still a
draft.  Sorry for the time warp.


On Wed, Mar 22, 2017 at 4:43 PM, Karl Auer <kauer at biplane.com.au> wrote:

> On Wed, 2017-03-22 at 16:12 -0700, Bruce Ferrell wrote:
> > Bottom line, one size never fits all...  poke, prod (gently) and use
> > trouble shooting steps to make a determination of what's needed to
> > recover and NEVER blindly follow "just do this..." instructions
>
> Sometimes people have no choice.
>
> Not sure what you are on about.
>
> The OP gave quite a good sitrep, made it clear that he was not in
> danger of losing critical data, and was given good, clear and above all
> harmless advice: Take a copy of the RAID, recover data from the copy.
>
> Had the OP said that this was critical data I would have offered quite
> different advice: Turn the thing off and take it to a professional data
> recovery service.
>
> Regards, K.
>
>
>
The OP checks in (Wednesday is my busiest day).

First off, this is raid-0, and comprises three 4-TB drives.  It's just
stripes so I have a larger partition than any one of my drives.  No
redundancy.  Sounds horrible, but remember this is hobby data only.  Not
only that, but there are enough backups of critical bits for me to feel
okay about re-creating anything lost.  And I have physical limitations in
my machines that keep me from adding more drives, which I might otherwise
do to have some redundancy.

Thing is, I want some specifics about what little bits were lost.  Just
filenames will do.  This is mostly lots and lots of little bitty files.
The few big ones are the ones I back up a lot.

I may already have enough, or nearly so.  I have copied all the files I
could in the root directory of the raid, and captured names of the ones I
could not read.  Of course there are some directories I could not read. and
anything in them is lost too.  But there are some directories that are
readable.  So I'd like to do the same thing in those.  There are enough of
them that I'd like to automate it, including taking note of what was
unreadable.  Filenames themselves will tell me a lot.

I'm not going to image the broken RAID, because I'm just not going to spend
the time dealing with tiny fragments.  I'm going to recover what complete
files I can, though I'm not sure any data files will be useful, because
some scripts may be recovered and it's my hobby and I'll feel better about
it if I go that far.  I have a working tar file of the main sqlite database
as of 3 days ago and the only other stuff that really matters is the little
scripts I use to automate some of the chores.  I don't want fragments that
I'm not sure were current -- I'd rather rewrite from memory or from
scratch.  Then I have a day or so of work to redo, and I have a log book
that tells me what that was.  I should do what recovery I can, use the new
disks to replace that raid entirely, and order a new set.  When I'm back up
and running I'll test the bejabbers out of the raid's drives before I put
any back in service.

And background: I've lost data before, like my PhD research back around
1999.  Eeek!.  So twice I've gone to data recovery services and paid a few
thousand bucks to get data back.  Because of this, nowadays I stay pretty
current with backups of crucial stuff.  But my raid is so big I just have
to take my chances.  I didn't have a great destination for storing
backups.  This is changing, and I now have another big machine, on which
I'm installing a RAID that will mirror the things on this one.  But I'm
going to use the drives I got for that as the replacement RAID in the old
machine.


-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170322/b6653a25/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170322/b6653a25/attachment.gif>