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.html>