All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan G. Weichinger" <lists@xunil.at>
To: linux-raid@vger.kernel.org
Subject: Re: emergency call for help: raid5 fallen apart
Date: Wed, 24 Feb 2010 18:28:54 +0100	[thread overview]
Message-ID: <4B8561D6.3020106@xunil.at> (raw)
In-Reply-To: <20100224170951.GC11039@cthulhu.home.robinhill.me.uk>

Am 24.02.2010 18:09, schrieb Robin Hill:

> It's degraded because you only have 2 disks in the array, presumably the
> event count on the other disks doesn't match up.  If you've replaced sdc
> and sdd never got rebuilt onto, then you only have the two disks
> available for the array anyway.

Yep.

> If these are the only disks with up-to-date data, and sda4 is still
> failing, I can only suggest stopping the array and using dd/dd_rescue to
> copy sda4 onto a working disk.  You should then be able to reassemble
> the array with sdb4 and the new disk, then add in a hot spare to
> recover.

OK, that's plan B. For now I try to get data aside.

md4 is a PV in an LVM-VG ... the main data-LV seems to trigger the
errors, but another LV seems more stable (other sectors or something).

This other LV contains rsnapshots of the main data-LV ... so if I am
lucky I only lose about 2hrs of work if I get the latest snapshot
copied. rsync is down to character "s" already ........

For sure there's a third LV as well, containing VMware-VMs ... oh my.

Let's pray this one is OK as well, at least while copying stuff.

> Alternately, bite the bullet, recreate the array and restore.

hmm

> Either way, it looks like you ought to be running regular checks on the
> array to try to pick up/fix these background failures.

smartd lead me to the failing sdc ... no note of sda though ...

A bad taste after all.

Thanks anyway, Stefan

  reply	other threads:[~2010-02-24 17:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 14:54 emergency call for help: raid5 fallen apart Stefan G. Weichinger
2010-02-24 15:05 ` Stefan G. Weichinger
2010-02-24 15:22   ` Robin Hill
2010-02-24 15:32     ` Stefan G. Weichinger
2010-02-24 16:38       ` Stefan G. Weichinger
2010-02-24 16:53         ` Stefan G. Weichinger
2010-02-24 17:02           ` Stefan G. Weichinger
2010-02-25  8:05             ` Giovanni Tessore
2010-02-25 16:27               ` Stefan /*St0fF*/ Hübner
2010-02-25 16:45               ` John Robinson
2010-02-25 17:41                 ` Dawning Sky
2010-02-25 18:31                   ` John Robinson
2010-02-26  2:42                     ` Michael Evans
2010-02-26 20:15                 ` Bill Davidsen
2010-02-28 11:50                 ` Stefan /*St0fF*/ Hübner
2010-02-28 12:52                   ` Stefan /*St0fF*/ Hübner
2010-02-24 17:09           ` Robin Hill
2010-02-24 17:28             ` Stefan G. Weichinger [this message]
2010-02-24 17:35             ` Stefan G. Weichinger
2010-02-24 18:12               ` Robin Hill
2010-02-24 19:54                 ` Stefan G. Weichinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B8561D6.3020106@xunil.at \
    --to=lists@xunil.at \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.