With support for a diverse selection of hardware, as well as proven
speed and reliability, Linux is up to the challenge of scaling up to meet
resource demands as they increase. This can include moving to an SMP
(Symmetric Multi Processing) configuration for
greater processing needs, RAID levels 0 through 5 (either in software or
hardware driven modes), etc.
On occasion, you may feel that your Linux server has outgrown the
hardware it is running on, perform a major Linux version upgrade, or
perhaps move to a different distribution of Linux. There are, of course,
two ways of doing this. Either you will be leaving your server on
existing or upgraded hardware (in which case you need simply shut down
services, back up your data, perform the required modifications, and then
restore data if needed), or in the more radical case, migrate your server
to new hardware.
This section will concentrate more on the latter situation, where
you will be actually migrating your various services from the old server
to a new one. There are, of course, several migration strategies, however
this section will attempt to provide some rough guidelines which you can
follow in order to ensure your migration effort succeeds with minimal
disruption to your users.
Prepare your
new server as necessary; install and configure Linux so that your new
hardware devices are supported, and any required daemons and kernel-based
features (such as firewalling) are enabled. See Chapter 4, as well as Section 10.6 for
details.
Set up your existing services (such as the Apache web
server, Samba or Netatalk file & print services, etc.) and make use
of them with test data for at least several days to ensure everything is
working as desired. See Section 7.4, as well
as Section 7.5 for details. Don't forget to
ensure that any changes or custom scripts you have made in the
``/etc/'' directory, including
anything in ``/etc/rc.d/'' have
also been done on the new server as required. It is especially important
that you remember to move over your user account information in the
``/etc/passwd'',
``/etc/group'', and, if you are
using shadow passwords,
``/etc/shadow''!
Shut down services on your old server, so that your file
systems will see a minimal amount of file update activity. Obviously you
don't want users uploading web pages and receiving e-mail on the old
server, while you are restoring the data onto the new one! As root, you
can shut down most services with the following command:
killall httpd atalkd smbd nmbd squid sendmail ftpd |
The above command will shut down the web server, file & print
services, e-mail server, and FTP service. (You may be running less or
more services than the ones I have listed above. Check your process list
and terminate any other service you feel appropriate; see Section 9.2 for details.)
You might also want to edit the
``/etc/inetd.conf'' file on your
old server, and with the ``#'' character, comment out
any services (such as FTP, IMAP, and POP3 services) which might result in
file system updates. Then, again as root, type:
The above command will reload the TCP wrappers (security wrappers
to Internet services) so that future connections to any services you have
disabled in the
``/etc/inet.conf'' file will not
be loaded).
Now you should be able to move over the data from one
system to another. Likely, you will have prepared your new server to
have everything it needs to function, including any additional software
that you wish to install that did not come with your Red Hat
distribution. Therefore, you will likely need to backup any data stored
in ``/home'',
``/var/spool'', as well as
optional file systems, such as
``/archive'', if applicable.
Here is an example command that uses the ``tar''
utility to make a compressed backup file of data:
cd /
tar zcvpf /tmp/backup_data.tar.gz --exclude=var/spool/squid \
home archive var/spool |
The above command will write a backup of your
``/archive'',
``/home'', and
``/var/spool'' file systems (or
subdirectories, depending on how you have set up your system), to a file
called
``/tmp/backup_data.tar.gz'' in
compressed tar format. Make sure you have enough space to create the
backup, or write it elsewhere!
Tip: Tip: You can use the ``du'' utility to help
determine required space. For example, to determine the requirements of
the ``/archive/'' and
``/home/'' directory trees,
type:
Bear in mind that the above command will report the actual size of
your data, but if you are using tar's ``z'' option (as
above) to compress the image file, your usage requirements will likely be
significantly less. Consider the output from the ``du''
command a worst-case estimate of the space required.
Now, you can restore the backup data from the tar file
onto the new server. You can restore it directly over NFS (see Section 7.6 for details on how to configure NFS), or simply
use FTP to transfer it over and untar it locally. Here is an example that
will restore the files that were backed up as above:
cd /
tar zxvpf /tmp/backup_data.tar.gz |
Next, if necessary, swap your IP addresses so that your
new server is seen on the old address.
Finally, you may wish to shutdown and restart your server
to ensure there are no unexpected error messages that appear. See Section 6.7 for details.
Once you are done, make sure everything is working as expected!
If not, you can always re-enable any services you disabled on the old
server and restart them so that users can continue using it until you
resolve the problems on the new one (bear in mind, however, that you'll
need to repeat the above steps again if you choose to do that).
