1. Failing to do backups on a regular schedule.
Most people with computer experience know how critical their data is. From word processing documents to multi-tiered databases, accurate data storage and retrieval is an absolute must to get the job done right. So, why do so many people put off backing up their systems or networks until it is too late? Data blocks in hand, they carelessly skirt the edge of the electronic microcosm until suddenly, accompanied by strange moaning and flushing noises, they see the fruits of their efforts whisked into a binary black hole, all traces of their presence vanished. Sadly, it is usually only then that they see the error of their ways.
Fortunately, there are many solutions available to aid in simplifying the task of archiving data and assuring that backups are done regularly, most of which do not require cosmic forces or a great deal of extra work. The simplest of these is to just let the system run the backup automatically using the Unix utility cron. cron makes it possible to schedule backup tasks to run on a recurrent basis without any user intervention. The only steps that are required are deciding when the system is at its quietest point of operation and setting up the backup commands. Once the proper commands have been set, all you need to do is to make sure that the backup tape is loaded. You can even have the system remind you to load the tape! The possibilities depend solely on what your current requirements are. Many system administrators establish a schedule of incremental backups each day, partial backups each week, and full system backups once a month. If your system is small, however, it may be easiest just to back up the full system each day.
BRU Solution: BRU has a special mode that enables it to run automatically under cron, which greatly simplifies the automation process. Multiple backup definitions can be created and scheduled to run at user-specified times, and all levels of backup can be incorporated into the process.
2. Failing to backup special files.
Special files exist to communicate (read and write) with system hardware devices, similar to what drivers do using other OSs. Unlike regular files, they do not contain data and cannot be copied with backup utilities like tar. If a special file associated with a certain device (like a disk drive) is destroyed or corrupted, it will be impossible to use the device until its special file is restored. In the event of a system crash or failure, your backup program may not be able to restore the special files and they will have to be re-created from scratch, which is usually a lllooooonng and tedious process.
BRU Solution: BRU will back up and restore all files, including the special files that are skipped by other utilities. BRU will even handle FIFOs and symbolic link files. If your system crashes, BRU can restore every file, regular or special, eliminating the need to re-install devices in order to re-create the special files.
3. Using absolute pathnames for backups.
One of the most highly recommended methods of performing backups is to perform all backups using relative pathnames instead of absolute pathnames. Of course, while this is THE suggested method of backing-up, especially if there is a possibility that the archive might be restored someplace other that the original machine, it is by no means a "gotta" (like, ya gotta do it this way). Technically, this means that it is not an "error" per se, but more like a failure to conform.
Absolute and relative pathnames differ in several ways. Relative pathnames begin with a ./ or directory name as opposed to /. This means that a relative pathname will recognize its place in the cosmos based upon the current directory, whereas an absolute pathname must align itself only to root. By specifying relative pathnames, files can be restored to different directories, which can be especially important when recovering from a hard disk failure. A hard disk failure usually requires rebooting a system from a floppy disk, at which point the small root filesystem contained on the floppy is utilized. If absolute pathnames were specified for the hard disk backup, then the system restore will try to write all the archived files to the root filesystem on the floppy! This can easily be avoided by backing up system files with relative pathnames. Relative pathnames make it easier to restore all the files to the hard disk. After the hard disk has been fixed (possibly by reformatting, creating a new filesystem, etc.) and mounted on the /mnt directory of the boot floppy filesystem, the archived files (stored with relative pathnames) can be restored to this directory. This will restore the original root filesystem to the hard disk.
If you have already stored your backup files with absolute pathnames, you can still restore them by using the chroot command. Mount the hard disk filesystem on the /mnt directory (example: mount /dev/rdsk0 /mnt) and create a /mnt/bin directory (mkdir /mnt/bin). Copy the shell program (cp /bin/sh /mnt/bin/sh), the backup/restore utility (i.e. /bin/bru /mnt/bin/bru), and any other necessary utilities to the new directory.
Change to the /mnt directory (cd /mnt) and start a new shell with the chroot command (chroot /mnt /bin/sh). This creates a new environment where all commands will treat /mnt as if it were the root directory. Set the execution path (PATH=/bin; export PATH) and files stored with absolute pathnames can now be restored. Of course, this is merely an outline of how to restore absolute pathname archives by using chroot. It is usually tricky and tedious and may not work with all systems. To avoid these problems, specify relative pathnames when you backup your files.
BRU Solution: BRU offers a simplified option that will convert absolute pathnames to relative ones. By using -PA on the command line, which is BRU's absolute-to-relative flagset, BRU will automatically treat the absolute backup like a relative one, converting / to ./ (makes you wonder why we just didn't tell you about this part first, doesn't it?).
4. Failing to maintain physical security for your backup tapes.
Backup tapes typically contain valuable company or personal data and should always be stored in a secure location. It is also a good idea to limit the access that personnel may have to this information, as these probably house data (i.e. payroll) that is classified internally, too. If stored out in the open, any common, or not so common (like a competitor), thief can pilfer a tape and access your data without even knowing your login or password. This could ultimately result in irreversible damage to your business or organization. It is also a good idea to maintain a copy of your important data in a separate location (or in a fire-proof cabinet) in case the original tape is damaged or lost.
BRU Solution: Be vigilant in maintaining security procedures. Understand the importance of protecting your electronic assets.
5. Failing to rotate your backup tapes.
Many users make the mistake of repeatedly using the same tapes for every backup, simply writing the new backup data on top of the old data. This seems especially true for those using tapes with large capacities (20gb, 40gb, etc.) for data. The problem here is that tapes have a finite lifespan and become unreliable when pushed beyond it. Trying to cut costs by stuffing all of the daily backups (i.e. writing data from Monday, Tuesday, etc.) on the same tape can end disastrously, too, especially if that single tape goes bad or if the system fails while doing a backup. All it takes is a power surge, static electricity, a mis-entered command while logged in as root, or any other negative environmental stimuli and suddenly you're left with a crashed system and no backup data.
BRU Solution: To avoid mishaps, you are strongly advised to have (at minimum) two sets of backup tapes, and to consistently alternate backups between the two. One backup can be written to the first set, the next one to the second set, and so on. Even if the system fails during a backup, there will always be one available set of tapes containing usable backup data. In addition, be sure to retire the tapes (always showing the proper respect and remorse, of course) once they have outlived their usefulness, as it is critical that they be replaced by tapes that are in the best possible condition (like brand new!). Tapes are one expense where the alternative can be far more costly than the preventive, so spare no expense and do not cut corners.
Keep in mind, too, that writing multiple archives (appending them one after another) to a single tape usually makes it more difficult to verify your backup. Appending a new archive to the end of tape usually requires that you write to the norewind device. Since this device does not rewind to the beginning of a newly created archive by default, it's much more difficult to ensure that you have a reliable backup.
Remember: A penny saved doth not a proper backup make.
6. Failing to create a boot diskette (or tape).
This one never fails to blow the mind, defying all logic and principle - not to mention causing a few ruptures in the ol' common sense pipeline, as well. Simply put, if a hard disk crashes, you need another way to reboot. Without a boot diskette, you're in big trouble. Although most vendors include a standard boot diskette with their system, this is not always the best solution, as the standard boot diskette contains only a "bare-bones" version of the Unix kernel. It will not contain any of the special device drivers or enhancements that you may have added. Even if you do use the standard boot diskette, you will still have to spend several tiresome (boring) hours rebuilding the system. Some systems (like SCO) will even make you re-enter the serial number of your software before you can even start to restore your files!
BRU Solution: Create your own boot diskette containing the latest version of your Unix kernel and make certain that it contains any special device files that you may need (like, uh, the one for your backup tape drive).
7. Failing to make a copy of the restore utility on the boot diskette.
This could happen (sigh...and often does). People get busy, it rains, they run out of Charmin at the local market. It may seem obvious, but many people really do forget to include their restore utility when creating a boot diskette. (Um...you did create a boot disk...right?) Don't let this happen to you.
BRU Solution: Make a checklist of all items, both hardware and software, that are essential to system/network backup and recovery. Be sure to update it regularly and include all of the files that should be stored on diskette. It is also a good idea to make at least two copies of your boot diskette and, like your backup data, keep the diskettes secure and keep a copy off-site.
8. Failing to backup filesystems separately.
Most Unix systems have more than one filesystem (like / and /u) and, ideally, each should be backed up separately. Unfortunately, most backup utilities (like tar and cpio) are unaware of filesystems and will simply backup any file, regardless of its filesystem. This makes it almost impossible to do a separate backup (unless you unmount the unwanted filesystems, which may not be practical).
Should there be a system crash, damage is likely to occur and it may not be possible to mount all the filesystems. If you are unable to mount all the filesystems needed by your backup files, then those files will be restored to improper locations. Your root filesystem could be filled to capacity with non-root files even before all the critical root files have been restored. This will invariably leave the system in an unbootable condition.
BRU Solution: BRU gives you the option of backing up each filesystem separately, which makes it easy to separate the root files and permits fast and easy crash recovery. It is always best to do a separate backup of the root filesystem, as this will let you rebuild and restore the root filesystem with only the root files, and should simplify the job of crash recovery.
By backing up the filesystems separately, once the root filesystem is restored, you can tend to the other filesystems and complete any necessary repairs before you attempt to restore the files. Never attempt to restore files to a filesystem that is corrupted, as you're likely to cause additional problems. You may even want to have each filesystem on a different backup schedule. Filesystems that do not change much may not need to be backed up as frequently as busy filesystems. The same backup tape may contain multiple filesystems (for speed, make sure that root is the first one), or you can write each filesystem to a separate tape.
9. Failing to verify your backup data.
Backup data is useless unless its integrity has been fully confirmed and preserved. Standard Unix backup utilities like tar and cpio are notoriously unreliable when writing data to a tape. If an error occurs, data can be lost without any kind of notification or warning. To prevent this, the best method of making certain that the data is correct is to fully verify the backup. The problem is that most of the standard backup utilities weren't designed to do data verification. They just assume that everything is written to the tape with no errors. While this is impressive optimism, it seldom works out in practice. tar does support the -t option for reading an archive, but all this does is read the file headers without verifying the data.
BRU Solution: BRU can verify data using three different methods:
1. Autoscan[tm] BRU will check every tape written by doing an "autoscan." After each tape is completed, BRU will automatically rewind and "scan" for errors by comparing checksums against the data that was just written. The checksum verification is done for each block of data and will quickly and easily identify most tape failures.
2. AnytimeVerify[tm] AnytimeVerify also verifies data by using error-detecting checksums. This option checks the integrity of the data on the backup tape. If there are errors, BRU will list the filenames and the locations of the problems. Since tapes are subject to a variety of failures (magnetic fields, heat, glazed donuts, etc.), this is a good test of the quality of the data on a tape. Backup tapes can be inspected at any time, and it is not necessary to compare the data to the original.
3. Bit-Level Comparison Using bit-level comparison, BRU will compare the archive to the hard drive information and check for differences in file size, changes in the data, date changes, status changes, link changes, and changes in special files. If there are any differences between the data on the disk and the data on the tape, BRU will report them.
10. Failing to keep a backup log.
This is usually not a serious mistake, but much time can be saved, and much trouble avoided, by keeping logs. There are two kinds of logs that should be kept: a file information log and an error log. The file information log should contain a list of which files were backed up, the date of each file, and the label of the tape containing the files. If you need to restore a file, the file information log will make it much easier to find the proper tape. The error log should contain a listing of the errors that occur during the backup process. This is especially important if you run your backups automatically (like under cron). Always monitor your log files to make sure that each backup was done successfully. Check each log for messages that might indicate a problem (you can even write scripts to do this for you automatically).
BRU Solution: BRU allows you to create log files by redirecting their output to a file. The standard output and the error output should be saved in different files and you can compress them to save space if the files become large. BRU also keeps an execution log. This log contains information on who started BRU, when it began, when it finished, and any error messages that occurred during the execution. In case of difficulties, you can check the execution log to identify the problem.
11. Failing to label your backup tapes.
This is not fatal, but it can certainly cause a lot of confusion when you are trying to find the tape you need (remember when you taped all of those HBO movies?). Many users prefer setting up a tape management system and keeping a database containing the tape label and information about the archive. Even if you are currently using this type of setup, it's still a good idea to label each tape (in case the database crashes) with at least the date of the backup, the backup level, the filesystems backed up, and any other pertinent information.
BRU Solution: In order to reduce some of the problems associated with keeping track of tapes, BRU allows you to write up to 63 characters of label information at the beginning of each archive. This label can contain any information desired and can be retrieved with a simple command. The label information can then be read by the operator or used as part of the tape management system.