All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.