[kwlug-disc] Cloning a physical server

Khalid Baheyeldin kb at 2bits.com
Tue Jul 20 17:22:30 EDT 2010

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

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

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

aptitude reinstall linux-image-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

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

Curious as to why this is happening though.
Khalid M. Baheyeldin
2bits.com, Inc.
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.html>

More information about the kwlug-disc mailing list