This program, which is a standard part of all major Linux distributions, is a simple but popular backup tool. It’s described in more detail in the next section. This program performs backups and restores on a file-by-file basis, placing all files in a carrier file. It’s also frequently used to create tarballs, which are disk-based archives of files that can be moved across a network, placed on removable media, and so on. Tarballs are commonly used to distribute program source and executable files.

The cpio program is conceptually similar to tar, in that it’s a file-by-file backup tool that creates an archive file. This file can be compressed or copied to a backup medium.

The dump program is another file-by-file copying program; however, dump is tied to a specific filesystem, such as ext2fs or XFS. It reads filesystem data structures at a lower level than tar or cpio, and can therefore back up files in a slightly less intrusive way. Unfortunately, versions of dump are not available for all filesystems; in 2004, only ext2fs/ext3fs and XFS have dump programs, of common Linux filesystems. Worse, with 2.4.x and later kernels, dump may not work reliably, so it shouldn’t be used. (See http://lwn.net/2001/0503/a/lt-dump.php3 for a mailing list message from Linus Torvalds on this subject.) To restore data backed up using dump, you must use a separate restore program.

This program works at a still lower level than dump; instead of backing up individual files, it backs up disk sectors that are marked as being used. This method of operation means that Partition Image is tied to the filesystem you use. As of Version 0.6.4, stable filesystems are ext2fs/ext3fs, ReiserFS, JFS, XFS, FAT, and HPFS. UFS and HFS are considered beta, while NTFS support is marked as experimental. This package can only back up and restore an entire partition, which makes it most useful for creating images of just-installed desktop systems and the like, rather than backups from which individual files might need to be retrieved in the future. You can learn more at http://www.partimage.org.

Although the Linux file copy command, cp, is seldom considered a backup tool, it can be used in this capacity, particularly with removable disk and removable hard disk media. Using the -a parameter performs a recursive copy that preserves most file metadata. Because cp performs a file-by-file copy without using a carrier file, it’s most useful for backing up relatively limited numbers of files to removable disks.

The Backup and Recovery Utility is a commercial backup tool for Linux and other Unix-like systems. It includes compression and provides easier file restore operations than are available from most open source backup programs. It also ships with a GUI, although you can use command-line tools, as well. Check http://www.bru.com for details.

Veritas (http://www.veritas.com) offers a line of commercial network-enabled backup products for Linux, Windows, and other platforms.

Legato (http://www.legato.com), like Veritas, offers commercial network backup products for Linux, Windows, and other platforms.

This command uses /dev/st0 as the archive’s filename. This filename corresponds to a rewinding SCSI tape device, which automatically rewinds after every operation. A nonrewinding SCSI tape device, which might be used when packing multiple archives on a single tape in an incremental backup scheme, is /dev/nst0. ATA tape devices use the device filenames /dev/ht0 and /dev/nht0 for rewinding and nonrewinding devices, respectively. If you back up to a removable hard disk, you can use a similar command, but you specify a partition on the disk (such as /dev/hde5) or a filename on a mounted disk filesystem (such as /mnt/backup/05-05-backup.tar).

This example command didn’t include the --gzip or --bzip2 options. The idea is that the tape device probably provides its own compression. When backing up to a disk backup device, chances are you’d enable compression.

The --one-file-system option prevents backup of data from partitions that aren’t explicitly listed as backup targets. This option is often used as a means of preventing backup of mounted removable media and the /proc filesystem, which holds pseudo-files that could cause real problems when restored. Alternatively, you could use --exclude or --exclude-from to explicitly exclude such directories from being backed up.

The order of the directories in the backup command is potentially important. This example backs up the /home directory first, followed by root (/) and /usr. Because tape is a sequential-access medium, restores must read all preceding data, which means that you want the directories with files that are most likely to need recovery to appear first. In this example, the idea is that users might accidentally delete files and request their recovery, so you want those files to be first in the archive. You might have other priorities depending on your needs, though.

The first approach to using optical media is to treat these media much like a tape: store a tarball (or other archive file) directly to the optical medium. Typically, you’ll create a tarball on disk and then use cdrecord to copy it to the optical disc, or you can pipe the output of tar directly to cdrecord. This approach has the drawback that non-Unix OSs may have a hard time reading the backup. On the other hand, instructions for doing tape backups and restores need relatively few changes. Restores work precisely as they do for tapes, except that you specify a CD-ROM device’s filename rather than a tape device’s filename, and mt isn’t used.

A variant on the preceding approach is to store tarballs (or other archive files) on a filesystem, which is recorded to the optical disc. To do this, you create a tarball on disk, create an ISO-9660 filesystem containing that tarball using mkisofs, and then record the ISO-9660 filesystem to the optical disc using cdrecord. (You can pipe some of these operations together or use GUI tools, such as X-CD-Roast, to help with some parts of the job.) This approach is more complex initially, but it makes the archive easier to access from non-Linux systems. You can also include text files (perhaps including an index of files in the tarball) or other explanatory materials in the disc’s filesystem, which can make access easier. Because most people and OSs expect optical discs to have ISO-9660 or other filesystems, this approach is less likely to cause confusion when accessing the media in the future.

The final backup method is to store files directly on an optical disc’s ISO-9660 filesystem. To do this, you use normal CD-R creation tools, such as mkisofs and cdrecord, or GUI frontends to these tools, such as X-CD-Roast. This approach makes recovery of arbitrary files relatively easy; you can mount the disc and access the files just as you would the original files on the hard disk. The drawback is that you’ll lose some file metadata. (Precisely how much you lose depends on the options you choose.)

In a partial restore, you need to restore only a few files to a system that’s basically functional. The files could be user datafiles or system files, but they’re not critical to the basic functioning of the computer or its backup and restore software. To perform a partial restore, you can basically run the backup process in reverse, although specifying the precise files can be tricky, as described shortly.

In a full restore, you need to restore all of a computer’s files. These are typically necessary when a hard disk fails completely, when a computer is stolen, or when you intentionally replace one computer with a new one. Full restores are much trickier than partial restores because you need some way to run the restore software on a computer that holds no OS. Thus, you must carefully plan how to perform your full restore before the need arises. Attempting to plan the restore when a server has crashed, and your boss is demanding it be restored immediately, is stress-inducing and will result in wasted time as you try to work out a solution.

You can create an emergency disk that enables you to boot a minimal Linux system and direct the restore process much as if you were running a partial restore. You can either prepare your own emergency disk system or locate one on the Internet. Several options for the latter exist, ranging from floppy-based systems to Linux systems that boot from CD-ROM. Examples include Tom’s Root/Boot (a.k.a. tomsrtbt, http://www.toms.net/rb/), a floppy-based system; ZipSlack (http://www.slackware.com/zipslack/), a variant of Slackware designed to fit on a 100-MB Zip disk; and Knoppix (http://www.knoppix.org/), a Debian variant that boots from a CD-R. Many other variants exist, as well; a web search on keywords that are important to you may turn up helpful pointers. If you have specific needs, such as an ability to restore using particular software, be sure that your needs are met by the option you pick, or create your own custom variant that includes the software you need.

Some administrators like to create a minimal emergency OS installation alongside the regular OS installation. This practice enables you to boot the emergency installation in case of a serious problem with the main installation. This practice requires extra planning beforehand, though, and it won’t help in case of a complete hard disk failure, system theft, or other catastrophic problems. It can, however, be a helpful approach in case of massive filesystem corruption or other problems that don’t damage the emergency system.

You can reinstall the core OS files and use this system to restore your main system. When doing a truly full restore, this practice works best if you reinstall your OS as a secondary OS, much like an emergency OS installation; trying to restore a backup over a working OS is an iffy proposition because you might be left with a bizarre mish-mash of files. Alternatively, you can reinstall the OS and all its files, and then perform a partial restore of user files alone. This approach works well if you want to upgrade to a newer version of your distribution or to another distribution, but it’s likely to entail additional effort in reconfiguring your new OS installation.

You can enlist the aid of another computer in your restore procedures. Place a new hard disk and a backup device in an existing Linux system and use that system to restore your failed system’s files to the new hard disk. You can then move the new hard disk to the target computer and reboot it into the restored OS. This approach is conceptually similar to using an emergency OS or an emergency disk, but it uses an entirely separate computer as a key component. Juggling the physical disks can be tedious, though, and you may run into problems related to the way the two computers handle the disk’s cylinder/head/sector (CHS) geometry; if they don’t match, some disk utilities will complain.