From: Phil Turmel <philip@turmel.org>
To: Wols Lists <antlists@youngman.org.uk>,
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 18:18:04 -0400 [thread overview]
Message-ID: <5770549C.4060301@turmel.org> (raw)
In-Reply-To: <5770452F.8000109@youngman.org.uk>
On 06/26/2016 05:12 PM, Wols Lists wrote:
> On 25/06/16 17:49, Phil Turmel wrote:
>> 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 ... :-)
dd will only copy a device that has no UREs. If it has no UREs, it'll
work in the raid array even if there's no redundancy. So duplicating
that device is pointless for pure recovery purposes.
If you already know you have one or more UREs on a device and no other
redundancy to reconstruct with, you go straight to ddrescue -- you know
that dd won't work, so why bother? And in this case we know -- the
drive was kicked out of the array. The OP hasn't provided any further
information, so we don't know if this is the typical timeout mismatch
calamity, or if there's more serious problems, but that doesn't change
the advice.
Finally, if you know you have UREs *and* you still have redundancy
(raid6 or raid10,n3 degraded by one, f.e.), you want to keep the drive
with the UREs in place until replaced so MD can perform reconstruction
when it hits that spot. Again, no role for dd.
Now, when the problem isn't just an array that needs to be reassembled
but rather a true reconstruction from unknown parameters, the duplicate
devices are needed because the experiments to discover the parameters
can be destructive. In this case we need complete copies for the
experiments, whether UREs are present or not. ddrescue again. (Knowing
there are UREs makes it important to use the original devices during
recreation after the experiments are done.)
I don't know *any* scenario where dd is useful for raid recovery.
> 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...)
Many hobbyists and small business people have limited budgets. (Been
there!) I try to avoid recommending expensive replacements unless the
situation clearly calls for it. I specifically omitted any suggestion
of where to perform backups since it may make sense for the OP to just
copy important stuff onto an external USB device.
It's entirely possible that the OP is researching timeout mismatch and
patching up some green drives. It's not ideal, but such an array can
operate with the work-arounds for years if it's regularly scrubbed. And
it's cheap, which sometimes matters.
Phil
--
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 22:18 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
2016-06-26 22:18 ` Phil Turmel [this message]
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=5770549C.4060301@turmel.org \
--to=philip@turmel.org \
--cc=anothersname@googlemail.com \
--cc=antlists@youngman.org.uk \
--cc=john@stoffel.org \
--cc=linux-raid@vger.kernel.org \
--cc=pgeb@seas.upenn.edu \
/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).