Home / server / Questions / 237242
Accepted
churnd
Asked: 2011-02-19 04:38:31 +0800 CST

Cloning a linux system from sdx to cciss

  • 772

I have an HP ML 310 server running CentOS Linux 5.5. I'm buying a RAID card (LSI 9260-8i) to set up a mirrored OS drive. Right now, the boot drive is set up with GRUB installed on the MBR of /dev/sda & has a 100MB /boot partition for /dev/sda1, then the rest is configured in LVM with a 20GB with a 20GB VG for the root partition & ~80GB VG for home. The new disk sizes will also be slightly larger as well. What is the best way to clone the boot drive to the new CCISS device?

linux centos lvm clone hp-proliant

5 Answers

  1. I think you should think more about a full backup/reinstall/restore cycle. You could use DD but the different disk sizes don't help there.

    You can also use tar or any other tool to get a full dump of the filesystem, repartition the new disk and untar all the stuff to the right places. You can even do it over a network and livecd/usb image using nc:

    Machine to receive the backup (/target is where your new disk partitions are mounted):

    $ nc -l -p <port> | tar zxvf - -C /target/

    Machine where the backup is:

    $ cat backup.tar.gz | nc <server ip> <port>
    • 1

  2. I do it often this way:

    1. create the partitions on the new drive, "cloning" the partition layout. Partitions don't have to be same size, equal or bigger.

    2. rsync whole partitions from one disc to the new one (rsync -avx --exclude=/proc --exclude=/sys --exclude=/dev --exclude=... , "-x" so it does not go over file system boundaries)

    3. if partition layout changed, adapt /etc/fstab

    4. some OS'es use /dev/disk/by-id/... naming and this will change on your new devices, adapt therefore /etc/fstab, /boot/grub/menu.lst, perhaps /boot/grub/device.map, ...

    5. if cloning to a new system wou would have to adapt MAC addresses also, but this is not the case here ...

    Have fun.

    • 1

  3. Since you are using LVM, using LVM snapshots is a good idea. I am not a fan of cloning LVM volumes because the Universally Unique elements that are essential to proper LVM function are no longer that Universally Unique. You never know how much your system will continue running with old and new hardware. I would suggest leveraging LVM's snapshot technology for everything other the your boot volume. Basically, you have VG_existing, and you will have to add your PVs to a new group VG_new, you will create new LVs under this group, and use same exact names as LVs i VG_old. Then you can create a snapshot of each volume in VG_old, and basically do a 'dd' from each snapshot to an identically named volume in your new group. This way you will not have a hobbled LVM configuration, and you can do this with a system live, no need for any real downtime. You will need to adjust grub later, and you are all set.

    • 1

  4. Am I missing something? There's no cciss device here. cciss generally represents the block devices tied to Compaq/HP Smart Array controllers. The LSI should show up as a /dev/sd[x] device. Either way, I'd recommend the backup, install, restore method here as mentioned in earlier comments.

    • 1
  5. Best Answer

    Some excellent answers here, but I wanted to post my own to document what I did that worked. Most of it can be found Googling easily, but one key step kept me at work late.

    With the new, unformatted disks installed (old & new disks in the system), assume /dev/sda is the old disk & /dev/sdb is the new & sda is the boot device. I did this from a CentOS DVD booting to "linux rescue":

    • Create a partition layout on the new disk similar to the old (colon denotes a command in fdisk):
      • fdisk /dev/sdb
      • n; p; 1; ; 13; a; 1 (100M boot partition)
      • n; p; 2; ; ; t; 2; 8e (LVM partition for rest of disk)
      • w;
    • lvm pvcreate /dev/sdb2
    • lvm vgextend vg1 /dev/sdb2 (substitute vg1 for your volume group name)
    • lvm pvmove -v /dev/sda2 /dev/sdb2 (this takes a while)
    • lvm vgreduce vg1 /dev/sda2 (remove the old disk from the volume group)
    • dd if=/dev/sda1 of=/dev/sda2 bs=1024 (clone boot partition)
    • poweroff & unplug your old disk
    • boot to the DVD using linux rescue once more
    • chroot /mnt/sysimage
    • grub-install /dev/sda (sda is now your new disk)
    • /sbin/mkinitrd -f /boot/initrd-uname -r.img uname -r (replace uname -r with your most recent kernel version. using backticks with uname -r might work in the command.)
    • reboot (to disk, not DVD)

    The part that had me stumped was mkinitrd, which was necessary because the system disk was behind a new controller & the drivers were not built into the previous initrd image. Without them, it would start to boot but couldn't find the LVM's.

    • 0