No-brainer backup

by Jeff Forsythe, Sr.

 Solaris ships with a program of great interest to all administrators: ufsdump. You use this program to create backups of your UNIX File Systems (UFS). It's a very powerful command that serves all but the very extraordinary circumstances, and it's free!

 The ufsdump command's syntax is easy to learn and use. You tell ufsdump what options you want, give it the arguments it needs, slap a tape in the drive, and forget about it until the next day. If you use cron to schedule your backups, you won't even have to repeat the process, except for slapping a tape into the drive. What could be easier?

 The real power of the ufsdump command comes from its companion program, ufsrestore. The ufsrestore command allows for full or selective restores just like any other restore program, but it has a cool feature unlike almost all other restore programs. And, those that share this feature usually cost thousands of dollars (ufsrestore is also free). This feature is interactive restoration.

 Interactive restores allow you to view the contents of the tape, traverse the directory structure of the file system you backed up, and select only the files, directories, or file systems that you want to restore. Once you're satisfied with your selections, you can extract the information back to the disk. This feature is extremely powerful because it allows you to determine whether your file(s) are on the tape prior to running the restore that will potentially save you hours.

 Because you're a smart administrator, you know that nothing short of a nightly full system backup will do. Let's look at the example full system backup in Listing A.

 Listing A: ufsdump Full System Backup

#!/bin/sh

##############################################

#

# SHELL:                full_bkup.sh

# DATE WRITTEN: 03/15/1998   JAF, Sr.

# DATE UPDATED:

# PURPOSE:      Full System Backup

# USAGE:                full_bkup.sh

# FLAGS:                None

# ARGUMENTS:    None

# RETURNS:      0 - Nominal

#               # - ufsdump return status

# CALLS:                logmsg.fnc

#               /usr/sbin/ufsdump

# CALLED-BY:    root's cron

# ERRATA:       None

# LIMITATIONS:  Doesn't check for tape in

#               drive before running.

#               Doesn't kick current users

#               off before proceeding.

# PLANS:                Backup /etc/vfstab as the

#               first data set on each tape

#               to make it easier to find

#               what you are looking for.

#

############################################## 



# Create /etc/nologin to prevent logins

echo "FULL SYSTEM BACKUP IN PROGRESS, TRY AGAIN LATER" > /etc/nologin



# Rewind tape (check return status to see if no tape?)

# Backup all filesystems to /dev/rmt/1 (rmt/0 is default)



mt -f /dev/rmt/1 rewind

grep ufs /etc/vfstab | grep -v "^#" | while read COOK \ RAW FS REST

do

        /usr/sbin/ufsdump 0uf /dev/rmt/1n ${FS}

        RS=$?

done 



# Remove /etc/nologin to allow logins again

rm -f /etc/nologin



exit ${RS}

We must first give credit to the Administrative Office of the U.S. Courts for writing the grep/while/read loop. We added the FS variable and wrapped the rest of the code around their loop. The first grep gets all UNIX File System lines from the /etc/vfstab and sends them to the second grep, which excludes those that have been commented out. It sends them to the while read statement, which puts each field into the variables: COOK, RAW, FS, and REST. The COOK variable contains the cooked device. The RAW variable contains the raw device, which is what ufsdump requires. FS contains the file system name (which can be used for logging purposes), and REST contains the rest of the line. We're not, however, going to use the COOK, FS, and REST variables in this example. The ufsdump command is then called within the loop to backup the RAW file system. Note that this command supports the use of the no-rewind device. This allows us to stack the file systems one after another on the tape. The ufsdump options we use are 0uf. The zero option says this is going to be a full backup of the file system. We explain the numbering system below. The "u" says that ufsdump should update the /etc/dumpdates file, which is a log of the usage of ufsdump. And, the "f" option says that we will be sending the output from ufsdump to a file, or in this case a tape drive's no-rewind device file (/dev/rmt/1n). There are many more options to ufsdump; you should read the man pages to reveal the power locked in ufsdump. When looking at the man pages, look closely at the l, o, and s options--they are quite powerful. The syntax of ufsdump is:
ufsdump [options] [args]

Options are followed by arguments. The argument in our example, /dev/rmt/1n, is an argument to the f option. The 0 and u options require no arguments. The rule here is that arguments must be in the same order as the options they go with. We'll see an example of this when we talk about ufsrestore below.

 It's hard to believe in this day and age, but some administrators still don't perform full system backups every night. It's true. There are shops out there that play the odds. If this is you, no lecture, just two words on what ufsdump has to offer for you. Incremental backups! You can perform backups at 10 different levels numbered 0-9. So, that's what those numbers are for! Each number backs up all files that have been added or changed since the next lowest numbered backup. As we previously stated, level 0 is a full backup. Like a tornado, it gets everything in its path. A level 1 backup gets everything that has changed since the last level 0 backup. A level 2 gets everything that has changed since the last level 1, and so on. So, in the example given in the man pages, if you perform a level 2 backup on Monday and then a level 4 on Tuesday, a subsequent level 3 on Wednesday would get all files that were added or changed since the level 2 on Monday. This means that you can still perform nightly backups but you don't have to get everything every night. And yes, before you ask, you'll have to use each incremental tape to perform the restore in the event of a crash, but ufsrestore makes restoring very easy. More importantly, isn't an incremental backup better than none at all? The backup scheme is left to you and your local requirements.

Restoring

The useful ufsrestore command is also standard with Solaris. There are two main ways to use ufsrestore: interactively and in batch. We'll describe each briefly.You'll also want to read the ufsrestore man pages closely, because they're full of useful information.

 A full restore uses the r option (r stands for recursive). The following example restores the entire contents of the data set to the current directory:

ufsrestore rf /dev/rmt/1

If you perform this command at the root level (/), it will restore the file system(s) that are on the tape to their original location. If you decide to use a combination of full and incremental backups, you would use the above command to extract the files from the last full backup and then each of the increments in the order they were performed.

 An interactive restore is the coolest thing going. The ufsrestore command allows you to view the contents of the tape and select what you want to restore before performing the actual restore. It does so in a quick manner. You no longer need to run a file's table of contents to decide if your information was on that volume. Also, you no longer have to run the restore command and hope that it's there. You've done both of these for sure. Now, you can run ufsrestore in interactive mode and find your files using the UNIX commands you've become accustomed to, such as: cd, ls, pwd, etc. You'll also need to learn a few new commands, such as add, delete, and extract, which are the three most important. The interactive restore syntax looks like this:

ufsrestore ifs /dev/rmt/1n 1

The "i" is for interactive, the "f" for file (tape device in our example), and the "s" is for skip-to. The i doesn't require any arguments, but the f and s do. And, as you can see (as we said you would), they are in the same order as the options. For instance,
ufsrestore ifs 1 /dev/rmt/1n

wouldn't work, because the 1 argument doesn't go with the f option. You know that interactive means you get to work with the command while it's running, and you know what the tape device is. But, what about that skip-to thing? Well, this allows you to skip to the nth data set from your present location on the tape. If you backup four data sets on each tape and you want to restore the third data set, you would first rewind the tape and then use a 3 as the argument. This is similar to the fsf option you may be used to from other backup commands, but remember that it's a skip-to, not a skip over such as fsf uses. Skip-to is much easier to use because it's intuitive! So, when you run these commands:
mt -f /dev/rmt/1 rewind

ufsrestore ifs /dev/rmt/1n 1

the tape is rewound, the first data set is found, and the table of contents for that data set is read into memory. This takes a few seconds to a minute (depending on where the data set is on tape). If there are multiple data sets on tape, make sure you use the no-rewind device. You're presented with the ufsrestore > prompt and you can start looking for the files, directories, or file systems you want to restore. Use the cd and ls commands to find your files. Once you've found your file, just type add filename and press [Enter]. This adds the file to a buffer to be restored later. You can tell this by using the ls command, it shows an asterisk (*) beside the file name if it has been added. If you accidentally add a file you don't want, you can delete it from the buffer (as in: delete filename). You can use cd and pwd to get around. When you're ready to restore, just type extract and walk away. The ufsrestore command then goes into a batch mode and restores the files you marked.

Summary

We've only touched on the power of these commands. Use the man pages to their fullest and experiment a lot with ufsdump and ufsrestore. You'll be very glad you did. Even if you already own and regularly use one of those expensive packages that does it all, you probably still use tar or cpio to copy single files or directories to tape from time to time. These commands will make it much easier to do this, and even easier yet to restore. No more wondering whether or not you are restoring the files you intend, just fire up that interactive restore and you'll know.
 

<<  Back to Tech Corner