All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: William Morgan <therealbrewer@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Two raid5 arrays are inactive and have changed UUIDs
Date: Fri, 10 Jan 2020 01:55:37 +0000	[thread overview]
Message-ID: <5E17D999.5010309@youngman.org.uk> (raw)
In-Reply-To: <CALc6PW7276uYYWpL7j2xsFJRy3ayZeeSJ9kNCGHvB6Ndb6m1-Q@mail.gmail.com>

On 10/01/20 01:19, William Morgan wrote:
> Thank you for the encouraging response. I think I would like to
> attempt to rescue the smaller array first as the data there is
> somewhat less crucial and I may learn something before working with
> the more important larger array.
> 
>>> md1 consists of 4x 4TB drives:
>>>
>>> role drive events state
>>>   0    sdj    5948  AAAA
>>>   1    sdk   38643  .AAA
>>>   2    sdl   38643  .AAA
>>>   3    sdm   38643  .AAA
>>
>> This array *should* be easy to recover. Again, use overlays, and
>> force-assemble sdk, sdl, and sdm. DO NOT include sdj - this was ejected
>> from the array a long time ago, and including it will seriously mess up
>> your array. This means you've actually been running a 3-disk raid-0 for
>> quite a while, so provided nothing more goes wrong, you'll have a
>> perfect recovery, but any trouble and your data is toast. Is there any
>> way you can ddrescue these three drives before attempting a recovery?
> 
> I do have plenty of additional disk space. If I try ddrescue first,
> will that just give me a backup of the array in case something goes
> wrong with the force-assemble with overlays? Can you give me some
> guidance on what to do with ddrescue?
> 
Firstly, the whole point of overlays is to avoid damaging the arrays -
done properly, any and all changes made to the array are actually
diverted to files elsewhere so when you shut down all the changes are
lost and you get the unaltered disks back. So the idea is you assemble
the array with overlays, inspect the data, check the disk with fsck etc,
and if it all looks good you know you can assemble the array without
overlays and recover everything.

Of course, things can always go wrogn ... so ddrescue makes a backup.
Depending on how you want to do it, just use ddrescue exactly as you
would use dd. You can copy your disk, eg "dd if=/dev/sdm of=/dev/sdn" -
just MAKE SURE you get the arguments right to avoid trashing your
original disk by mistake, or you can copy the disk or partition to a
file eg "dd if=/dev/sdj of=/home/rescue/copy_of_sdj".

If you're not happy using overlays, having ddrescue'd the disks you
could always assemble the array directly from the copies and make sure
everything's okay there, before trying it with the original disks.

Note that there is no difference as far as the *user* is concerned
between dd and ddrescue. Under the hood, there's a lot of difference -
ddrescue is targeted at failing hardware so while it tries to just do a
simple copy it doesn't fail on read errors and has a large repertoire of
tricks to try and get the data off. It doesn't always succeed, though
... :-)

Cheers,
Wol

  reply	other threads:[~2020-01-10  1:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CALc6PW4OKR2KVFgzoEbRJ0TRwvqi5EZAdC__HOx+vJKMT0TXYQ@mail.gmail.com>
     [not found] ` <959ca414-0c97-2e8d-7715-a7cb75790fcd@youngman.org.uk>
2020-01-10  1:19   ` Two raid5 arrays are inactive and have changed UUIDs William Morgan
2020-01-10  1:55     ` Wols Lists [this message]
2020-01-13 22:40       ` William Morgan
2020-01-14 14:47         ` William Morgan
2020-01-14 15:23           ` Wols Lists
2020-01-15 22:12             ` William Morgan
2020-01-15 23:44               ` Wols Lists
2020-01-19 17:02                 ` William Morgan
2020-01-19 17:07                   ` William Morgan
2020-01-19 17:41                   ` Wols Lists
2020-01-19 20:12                     ` William Morgan
2020-01-19 21:10                       ` Wol's lists
2020-01-24 14:10                         ` Nix
2020-01-20  8:49                   ` Robin Hill
2020-01-20 15:00                     ` William Morgan

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=5E17D999.5010309@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=therealbrewer@gmail.com \
    /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.