You have installed your system, configured various services, tested access to the network and the system is chugging along fine. The adrenalin has dropped and it is now time to think of what is required to keep your system up and running, and time to plan ahead for unforeseen failures. Two primary functions are classified in this ‘mundane’ activity—System maintenance and

Data backups.

System maintenance comprises ensuring that the system resources are available all the time to the user(s). System resources need monitoring regardless of whether the monitoring is manual or automated. Here is a monitoring checklist.

Pre-install Site check

• Input power voltage (stabilized, 220+/- 10V, AC and neutral to earth voltage (less than 3 V, AC)
  System checks
• Cable overhangs from the CPU, monitor and keyboard (fasten all lock screws on the connectors, bunch wires and tag and label them): Periodic.
• System BIOS and test messages on boot-up (observe component status and test reports): On boot.
  Post-install

OS checks (Routine)

• Kernel boot messages that report devices status
  type dmesg | less at your command prompt
• Verify the system date and time
  type date to see the date/time
  type date DDMMHHMMCCYY as super user to set the date. Remember to ask crond to reread its internal settings so that the new time is reflected
• Verify that all file-systems are mounted and check the available space in them.
  df -h gives you a self-explanatory listing with the capacities in MB/GB
  

  File-system	Size	Used	Avail	Use%	Mounted
  /dev/hda6	2.8G	2.5G	255M	91%	/
  /dev/hda1	27M	3.4M	21M	14%	/boot

• Watch to see that all the log files are being updated (refer to article ‘System Administration in Linux’, page 128 PCQuest, November 1999).
  Check the /var/log/ directory. To check the status of, say, the system messages file, use stat messages. Check the fields ‘Modify’ and ‘Change’.
  
  File: ‘messages’
  Size: 69529 Blocks: 144 Regular File
  Access: (0600/-rw———-) UID: ( 0/ root)
  GID: ( 0/ root)ot)
  Device: 306 Inode: 84591 Links: 1
  Access: Tue May 29 12:21:49 2001
  Modify: Thu May 31 15:20:56 2001
  Change: Thu May 31 15:20:56 2001
  
• Check mail that is sent to user “root”—most in ternal problems are reported there.
  
  To: root@gopi.exocore.com
  Subject: Cron run-parts /etc/cron.daily
  /etc/cron.daily/tripwire-check:
  **** Error: NOSPACE: Cannot update
  Tripwire database for
  www.pcquestlabs.com ****
• Make sure that you backup your system boot image and services configuration to help you restore things if there is an emergency.

Backing up

Backing up data is a desirable addiction. Post installation, the first things that need backup are the systems configuration and boot image. Yes, it is always desirable to make that boot floppy that you are prompted to make at the end of the installation session and then make a couple of extra copies of this floppy.

Where do you back up to? Ideally a tape drive if you have one (please refer article ‘Backup and Disaster Recovery’, page 83 PCQuest March 1999), otherwise a second hard-disk that you may have mounted or at least on a partition on the disk, from where it is easy to transfer it to an off-site location or burn it onto a CD. Let us assume that you have no backup device other than a floppy. No, no system backups on a floppy, please. They are far too critical.

What do you back up ? If disk space is not a problem, then the fastest is to backup entire directories /boot (4 MB), /etc. (11 MB), /var (59 MB) and /usr (2 GB) in addition to any user data that you might have. The sizes mentioned are estimates from a full-install system.

How do you do this? In the setup that we have, let us prepare ground for backups with some assumptions. (We will use the tar command for taking backups.)

1. There is enough free space on the Intranet server where one can store backups.
2. Backup entire directories from the Gateway machine to the Intranet server.
3. Backup all logs under /var/log on gateway to the Intranet server.
4. Do a full backup everyday instead of incremental backups.
5. Transfer the backup archives into a removable media, later.
6. You have installed the sash package on both the gateway machine and the Intranet server.

Here is the command that will enable you to backup the various directories from the gateway onto the disk of the Intranet server.

root@gateway# FLABEL=`date ‘+%b%d’`-backup; tar zcf - /boot /etc/
/var /usr | ssh backups@intranet
“dd of=/var/backups/gateway/$FLABEL.tgz”

Here is what the elements of the command line mean:

FLABEL=`date ‘+%b%d’`-backup is used to generate a filename automatically for the backup file. You should see filenames like “Jun01-backups.tgz”. So, you will have the date on which the backup was taken. Modify the format parameters in the date command to suit your requirement.

tar zcf - /boot /etc/ /var /usr is used to generate a compressed tar archive of the directories listed and write the output to stdout.

ssh backups@intranet “dd of=/var/backups/gateway/$FLABEL.tgz” is used to remotely execute the dd command on the intranet server, capture the input via stdin and create a file of the archive. The remote command is executed via ssh to ensure that the passwords and data do not go on the LAN as clear text.

Once these backup archives are created, they can be written on to a CD (please refer to the article CD-writing, page 63 PCQuest June 2000).

Happy Backing up!

Gopi Garge is a director of Exocore Consulting