[kwlug-disc] Cloning a physical server

Tue Jul 20 17:53:20 EDT 2010

Sounds like an easy and successful operation.

My usual routine for this is using network transfer. It all depends on the 
size of data and what other faster paths of transfer exist.

I boot a live cd or a rescue CD (in Red Hat parlance) and manually 
partition, LVM, mkfs, and mount. Then I bring up the network and use ssh to 
transfer the files in a one shot command:

cd /mount_point_of_disk
ssh remote_host "cd / && tar -cvlf - . tmp usr var home boot" | tar -xvf -

Then fix up the fstab and grub config and run grub-install. If a new kernel 
was needed I could install it before the transfer. If new drivers are needed 
I usually do that manually on the target server.

I usually forget to de-configure ethernet MAC addresses and do that manually 
on the console at boot.

While the target server reboots I re-IP the old server.

If I'm concerned about a consistent backup I'll shut down everything but net 
and ssh on the old server.

I have only found dump/restor useful when I transfer software that uses a 
file's inode as part of a licensing algorithm. Using dump/restor ensures the 
same inodes for files.

  _____

From: kwlug-disc-bounces at kwlug.org
To: KWLUG discussion
Sent: Tue Jul 20 17:22:30 2010
Subject: Re: [kwlug-disc] Cloning a physical server

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/49f74cc1/attachment.htm>