dumpall backup script

Script overview:

This script will dump all local mounted file systems on a system to tape. It can send output to a log file and via email.  It is portable between Solaris 2.x and Digital/Compaq Unix 4.0x. Because of differences in the underlying "ufsdump" and "vdump" commands, this script has different capabilities between Sun and DEC.  

Solaris:

This script can back up both standard UFS file systems and Veritas vxfs file systems. Because it uses device names rather than mount points in the ufsdump or vxdump command, it can be run as a non-root user. ufsdump and vxdump support being run as a user in the "sys" group because the disk device files are readable by the "sys" group. This is especially useful when performing network based backups. This allows a the central computer controlling the backups to run it's "rsh" commands as a non root user.

Sun supports the use of a tape drive over the network in the ufsdump program, which allows the use of a central tape host. And because the central tape host does not need a root user id for allowing inbound tape requests, this also helps security.

Digital / Compaq Unix

As of Digital Unix 4.0D, the "vdump" command can backup either UFS or ADVFS file systems. So this script assumes that "vdump" will work on whatever file systems are locally mounted. If you are running UFS file systems on a pre 4.0D system, you can modify the "OSF1_dump" script to check for the fstype.

Unfortunately, Digital Unix does not lend itself as easily to network based tape backups as Solaris. So this script makes no provisions for network backups for a Digital host.

One way to use vdump to a remote tape drive is using this command: vdump -b64 0uf - /somefilesystem | rsh tapehost dd of=/dev/nrmt0h bs=64k The block size parameters are needed to make sure the sending and receiving programs are in sync as to what block size to use.

Options:

 -l|-logfile 
        Write output to the specified log file.
 -mail|-email 
        Send log file output to the specified email address
 -d|-dev 
        Specifies the tape device to use.  Must be the non-rewinding 
        device for the script to work properly.  Default device is
        $TAPE if set, or /dev/nrmt0h
 -unload
        Unloads the tape from the drive when the backup is done.

These options can be specified either via the command line or via a configuration file. The configuration file resides in the same directory as the executable, and can either be named "dumpall.rc" or "dumpall.<hostname>.rc". This allows you to easily override default settings with command line parameters, or store the configuration files in a central spot. The program will take all of its parameters from the first location it finds. It searches for parameters in the following order:

Tape Format:

Each file system backed up will be it's own file mark on the backup tape. (This is why a "non-rewinding tape device must be used). There will be one file mark for each file system, plus an additional file mark that consists of the backup script's output file written to the tape in "tar" format. The individual backup file marks will be in the file format needed for backing up each file system. For Sun, the format will be either "ufsdump" format or "vxdump" format. For Digital Unix, it will be in "vdump" format for either ADVFS or UFS file systems.

Installation and Setup

If you are performing backups to a local tape drive, and are running the backups as root, the installation is as simple can be. Simply copy "dumpall" to a local or NFS mounted directory on the system being backed up. Create a "dumpall.rc" or "dumpall.<system name>.rc" file to contain the default parameters, and add a line to the root crontab if so desired.

If you are running the command via "rsh" from a central server, and/or are writing to a tape drive over the network, the installation gets slightly more complicated. The simplest thing to do would be to just set up the /.rhosts files so that root could rsh from the central backup server to the client host, and vice versa. The problem with this is that this is a huge security hole.

The "dumpall" client system can be set up so that it is run as a non-root user from the central backup server. And tape server can be set up so that the user id for remote tape access is restricted so that it can not do anything except run the tape drive. This requires setup on both the backup server and backup client systems. In our example, we have two systems, "tapehost" and "backupclient" . The "dumpall" command be run via "rsh" from tapehost, and will run on "backupclient" as user "backup". The tape drive on "tapehost" will be controlled from "backupclient" using the user name "tape". Note, depending on how your systems are set up, you may need fully qualified hostnames in the .rhosts file, such as "backupclient.mydomain.com".

Backup client modifications:

The dumpall script must be copied to the backup client, and a dumpall.rc file should be set up in the same directory as the dumpall script. The backup client needs to have a non root user id added to it that is in the "sys" group. This user will need to have it's .rhosts file set up to allow inbound "rsh" calls from the backup server. For security, the script files, .rhosts file, and /home/backup directory should all be owned by root and only writeable by root. The "backup" user can have a locked password because it does not need to support logins, it just needs to be able to run commands via "rsh"., for example:

/etc/passwd entry:
backup:x:59999:3:Backup User:/home/backup:/bin/ksh

/home/backup/.rhosts contents:
tapehost root

Backup server modifications:

The backup server needs to have a non root user id added to it that can be used by the backup client for tape drive communication. Because any user can read and write to the tape drive, this id does not need to belong to any special group, and it is better to make it as unprivileged an account as possible. This id will need a .rhosts file that will allow rsh commands from root or backup on the backup client systems. In order to prevent the id from being used for anything but tape control, the start up script for the account will be a Perl script that limits what the account can do. When "ufsrestore" and "ufsdump" access a tape drive over the network, they do so by issuing an "rsh tapehost /etc/rmt" command. The "/etc/rmt" command then reads and writes data over standard in and standard out over the "rsh" network connection. The tape id start up script will only allow the "/etc/rmt" command to be executed. If any other command is passed to the start up script, it will exit quietly. You will need to copy the rmt perl script into the home dir for the "tape" id. As with the backup user id, all script files, home dirs, and .rhosts files for the "tape" id should be owned by, and only writeable by, root.

/etc/passwd entry on tapehost:
tape:x:60000:60001:Tape drive control account for rdump:/home/tape:/home/tape/rmt

/home/tape/.rhosts contents:
backupclient    root
backupclient    backup

In addition to these steps, the backup server will need a script that calls the "dumpall" script on each client machine via "rsh". While dumpall could be run via cron on each individual client system, the scheduling of the dumpall process can be a problem. Each backup needs to wait until the previous backup finishes using the tape drive. If dumpall was run independently on each client system, you would need to provide a large buffer of time between each backup to handle variations in backup time. It is more reliable to control backups centrally. See the appendix at the bottom for a simple central backup script.

Testing the setup:

Before running the backup scripts, you should test the rsh connectivity between the backup client and the tapehost system.

Security Concerns:

This backup method is more secure than the typical method of performing network backups, but it still introduces possible areas for security exploits. This method is more secure than some other methods because:

The vulnerabilities that this script introduces are:

If these potential vulnerabilities are too great for your environment, then your alternatives might have to involve solutions such as local tape drives, encrypting the "ufsdump" data stream prior to sending it over the network, or using "ssh" to make for a more secure data channel.

Disaster Recovery Concerns:

Using network based backup for the OS does complicate disaster recovery scenarios. When restoring a file system, you will have to remember that the backup tape contains backup files for multiple systems. You will need to skip over the unneeded backup file marks using "mt". This process will be easier if you have access to the log files that correspond to the backup tape you are processing. In addition, a typical DR procedure involves booting off of CD-ROM media and assumes that you can restore from a local tape drive. Possible solutions to this problem include:

Appendix:


Back Last Updated November 2, 1999