From: Wols Lists <antlists@youngman.org.uk>
To: H <agents@meddatainc.com>
Cc: Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: Recovering RAID-1
Date: Thu, 17 Jun 2021 19:22:10 +0100 [thread overview]
Message-ID: <60CB92D2.1030508@youngman.org.uk> (raw)
In-Reply-To: <cce5ebf1-6ab5-b448-4312-0ae07d335ac9@meddatainc.com>
On 17/06/21 18:37, H wrote:
> I see. I do recollect that at one time I had /dev/md127 and /dev/md128 show up in gparted. Could they have been created by the Intel fake RAID?
>
> If there are no signs of a remaining mdadm RAID installation and I have to install fresh, I do have a couple of questions. Naturally I need to make backups of the partitions before doing anything but:
>
> - Since the system seems to be booting from sdc1 and sdc2 while using sdb3 for the data partition, I would think that any restoration should be from backups of sdc1, sdc2 and sdb3, correct?
Yes. What you could do is create your new array(s) using sdb1, sdb2, and
sdc3, using the "missing" option to create single-disk mirrors. You then
dd the contents of sdc1, sdc2 and sdb3 across, make sure you can/are
booting cleanly from the mirrors, and then add sdc1, sdc2 and sdb3 to
the mirrors.
I'd probably happily do this on a test system for the hell of it, but on
a live system I'd make sure I had backups and be rather careful...
>
> - Is there anyway to do a dry-run of a fresh mdadm installation to see if it might install on the disks as currently partitioned and not disturb sdc1, sdc2 and sdb3? I do have this minimal partition of ca 4 MiB at the end of both disks which, if I understand correctly, might be used by a mdadm 0.90 scheme?
As above, you could dry-run on the apparently unused partitions, but
BACKUP BACKUP BACKUP!
And no, that little partition at the end will not be where the md
metadata is stored. You're correct, v0.9 (and v1.0) store their metadata
at the end, but at the end of the raid partition, not in a separate
partition.
And you're better off using the recommended 1.2 metadata, because 0.9 is
deprecated, and 1.0 and 1.1 are considered vulnerable to being stomped
on by other utilities that don't know about raid. Even 1.2 is
vulnerable, there've been a couple of cases recently where it seems that
other software (the BIOS, even?) "helpfully" writes a GPT on an
apparently blank disk - RIGHT WHERE MDADM PUT ITS SUPERBLOCK. And these
utilities don't ask permission! Windows of course is notorious for this,
although it seems that it no longer does it regardless it just assumes
that if the user invokes the disk management software then the user must
know what they're doing ... do they ever?
Cheers,
Wol
prev parent reply other threads:[~2021-06-17 18:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-13 22:51 Recovering RAID-1 H
2021-06-14 8:17 ` antlists
2021-06-14 17:35 ` H
2021-06-16 18:02 ` Piergiorgio Sartor
2021-06-17 17:37 ` H
2021-06-17 18:22 ` Wols Lists [this message]
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=60CB92D2.1030508@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=agents@meddatainc.com \
--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.