There are a number of software packages that allow you to perform backups. Some are vendor specific, and others are quite commonly available. Each may have particular benefits in a particular environment. We'll outline a few of the more common ones here, including a few that you might not otherwise consider. You should consult your local documentation to see if there are special programs available with your system.
The simplest form of backup is to make simple copies of your files and directories. You might make those copies to local disk, to removable disk, to tape, or to some other media. Some file copy programs will properly duplicate modification and access times, and copy owner and protection information, if you are super-user or the files belong to you. They seldom recreate links, however. Examples include:
There are several programs that are available to make simple archives packed into disk files or onto tape. These are usually capable of storing all directory information about a file, and restoring much of it if the correct options are used. Running these programs may result in a change of either (or both) the atime and the ctime of items archived, however.
You can improvise your own backup encryption if you have an encryption program that can be used as a filter and you use a backup program that can write to a file, such as the dump , cpio , or tar commands. For example, to make an encrypted tape archive using the tar command and the des encryption program, you might use the following command:
# tar cf - dirs and files | des -ef | dd bs=10240 of=/dev/rm8
Although software encryption has potential drawbacks (for example, the software encryption program can be compromised so it records all passwords), this method is certainly preferable to storing sensitive information on unencrypted backup.
Here is an example: suppose you have a des encryption program called des which prompts the user for a key and then encrypts its standard input to standard output. You could use this program with the dump (called ufsdump under Solaris) program to back up the file system /u to the device /dev/rmt8 with the command:
# dump f - /u | des -e | dd bs=10240 of=/dev/rmt8 Enter key:
# tar cf - /u | des -e | dd bs=10240 of=/dev/rmt8 Enter key:
To read these files back, you would use the following command sequences:
# dd bs=10240 if=/dev/rmt8 | des -d | restore fi - Enter key:
# dd bs=10240 if=/dev/rmt8 | des -d | tar xpBfv - Enter key:
In both of these examples, the backup programs are instructed to send the backup of file systems to standard output. The output is then encrypted and written to the tape drive.
A few programs can be used to do backups across a network link. Thus, you can do backups on one machine, and write the results to another. An obvious example would be using a program that can write to stdout, and then piping the output to a remote shell. Some programs are better integrated with networks, however.
There are several commercial backup and restore utilities. Several of them feature special options that make indexing files or staging little-used files to slower storage (such as write-once optical media) easier. Unfortunately, lack of portability across multiple platforms, and compatibility with sites that may not have the software installed, might be drawbacks for many users. Be sure to fully evaluate the conditions under which you'll need to use the program and decide on a backup strategy before purchasing the software.
Most backup programs check the access and modification times on files and directories to determine which entries need to be stored to the archive. Thus, you can force an entry to be included (or not included) by altering these times. The touch command enables you to do so quickly and efficiently.
However, many programs that do backups will cause the access time on files and directories to be updated when they are read for the backup. As this behavior might break other software that depends on the access times, these programs sometimes use the utime system call to reset the access time back to the value it had prior to the backup.
Unfortunately, using the ctime () system call will cause the inode change time, the ctime, to be altered. There is no filesystem call to set the ctime back to what it was, so the ctime remains altered. This is a bane to system security investigations, because it wipes out an important piece of information about files that may have been altered by an intruder.
For this reason, we suggest that you determine the behavior in this regard by any candidate backup program and choose one that does not alter file times. When considering a commercial backup system (or when designing your own), it is wise to avoid a system that changes the ctime or atime stored in the inode.