| The backup implementation for our systems will consist of two parts. During the day we will take copies of key system files into an archive area and during the evening we will perform a full system backup. You may think we are cheating a bit because none of our systems have 80-GB databases with 2-hour backup windows. But we can't account for all situations, and systems that fall into this category tend to be prime candidates for third-party products that enable online backups to be taken. The purpose of this book, though, is to show how to use Solaris and the tools that come with it. System File Backup The script archiveFiles is called four times a day from the root crontab file (see below). It takes a backup of key system files into a cpio file in the directory /archive. We have chosen to store the backups on the root filesystem to ensure we can get to them in the event that we have a problem mounting any other filesystem. The files to be backed up are stored in the configuration file /usr/local/utils/filesToBackup, one file per line: #!/bin/ksh arch=$(date +%d%m%y).cpio conf=/usr/local/utils/filesToBackup while read sys_file do if [[ -f ${sys_file} ]] then echo ".${sys_file}" >>/tmp/file_collection fi done <${conf} cd / cat /tmp/file_collection | cpio -ovc >/archive/${arch} if [[ "$?" -ne 0 ]] then echo "System file backup failed" | mail root fi rm -f /tmp/file_collection We now have a script that provides an easy way to recover key system files and allows us to revert easily to previous versions of any files should their contents become lost or corrupt. We just need to make sure that we decide how many of the archive files we want to keep and update the housekeeping configuration file to ensure we don't end up filling the filesystem. As mentioned, we will run the above script four times each day, using the following crontab entry: 0 9,12,15,18 * * * /usr/local/utils/bin/archiveFiles >/dev/null 2>&1 If we don't redirect the output from any command or script that is executed by cron, the owner of the crontab file will receive any output from that command in his or her mail. Our Backup Strategy The next stage is to implement the actual backup itself. Each of our systems has a local tape drive (/dev/rmt/0) and we know that one tape will hold the entire contents of each server so we don't need to bother with incremental backups. From this information, we can form a basic backup strategy that will meet our requirements, which are, admittedly, fairly simple. We know that we can fit all the data on a single tape, but unless somebody changes the tape everyday, we will keep overwriting the data that was backed up on the previous night. Our office is not open on Saturdays and Sundays, so we will only be able to change tapes Monday through Friday. So, if we start off with five tapes, we can perform a backup each night from Monday through Friday. If we label the tapes "Monday," "Tuesday," "Wednesday," "Thursday," and "Friday," then we just need somebody to put the correct tape in the drive on each weekday. We will then be able to recover any file that was lost over the last week. This isn't quite good enough for our needs since we would like to be able to recover data older than one week, so we will simply multiply the number of tapes by four and add a week number to the tape label. This is almost good enough for our strategy, but not quite. So, we will also remove one tape from the cycle every four weeks and keep that in the safe. In this way, we can recover any file that was backed up within the previous four weeks, and we have access to data going back to when the backup first ran. For our backup strategy to work effectively, it is very important that it is fully documented and that we label the tapes clearly with the server name, the week number, and the day of the week. Every four weeks we will be removing a tape (which should have the date it was removed clearly marked on it) so we will need a new tape to replace it with. If we remove the same tape every four weeks, we will build up a collection of tapes that have only been used once, while all the other tapes slowly wear out, so we should ensure that we also cycle the tapes that we remove. We will get around this issue by stating in our strategy that we always remove the tape used on the first weekday of each month. From this we can calculate that for each server we have, we will need to buy 32 tapes to provide a full year's backup capability. We should also buy a number of cleaning tapes and include the regular cleaning of each tape drive within our backup strategy. The Backup Script To make our backup script as flexible as possible, we won't hard code the names of the filesystems to back up within the script. Instead, we will take them from the output of the df command. This means that if a filesystem is not mounted, it won't get backed up; this also means that we will need to filter out the filesystems that are not UFS types. #!/bin/ksh # Simple backup script to back up each UFS filesystem to tape. dt=$(date +%y%m%d) log=/logs/backup for fs in $(df -l | awk '{print $1}') do # Get filesystem type from /etc/vfstab file. fs_type=$(grep " ${fs} " /etc/vfstab | awk '{print $4}') if [[ "$fs_type" != "ufs" ]] then # This filesystem is not type UFS so skip it. continue fi # For / replace the / with root for log filename. if [[ "$fs" = "/" ]] then fn="root" else # Replace any / in fs name with _ for use in log filename. fn=$(echo $fs | sed 's:/::g') fi if ufsdump 0uf /dev/rmt/0cn ${fs} >${log}.${fn}.${dt} 2>&1 then echo "Backup of ${fs} completed successfully" >>/logs/summary else echo "ERROR: Backup of ${fs} failed" >>/logs/summary echo "ERROR: Backup of ${fs} failed" | mail root fi done echo "Rewinding tape" >>/logs/summary </dev/rmt/0 The script is called from the following entry in the root crontab file: 0 2 * * 1-5 /usr/local/utils/bin/fullBackup >/dev/null 2>&1 Our backup script is simple, but does the trick. Each night it will back up each of the UFS filesystems to the tape in the drive, one after the other. In order that the backup of a filesystem does not overwrite the previous one, the no rewind device is used. We also want to take advantage of the compression built into the tape device, so we also specify that in the device name also. We produce a log file for each filesystem in the directory /logs and also write a message to a summary log file stating whether each individual filesystem backup was successful. We keep the backup logs on the root directory so that if we ever get into a situation where we have lost one of the other filesystems, we will still have access to the logs to check when the most recent successful backup was taken. If a backup fails, we also send an email to the root user to alert the root user of that fact. For the backup to be consistent, we need to be sure that the system is not being used (by users or applications) during the backup. Our backup will run at 02:00 in the morning so we are pretty sure no one will be logged in, but we could modify our script to put out a message using the wall command to ask any logged-in users to log out. If we wanted to take that a step further, we could even kill any user processes before starting the backup. If we have any databases or other applications that could be running throughout the night, it is a good idea to write a script that will stop them running (which can be called from cron just before calling the backup script) and another to start them again (which can be called when the backup completes). Each company's requirements will be different, so that will impact the best way to implement a backup. But however you end up doing it, remember it is a backup strategy that needs to be implementednot just a backup script. | 
