<p><font size=2 color=navy face=Arial>
<br>Sounds like an easy and successful operation. <br><br>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. <br><br>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:<br><br>cd /mount_point_of_disk<br>ssh remote_host "cd / && tar -cvlf - . tmp usr var home boot" | tar -xvf -<br><br>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. <br><br>I usually forget to de-configure ethernet MAC addresses and do that manually on the console at boot. <br><br>While the target server reboots I re-IP the old server. <br><br>If I'm concerned about a consistent backup I'll shut down everything but net and ssh on the old server. <br><br>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. <br></font></p>
<p><hr size=2 width="100%" align=center tabindex=-1>
<font face=Tahoma size=2>
<b>From</b>: kwlug-disc-bounces@kwlug.org <kwlug-disc-bounces@kwlug.org> <br><b>To</b>: KWLUG discussion <kwlug-disc@kwlug.org> <br><b>Sent</b>: Tue Jul 20 17:22:30 2010<br><b>Subject</b>: Re: [kwlug-disc] Cloning a physical server <br></font></p>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
On Fri, Jul 16, 2010 at 8:40 PM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com">kb@2bits.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br><br>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).<br>

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

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

<br>Is this concern valid? Or should I just copy over everything and not care much? What about udev and modules in that case?<br clear="all"><br>This is Ubuntu, so Debian advice will work too. <br>Generic non-distro-specific advice welcome too (e.g. you used cpio instead of dump/restore).<br>

<br>Thoughts? Ideas?<br></blockquote></div><br clear="all"><br>OK, so the forklift job is done.<br><br>Here is what I did, in case it is useful to someone:<br><br>1. Installed the same distro version on the new server (in this case it is Ubuntu 8.04 LTS server edition).<br>
<br>2. Created a full (level 0) dump on the old server, to an external disk (USB in this case).<br>  dump -0 -u -f /backup/0/full.dump<br><br>3. Shutdown the old server, and connect the new server to the external disk.<br>
<br>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).<br><br>4. Backup the entire /etc directory of the new server:<br>  cd /<br>  tar czv /etc /etc.tgz<br>
<br>5. Create a mount point for the new disk<br>  mkdir /mnt-tmp<br><br>6. Mount it<br>mount /dev/sdg1 /mnt-tmp<br><br>7. Restore the dump <br>  cd /<br>  restore -x -aou -f /mnt-tmp/full.dump<br><br>One error was displayed during the restore, which I am ignoring for now.<br>
<br>restore: cannot create symbolic link ./usr/share/doc/python-minimal->python2.4-minimal: File exists<br><br>8. Extract the new server's /etc directory somewhere else<br>  cd tmp/<br>  tar xzf /etc.tgz <br><br>9. Copy the fstab file<br>
cp /etc/fstab fstab.new<br>cp /tmp/etc/fstab /etc/<br>Manually merge the old disks (mainly USB external disks) into the new fstab.<br><br>10. Get the new MAC address to be eth0:<br>cp /tmp/etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules <br>
<br>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).<br><br>So, I had to do this before rebooting:<br>
update-initramfs -u<br>update-grub <br><br>Then after rebooting, I reinstalled the correct kernel image and modules:<br><br>aptitude reinstall linux-image-2.6.24-28-server linux-ubuntu-modules-2.6.24-28-server<br><br>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.<br>
<br>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.<br><br>Curious as to why this is happening though.<br>-- <br>
Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra<br>
Simplicity is the ultimate sophistication. --   Leonardo da Vinci<br>