[kwlug-disc] Cloning a physical server
John Van Ostrand
john at netdirect.ca
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:
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
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
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:
tar czv /etc /etc.tgz
5. Create a mount point for the new disk
6. Mount it
mount /dev/sdg1 /mnt-tmp
7. Restore the dump
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
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:
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:
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
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...
More information about the kwlug-disc_kwlug.org