From: Wols Lists <antlists@youngman.org.uk>
To: Phil Turmel <philip@turmel.org>, Peter Gebhard <pgeb@seas.upenn.edu>
Cc: Linux-RAID <linux-raid@vger.kernel.org>,
Another Sillyname <anothersname@googlemail.com>,
John Stoffel <john@stoffel.org>
Subject: Re: Recommendations needed for RAID5 recovery
Date: Sun, 26 Jun 2016 22:12:15 +0100 [thread overview]
Message-ID: <5770452F.8000109@youngman.org.uk> (raw)
In-Reply-To: <576EB5FD.1000309@turmel.org>
On 25/06/16 17:49, Phil Turmel wrote:
> Hi Wol, Peter,
>
> { Convention on kernel.org is to reply-to-all, bottom or interleave
> replies, and trim unnecessary context. CC list fixed up accordingly. }
Sorry, but the OP had already been trimmed, I trimmed a bit further...
>
> On 06/25/2016 07:43 AM, Wols Lists wrote:
>
>> I know you're getting conflicting advice, but I'd try to get a good dd
>> backup first. I don't know of any utility that will do an md integrity
>> check on a ddrescue'd disk :-( so you'd need to do a fsck and hope ...
>
> Conflicting advice indeed. More conflict ahead:
>
> dd is totally useless for raid recovery in all cases. ddrescue may be
> of use in this case:
And if dd gets a copy without errors, what's the difference between that
and a ddrescue? Surely they're identical?
That said, it struck me you're probably better off using ddrescue,
because ddrescue could get that copy in one. So if you can get it in
one, it doesn't matter which you use, so you should use ddrescue because
it saves a wasted attempt with dd. (I've just read the ddrescue man
page. Recommended reading ... :-)
>
> Which means that the the balance of the drives have no redundancy
> available to reconstruct data for any UREs remaining in the array. If
> there were, forced assembly of originals after any timeout mismatch
> fixes would be the correct solution. That would let remaining
> redundancy fix UREs while adding more redundancy (the #1 reason for
> choosing raid6 over raid5).
>
> Peter, I strongly recommend that you perform a forced assembly on the
> three drives, omitting the unit kicked out last year. (After fixing any
> timeout issue, if any. Very likely, btw.) Mount the filesystem
> read-only and backup the absolutely critical items. Do not use fsck
> yet. You may encounter UREs that causes some of these copies to fail,
> letting you know which files to not trust later. If you encounter
> enough failures to drop the array again, simply repeat the forced
> assembly and readonly mount and carry on.
>
> When you've gotten all you can that way, shut down the array and use
> ddrescue to duplicate all three drives. Take the originals out of the
> box, and force assemble the new drives. Run fsck to fix any remaining
> errors from zeroed blocks, then mount and backup anything else you need.
>
> If you need to keep costs down, it would be fairly low risk to just
> ddrescue the most recent failure onto the oldest (which will write over
> any UREs it currently has). Then forced assemble with it instead.
>
> And add a drive to the array to get back to a redundant operation.
> Consider adding another drive after that and reshaping to raid6. If
> your drives really are ok (timeout issue, not physical), then you could
> re-use one or more of the originals to get back to full operation. Use
> --zero-superblock on them to allow MD to use them again.
>
Hmm...
Would it be an idea to get 4 by 3TB drives? That way he can do the
backup straight on to a RAID6 array, and IF he gets a successful backup
then the old drives are now redundant, for backups or whatever (3TB Reds
or NASs are about £100 each...)
Cheers,
Wol
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-06-26 21:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 19:55 Recommendations needed for RAID5 recovery Peter Gebhard
2016-06-24 20:44 ` Another Sillyname
2016-06-24 21:37 ` John Stoffel
2016-06-25 11:43 ` Wols Lists
2016-06-25 16:49 ` Phil Turmel
2016-06-26 21:12 ` Wols Lists [this message]
2016-06-26 22:18 ` Phil Turmel
2016-06-27 9:06 ` Andreas Klauer
2016-06-27 10:05 ` Mikael Abrahamsson
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=5770452F.8000109@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=anothersname@googlemail.com \
--cc=john@stoffel.org \
--cc=linux-raid@vger.kernel.org \
--cc=pgeb@seas.upenn.edu \
--cc=philip@turmel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).