Disk-to-Disk Magic

If you're being pressed into a massive server upgrade, don't risk it all with the dangers of an in place upgrade. I've done in place upgrades on other people's systems just to see if they really work. Sometimes they do and some times not. But at the other end of the spectrum, why bother moving all the existing server data to tape when you're just going to have to move it all right back into place? Tape is slow; so there is no need to do it that way. If you're able to get a couple extra hard drives lined up, there's a much easier way.

First, get yourself a couple of extra drives. One of the new drives will be your new OS drive-the one you're going to install a fresh new OS on. The second drive is going to be your insurance. Take your second drive and clone your original old OS/data drive with imaging software such as Symantec Ghost or Drive Image Pro (this is assuming an X86 environment, but Ghost can also clone non-x86 filesystems). Either Ghost or DIP will allow you to make a block-level copy of your old drive to your temporary migration drive. Now take that original old data/OS drive, clearly label and date it, and put it in a safe place for at least 6 months, just in case.

Now take your ghosted drive and install it in your new system under somewhere obvious like /mnt/old-drive/, mounted read only. It should look something like this in your /etc/fstab file:

/dev/hda3     /               ext3        defaults       1 1
/dev/hda2     /boot           ext3        defaults       1 2
/dev/hdc6     /mnt/old-drive  ext2        defaults,ro    0 0

After you have the drive mounted, begin migrating your data carefully and slowly. If you don't want to overwrite new server configuration data and files with your old stuff, DO NOT just blindly copy of large chunks of data such as /home directories, websites, users, and config files. Many times, new software package (such as apache 2's httpd.conf file) is not compatible with its older cousins. The same goes for even some user content. Be sure to inspect /home/username directories before just blindly copying them over. You should usually to spend a few minutes on each one before letting loose with your cp -a /mnt/backup/ home /home. In fact, sometimes before starting to move over the larger chunks, I just go ahead and back up the new stuff just in case (if I have the space):

# cp -a /home /home-BAK

If you don't feel so comfortable with doing a lot of this on the command line, you can use a GUI environment such as KDE, GNOME, or even a cool shell tool such as Midnight Commander (or mc on the command line).

Software Issues

The software and server daemons on the source and target servers make up a major part of the server migration checklist. In short, you need to do your homework and make sure that the content and web programs you are moving do not have application version reliance that could make things difficult for you later (such as perl versus mod_perl, php versions, and so on). From a bird's-eye view, some of the technical issues that you need to check on the new server before the move begins include the following:

• OS install and supported libraries (for example, Linux and glib versions)

• Versions of apache (or other web server service used)

• Version of Sendmail (or mail service used)

• Apache modules, Perl, and CGI engines installed and configured

• BIND/DNS software (formatting of zone files)

• Same or greater patch levels (old versus new) for network visible services

• Same or greater hardware configuration

• Same security/access rights (TCP-Wrappers, ACLs, and so on)

• Any software or configuration dependencies on your IP address

• Any commercial packages that register their key based on IP, FQDN, or server name

• Roughly the same OS and filesystem UID/GID (user/group) permissions

This last point is usually one of the trickier ones. You need to examine your old /etc (now on /mnt/old-disk/etc/) and start looking for differences with users (/etc/passwd and /etc/shadows) and groups (/etc/group). Then recreate the users on the new system with the same UID/GIDs if possible.

Here's an example and breakdown of what the user accounts in /etc/passwd look like, and which column does what:

bsmith:x:503:503:Bob Smith:/home/bsimith:/bin/bash
  ^^^    ^^  ^^    ^^^       ^^^^          ^^^^
  user   UID GTD   username  home dir      login shell

The file system and movement of data can be the hardest parts of a migration, because every file in the system maps to a specific user/UID and group/GID (not to mention special file links, security settings, and so on). Simply tar'ing or zipping-up and moving all the files from the source server over to the target server and then manually trying to match everything up can be a daunting job-even for a professional. Even though cp -awill preserve user/group IDs perfectly, your new OS install will often have slightly different directory, group, and security settings that you will have to keep battling, sometimes months after the migration is complete.

Web/Apache Gotchas

Here are a few of the things to watch out for with regards to apache migrations:

• Comparing the old and new httpd.conf configurations and modules of your two servers (assuming UNIX/apache)

• Verifying that system automation scripts, that may, for example, restart the web server, use the correct start/stop commands and paths

• Checking the paths of logs that are written and read (if you're doing any log analysis reporting)

• Checking all user and system crontab files, moving them over, and verifying each absolute path reference

• Apache 1.3 versus 2.0 module incompatibilities

One big web migration issue that is often overlooked is checking to make sure that your SSL engines (underlying SSL server programs) on your old and new servers are the same or at least certificate-compatible. If they are not, you could be looking at either regenerating and repurchasing all of your SSL certificates (which could take up to 2 weeks per certificate, and hundreds of dollars each), or installing a different SSL engine on the new server.

Also, if you're bringing new SSL sites to your server that has existing SSL certificates that they've paid for, you will need both the SSL key and certificate for each site. Otherwise, the certificate is useless. I also recommend getting the cert request if it is still available. This can sometimes save the site owner money if the cert needs to be recreated.

Security

This too is a big category, so I'll just mention the basics of what you'll want to check out and compare on the new target server. This includes the following:

• TCP-Wrappers or IP based ACL (access) controls

• IP-Chain/IP-Table configurations

• FTP access rules

• Mail/SMTP/SMTP-Auth settings and relaying rules

• Mail/POP-locks and access rules

• Firewall ports, IP rules

• DNS zone transfer lock-downs/allows

Usually security ends up taking a back seat to getting everything moved over and working in the migration priorities. While this might end up being your de facto strategy, just don't forget to follow up with your server's security settings or you may end up experiencing a not so pleasant reminder in the form of hacked users accounts and/or compromised systems.