[TriLUG] How to migrate LVM to LVM on Raid-1

[Brian McCullough]

On Fri, Feb 17, 2006 at 09:37:12AM -0500, Rick DeNatale wrote:
> On 2/17/06, Brian McCullough <bdmc at bdmcc-us.com> wrote:
> > On Thu, Feb 16, 2006 at 04:23:45PM -0500, Rick DeNatale wrote:
> 
> > > 1. I need to change the partition type of /dev/sda5 from 8e to fd
> > > "Linux raid auto"  I can't seem to figure out how to do this with
> > > sfdisk, so I guess I'll do that interactively with fdisk.
> >
> >
> > NO, NO, NO.  At least, not yet.  This is the last step -- or one of the
> > last steps.  Doing this destroys your existing LVM partition. ( or at
> > least has that effect.  You haven't actually overwritten anything,
> > but.... )
> 
> Okay, I'm starting to understand the whole picture here.  At first I
> was wondering why I had to copy the data, isn't that what md is for.
> Now, I think what I really need to do is to create a new md array with
> /dev/sdb5 and a missing partner, populate it with the data, reboot and
> test, and then add /dev/sda5 to the array at which point it's going to
> get overwritten by md to be a twin of /dev/sdb5.


Bingo!


> > I tend to express these in megabytes ( or some other unit ) rather than
> > extents.  That's just me.
> 
> I guess that there's no operational difference in the result, or is
> there?  I got the numbers from lvdisplay


I just tend to think in bytes, but the value that I put in gets rounded
up to the next unit of extents anyway.


> I wasn't planning on making any physical configuration changes.


OK.  I understand.


> Grub uses a bios based numbering system for drives. (hd0,...) doesn't
> (necessarily) map to /dev/hda it maps to the first drive in the bios
> list.


I told you that I might be wrong.  ;-)


> That said, I think that I need to $s/hd0/hd1/g in the above. My
> current setup had hd0 in the menu.  What I'm doing in installing grub
> here is to allow booting from either boot partition /dev/sda1, (hd0,0)
> in grub parlance, or /dev/sdb1, (hd1,0) in case one of the drives
> fails.


Exactly.  If you aren't booting to the sdb drive, you aren't fully
testing your update. On the other hand, md0 has nothing to do with
either sda1 or sdb1.


> And the grub installation on /dev/sda will still be there and usable
> since only /dev/sda5 is in the md array.


Hey, I just said that!  ;-)


> > >     14. Copy the new /etc/fstab and grub configuration to the old drive
> > >         $sudo cp -p /mnt/root/etc/fstab /etc
> > >         $sudo cp -p /mnt/boot/grub/menu.1st /boot/grub
> >
> >
> > Not yet.  You want to leave the old drive as clean as possible.
> 
> Okay, so I leave it for now and change the boot order in BIOS to test
> the new drive.


Or, as we have said above, GRUB will boot to the device that you tell it
to, so you may not have to do anything to the BIOS.


> > >    16. Now add /dev/sda5 to the raid
> > >      $sudo mdadm --add /dev/md0 /dev/sda5
> >
> >
> > HERE is where you change the partition type of /dev/sda.
> > At this point you are committed.
> 
> I'm assuming you mean here that the change is a side-effect of the
> mdadm --add command, right?


No, I think that they are exclusive.  mdadm MAY change the partition
type, but I would check as well.



> And in future, if a drive (say sdb) fails, am I correct that the
> recovery is simply,
> 
> a) $mdadmin /dev/md0 -f /dev/sdb5 -r /dev/sdb5
>      The fail might not be necessary since md will probably already
> have noticed.
> b ) Install and partition a new drive
> b) mdadm /dev/md0 --a /dev/sdb

sdb2 or sdb10 or whatever



> c) Wait for the sync to complete
> 
> Yes?


Exactly.  See, nothing to it!


B-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2229 bytes
Desc: not available
URL: <http://www.trilug.org/pipermail/trilug/attachments/20060217/07ccdc57/attachment.bin>