Re: Imaging Mirrored OS Drives

Re: Imaging Mirrored OS Drives

[andy liebman]

For those who have been following my attempt to create IMAGES of a pair 
of drives with mirrored OS partitions, and then restore the IMAGES to a 
new set of drives...

This doesn't work directly. The imaging programs are FAST because they 
do not perform block level copying. They replicated partition structure 
and copy FILES from disk to image and then image to disk.

As I have just discovered, when I restore the images to NEW clean 
drives, the partitions on the NEW drives do not have any RAID 
information. No UUID for mdadm to use. No RAIDS to assemble. But the 
file information is there.

So, my questions are...

1) Is it now possible to CREATE mirrored partitions with mdadm AND still 
KEEP the existing data on the NEW set of drives. In other words, create 
the mirrors AFTER the fact (given that the data on the drives is 
identical).

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?

I want to update the UUIDs so that they are the same as the UUIDs on the 
partitions on the original set of drives.

Andy Liebman

Re: Imaging Mirrored OS Drives

[Luca Berra]

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.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

RE: Imaging Mirrored OS Drives

[raid]

The first method that comes to mind is to make a raw copy of each mirrored disk to another disk attached to the same server. dd if=/dev/sda of=/dev/sdb will do a raw dump from one drive to another. Assuming you copy to a drive of equal or greater capacity, your partition structure, RAID superblock (including UUID), and data should remain intact. mdadm should be able to run a disk pair made by raw copies of the disks. I don't see a problem with identical UUID drives living in the same machine, so long as the array isn't started. Obviously copying a mounted block device is a bad idea, so I'd do it from a bootable CD environment, etc.

RE: Imaging Mirrored OS Drives

[raid]

Sorry, I EOF'd too soon..
As to creating mirrored partitions over top of existing data, mdadm will write a superblock at the beginning of each mirrored component, which will blow up the first several bytes of the partition (probably the FS descriptor). I believe there is an option to create a raid1 pair without a superblock, but I don't think I would want to use it.

P.S. I'm sorry for not having a full name attached to my email address.. I'm baffled on how to do that with mailx.

Re: Imaging Mirrored OS Drives

[andy liebman]

> 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