|
BDH Technology
Marshalltown, Iowa
|
Linux-Based Automatic Backup System Orginally posted Dec. 2000 Linux Journal -------------------------------------------------- #!/bin/sh # This batch file backs up the data from SHARE # -------------SCRIPT VARIABLES--------------- SHARE="//higgens/d_drive"; DATADIR="DATA"; USERNAME="notneeded" PASSWD="mjdomo"; BACKUPFILE="higgens_data.zip"; BACKUPDRIVE="/dev/hdc1"; BACKUPMP="/mnt/backups/"; SMBMP="/mnt/smb/"; # --------------------------------------------- export PASSWD; echo 'go'; smbumount $SMBMP; smbmount $SHARE $SMBMP -N -n$USERNAME; if (ls $SMBMP$DATADIR) then echo "Backing up $SHARE"; mount -t vfat $BACKUPDRIVE $BACKUPMP; cd $SMBMP; zip -r -u -v $BACKUPMP$BACKUPFILE $DATADIR; cd /; umount $BACKUPDRIVE; fi; smbumount $SMBMP; -------------------------------------------------- The first line, while looking like a comment, actually instructs the computer to use bash to execute the script. Next comes all the shell variables that the main part of the script will use to back up the data on higgins. This practice of putting the case-specific values in variables at the beginning of the script allows the user to make new versions for new computers very quickly by copying the basic script and changing a few easily seen values. Listing 2 shows a different set of variables for a Windows 98 machine (``rick'' with a shared C: drive) and a Windows NT machine (``tc'' with a shared folder named ``data''). Note how the Windows NT variables need to specify a user name and the password associated with that username. ( Listing 2. Variables for the Windows Machines ) -------------------------------------------------- # -------------SCRIPT VARIABLES for rick-----------< SHARE="//rick/rick_c"; DATADIR="Data"; USERNAME="notneeded" PASSWD="icepick"; BACKUPFILE="rick_data.zip"; BACKUPDRIVE="/dev/hdc1"; BACKUPMP="/mnt/backups/"; SMBMP="/mnt/smb/"; # --------------------------------------------- # -------------SCRIPT VARIABLES for tc--------------- SHARE="//tc/data"; DATADIR="*"; USERNAME="obrien" PASSWD="flyme"; BACKUPFILE="tc_data.zip"; BACKUPDRIVE="/dev/hdc1"; BACKUPMP="/mnt/backups/"; SMBMP="/mnt/smb/"; # --------------------------------------------- -------------------------------------------------- The remaining lines actually do the work. The command export PASSWD puts the password in an environment variable that the smbmount program reads automatically. The smbumount command is executed next in case someone forgot to unmount an SMB share from the mount point. (If there is nothing there, smbumount returns a harmless error message and the script continues.) The smbmount program then attempts to mount the remote share. -N switch instructs it not to ask for a password to replace the value of the PASSWD environment variable. The -n switch communicates the username to smbmount. An if statement checks to see if the specified backup files actually exist before doing any backup work in case the network may be down or the remote computer is switched off. In this case the script will terminate after making the mount point available again. If the Linux machine can access the remote files, all archiving is done with the zip command. The -r switch is the standard recursion option, which makes zip go through every subfolder of the data directory. The -u puts zip in update mode, where it will only add or change files that are not already archived or those that have changed. The -v parameter instructs zip to verbosely show the names of every file it checks on the display-- a useful option for troubleshooting. After a backup script has been set up for each computer, you can make a simple script named master to call each of the backup scripts sequentially. An example of my master script is shown in Listing 3. ( Listing 3. Master Script ) -------------------------------------------------- #!/bin/sh #this script calls the individual backup scripts /root/backup/higgins /root/backup/rick /root/backup/tc #now our data is backed up -------------------------------------------------- Activating the System After all the scripts have been written, you can put a symbolic link to the master script in one of the /etc/cron.d subdirectories so that the computer will take care of the backups automatically. For my setup, I typed ln -s /root/backup/master /etc/cron.d/weekly/master to set automatic weekly backups. You can back up on a daily basis if you need to since the update option of archiving utilities minimizes resource requirements. The first usage of a backup script, however, will require a lot of network bandwidth and CPU time. Hence, you may want to consider running it for the first time by hand or with the at command at night. Caveats Five important points should be noted: 1. Any shell script with passwords should be made unreadable by anyone but the owner by using the chmod go-r command. If your data is very sensitive, you need to set up adequate security measures to keep industrial spies from hacking into your Linux machine and stealing your centralized data. See the Linux security HOWTO for more information. 2. The smbmount program tends to vary slightly across different distributions of Linux. Hence, if the scripts in this article don't work quite right for you, check out the man pages to see how your version of smbmount handles its command-line options. 3 . Users of the Windows computers must be taught to keep their data under a central directory, such as ``users'' or ``data'', instead of several random directories spread across the hard drives. Some people are too lazy to move their files into a central directory, despite the fact that it takes only five seconds. You may have to actually move their files yourself before they will even start using the centralized directory. Remember, though, that these users may be the greatest threat to your organization in terms of data loss since they never bother to make backup copies of their own data. 4 . Finally, a hard drive is a very practical place to put the backups of irreplaceable data. My archive files use less than 400MB of hard disk and contain more than a 1.5GB worth of data. However, you may want to consider obtaining a large-capacity, removable drive for your Linux machine. With this, you can occasionally copy the archive files from your hard disk to a removable disk and take them home in case of physical destruction or theft of the machine. Conclusion A Linux-based network backup system for irreplaceable data files on many networked computers is inexpensive, reliable, easy to set up, trivial to expand and extremely practical. With just an hour of time you can potentially save your group or company many thousands of dollars in the case of a hard drive crash. Currently, my Pentium 150 workstation keeps archives of years of mission-critical data from eight computers spread across three buildings and two subnets. It takes me less than two minutes to add a new computer to the system due to the use of shell variables in the scripts. This is the kind of task Linux was born to do. You can take an old surplus computer, make it ``headless'' with no keyboard or monitor and stick it somewhere in a closet where it will humbly do its work unseen. You can also run it on your personal workstation since the Linux tools can run in the background. You can set up an FTP server on the Linux machine on the fly if you need to restore files to a crashed computer or simply take the hard drive out and stick it inside a Windows machine. Since Linux has been designed to coexist with many different computers and operating systems, one can adapt the scripts to back up many different kinds of computers, including other Linux machines via NFS and even MacIntosh computers with the netatalk and hfs packages. |

