21st Century I.T. Solutions

Davrom Consulting Pty Ltd Established Since 2001 PO Box 1644, Sunnybank Hills, Qld, 4109 Phone/Fax: +61-7-32720267 ABN: 81 096 990 804

The following article was written by David.M.Clark for SCO World Magazine.

Despite the preaching from the industry specialists, so many computer installations fall far short of the "ideal backup goal". In fact most UNIX server backup strategies implemented still only backup the application data and while this is paramount to business record integrity, it still results in considerable down-time when it comes to re-installing the operating system and application software. The recovery time is further impacted when there is no knowledge of what users, printers and root filesystem changes were made to the pre-crashed system.

We install RAID systems to combat downtime experienced with hard drive failures and while this does give us higher redundancy, RAID systems still need some sort of additional backup to compensate for events such as human error or destruction by fire.

With tape drive capacity now equaling and/or exceeding the amount of hard disk space used (eg., DAT and DLT tape drives), ensuring that you backup as much of the entire system as possible on a daily/nightly basis holds the key to quicker recovery in the event of system failures. Using the system crash recovery diskettes or products such as Lone-Tar (with Airbag) from Cactus and BackupEdge from Microlite provide a complete crash recovery system. Lone-Tar and BackupEdge provide their own backup utilities and Emergency Boot floppy disks. The success of crash recovery packages such as these speak for themselves as they reduce downtime and provide a menu driven restoration front-end.

As indicated previously, backing up your data on a daily basis is essential and provided there are regular backups performed of the application programs and the UNIX operating system, using this three-tiered-restore approach to backing up will at least ensure that every file is backed up at some point. A root filesystem backup should be performed each time something has been changed such as the addition of users and printers or modifications to the kernel and networking. Most present day application software is installed in the additional filesystems such as /u or /home, but some still store configuration files within the root filesystem. If an application totally resides in the root filesystem (eg., in /usr or /var/opt) then a root filesystem backup should be performed to ensure both the application and the root filesystem configuration files are covered. Some sites elect to backup the /u or user based filesystems (eg., /home, /data, /usr1) each day if they include both the application programs and data.

The ideal, however, is to backup the entire system on a daily/nightly basis using either 'cpio' utility or one of the previously mentioned crash recovery packages. Unattended overnight backups can be performed via use of the UNIX systems 'cron' facility. It should be noted at this point that using the 'tar' command to backup filesystem data on most UNIX systems has limitations which may impact on the restoration of the system. The 'tar' command cannot normally restore the files in the /dev directory nor can it restore empty directories. SCO have always recommended the use of 'cpio' as the only accurate utility that is able to restore all system and non-system files. While 'tar' may have a simpler syntax, familiarisation with options associated with 'cpio' will make its power and use in tape backup/restore evident.

While a whole new debate with regards to the cost of purchasing backup products for UNIX, using the "Lite" versions of backup utilities such as ARCServe, or implementing standard UNIX backup scripts (shell scripts), the bottom line is the integrity of the actual backups themselves coupled with the time-frame in which they can be restored. The original charter of the design of UNIX was that it would be self-sufficient with respect to providing in-build utilities such as the archive utilities, commercial backup products often offer better interfaces that shield the user from the command line. Still they compete with the front end menus and GUI options provided with the operating system such as the Backup Manager under ScoAdmin.

From the perspective of providing a backup solution to a customer that may in fact fail due to some unforeseen hardware or software issue, a question of liability can be raised. While UNIX backup scripts work extremely well and are at little or no cost to implement, it must be expressed clearly that should a shell script fail owing to some un-known issue no guarantee can be offered. One such issue would be if the tape device file in the /dev directory, such as /dev/rStp0, where to become a regular file instead of remaining a device special file. cpio and tar have no way of interpreting that they are backing up to a regular file in the /dev directory as opposed to backing up to the physical tape drive itself. There are of course ways in scripting to check for such errors and raise alarms if required.

The backup script listed shows some of the base elements that are useful in implementing a 'cpio' based shell script.

1  :
2  # @(#) Simple backup example script using cpio
3  # @(#) No guarantee or warranty offered
4  #
5  # Variables
6  #
7  DEVICE=/dev/rfd0
8  FILESYSTEMS="u stand ."	
9  BACKLOG=/u/backup/backuplog_`date +%d`	
10 BACKUPLIST=/u/backup/backuplist_`date +%d`
11 EOF=/tmp/END_OF_BACKUP		
12 STAMP="/tmp/BACKUP_`uname -n`_`date +%m%d%Y`"
13
14 echo "Backup Started: `date`" >${BACKLOG}	
15
16 if [ -c "${DEVICE}" ]
17 then
18  echo "${DEVICE} is Character Special" >>${BACKLOG}
19 else 
20  echo "Failure: ${DEVICE} is not Character Special - aborted." >>${BACKLOG}
21  exit 1
22 fi
23
24 cd /
25
26 touch ${EOF}	
27 touch ${STAMP}	
28 
29 find ${STAMP} ${FILESYSTEMS} ${EOF} -mount -print | cpio -ocvB >${DEVICE}
30
31 cpio -itcvB <${DEVICE}>${BACKUPLIST}
32
33 echo "Backup Completed: `date`" >>${BACKLOG}
34
35 #
36 ## Eof: samplebackup

Lines 7-12 set the shell script variables. You will need to modify the DEVICE variable to suit your backup media (eg,. /dev/st0) and the FILESYSTEM variable to suit the filesystems/directories on your system and the order in which they are archived. Lines 11 and 12 are used to setup null files that assist labelling the archive media with the server name and date backed up and an END_OF_BACKUP marker file for verification. Lines 16-22 provide an if/then/else/fi routine to check that the DEVICE is in fact a hardware device file, in this case /dev/rStp0. In lines 24-29 the script enforces a change to the root directory, creates the 'label' and 'end of backup' files and then proceeds to perform the backup command. Line 29 performs the 'find' command on the files/filesystems but uses the '-mount' option to stay within the individual filesystem - this allows the backup of each filesystem exclusively. The options for 'cpio' are: -o for output, -c use ASCII header for filenames, -v for verbose and -B for 512 byte blocks at a time. Line 31 lists back the files from tape for later verification. This would allow the administrator to further write a script to check that the last line in the archive list file is /tmp/END_OF_BACKUP - qualifying if there was a backup archive failure or if the archive is in fact full.

Where two UNIX servers exist on the same LAN/WAN, it is possible to backup (remote copy) the files contained on one server to another (with the exception of the root filesystem). Say for example we have two UNIX servers on a LAN and the contents of the /u filesystem on servera need to be copied to the /u directory on serverb. The following two commands would facilitate this copying process provided the remote server were setup for the 'root' users trusted access (r-commands). On servera you could execute the command:

cd /u
find . -print | cpio -ocB | rcmd serverb "cd /u; cpio -icvBdlum"

or

cd /u
rcp -rp * serverb:/u

Another useful way to keep permanent records of directories is with CD-WRITERs using the public domain 'cdrecord' utilities. These utilities allow you to create CD images of directory structures that are then copied onto blank write-able CD-ROMs. It is important to check that the model of CD-WRITER has been qualified to work with your version of UNIX. Most SCSI based CD-WRITERs work with 'cdrecord'. Some typical commands used to create and then write to CD-ROMs are:

mkisofs -L -l -v -r -o /u/tmp/myimage.img .

to create and image, and then to record the image on CD-ROM:

cdrecord -v dev=/dev/rcd0:5,0 /u/tmp/myimage.img

Regardless of whether you backup to tape drives, Zip drives, remote servers or CD-ROM, it is vital for any organisation to ensure they have the highest level of backup strategy in place. The speed of which a business recovers from a system failure is measured in dollars-per-hour and in some cases dollars-per-minute.

Implementing the backup that suits your environment and taking into account storing backups off-site on a regular basis is the key to ensuring your business, your customer has the best backup strategy.