[kwlug-disc] Cloning a physical server

[Khalid Baheyeldin]

On Fri, Jul 16, 2010 at 8:40 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:

> Time to upgrade a server via the proverbial forklift operation: a new
> server comes in, and need to copy the existing server to it before
> de-commissioning/re-purposing the old server.
>
> Normally, on a regular LAMP server, it would be an opportunity to clean
> things up by doing a fresh install and configuring the few bits that need to
> be done manually, then just copying the data portion(s).
>
> In this case, this server is quite complex and has been running for several
> years with lots of stuff on it, not just LAMP. Therefore a fresh install is
> less desirable.
>
> Normally, if the hardware is similar, it is a no brainer: just use dump on
> the old server and restore on the new one, and you are done.
>
> The old concerns about /dev no longer apply, because now it is a dev is a
> tmpfs so it is not backed up by dump. However, in this case the hardware is
> a bit different, and therefore I am concerned about things in udev, modules,
> ...etc. being restored over from the older server's dump. That would
> overwrite configurations for devices such as MAC addresses and such. For
> modules, there could be differences too.
>
> Is this concern valid? Or should I just copy over everything and not care
> much? What about udev and modules in that case?
>
> This is Ubuntu, so Debian advice will work too.
> Generic non-distro-specific advice welcome too (e.g. you used cpio instead
> of dump/restore).
>
> Thoughts? Ideas?
>


OK, so the forklift job is done.

Here is what I did, in case it is useful to someone:

1. Installed the same distro version on the new server (in this case it is
Ubuntu 8.04 LTS server edition).

2. Created a full (level 0) dump on the old server, to an external disk (USB
in this case).
  dump -0 -u -f /backup/0/full.dump

3. Shutdown the old server, and connect the new server to the external disk.

The disk shows up as /dev/sdg instead of /dev/sdb, but that does not matter.
It was fixed after the reboot (sort of, see below).

4. Backup the entire /etc directory of the new server:
  cd /
  tar czv /etc /etc.tgz

5. Create a mount point for the new disk
  mkdir /mnt-tmp

6. Mount it
mount /dev/sdg1 /mnt-tmp

7. Restore the dump
  cd /
  restore -x -aou -f /mnt-tmp/full.dump

One error was displayed during the restore, which I am ignoring for now.

restore: cannot create symbolic link
./usr/share/doc/python-minimal->python2.4-minimal: File exists

8. Extract the new server's /etc directory somewhere else
  cd tmp/
  tar xzf /etc.tgz

9. Copy the fstab file
cp /etc/fstab fstab.new
cp /tmp/etc/fstab /etc/
Manually merge the old disks (mainly USB external disks) into the new fstab.

10. Get the new MAC address to be eth0:
cp /tmp/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/70-persistent-net.rules

Finally,  /boot was its own partition on the old server, and I prefer it to
be on the root filesystem (philosophical/religious debate on this in a
separate thread please, if any).

So, I had to do this before rebooting:
update-initramfs -u
update-grub

Then after rebooting, I reinstalled the correct kernel image and modules:

aptitude reinstall linux-image-2.6.24-28-server
linux-ubuntu-modules-2.6.24-28-server

All is well now, everything working perfectly. Except for one weird anomaly:
what used to be /dev/sdc is now /dev/sdb, and sdb is sdc. Both are USB
disks.

I worked around that by using LABEL= in /etc/fstab instead of UUIDs or /dev
names, and making the scripts use the mount point names rather than the
device.

Curious as to why this is happening though.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20100720/0473ece3/attachment.htm>