From: andy liebman <andyliebman@aol.com>
To: linux-raid@vger.kernel.org, Luca Berra <bluca@comedia.it>
Subject: Re: Imaging Mirrored OS Drives
Date: Wed, 16 Aug 2006 18:20:42 -0400 [thread overview]
Message-ID: <44E39A3A.50909@aol.com> (raw)
> On Wed, Aug 16, 2006 at 01:05:39PM -0400, andy liebman wrote:
> if the imaging software is not too smart and creates the partitions and
> filesystems with the exact same size as the original, yes.
> (i mean that there should be some space between the end of the
> filesystem and the end of the partition to store the md superblock)
>
>>2) Furthermore, if the above is possible, in creating the arrays on the
>>new drives is there a way to force mdadm to give the arrays specific
>>UUID numbers? It looks like I can do that with mdadm --update? Should I
>>create the arrays first using the normal "mdadm -C" procedure, and then
>>update the UUIDs?
> never tried that, let us know how you fare.
>
> L.
>
> --
> Luca Berra -- bluca@comedia.it
> Communication Media & Services S.r.l.
Well, I booted with Mandriva One (Live CD), created NEW raid1 arrays
(md0, md1, md2 and md3) on top of the 4 pairs of partitions
(/dev/sd{a,b}1, /dev/sd{a,b}2, etc. corresponding to "/boot", "/",
"swap" and "/home")
mdadm -C -ayes /dev/md0 -n2 -l0 /dev/sd{a,b}1 and so on...
and when I mounted the md devices all of the data seemed to be there.
Then I stopped the arrays and changed the UUIDs on all the md devices so
that the UUIDs matched the original UUIDs from the drives that I was
copying from when I made the images.
mdadm -Av -ayes /dev/md0 --update=uuid --uuid=xxxxxxxx /dev/sd{a,b}1
I probably could have just created the arrays in the first place
specifying the uuids.
Anyway, after making those changes, I rebooted and the RAIDED OS just
came up "like magic". I was a little worried about whether the
filesystem would be okay. Rebooted with Mandriva One and ran "e2fsck
-fv" on all md devices (to force a thorough check and be verbose) and
all checked out okay as well.
I say, "hmmm". I never expected this to work. Compared to cloning a
RAIDED OS by doing dd on each drive, partition by partition, this was
fast! With this approach, it only takes about 15 minutes to produce a
cloned RAIDED OS.
I'm still worried that something might be wrong, but I can't see what it
is if it's there.
I promised I would put my "Single-Drive-OS-to-RAIDED-OS" recipe on the
list. I'll do it tomorrow.
Andy
next reply other threads:[~2006-08-16 22:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-16 22:20 andy liebman [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-08-16 17:32 Imaging Mirrored OS Drives raid
2006-08-16 17:28 raid
2006-08-16 17:05 andy liebman
2006-08-16 20:47 ` Luca Berra
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=44E39A3A.50909@aol.com \
--to=andyliebman@aol.com \
--cc=bluca@comedia.it \
--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.