UNIX System Administration Handbook - Evi Nemeth [114]
Table 10.2 gives some hints for our four example systems.
Table 10.2 Device files for the default SCSI tape drive
See page 247 for information about device numbers.
If you choose the rewinding device by accident, you will end up saving only the last filesystem dumped. Since dump does not have any idea where the tape is positioned, this mistake does not cause errors. The situation only becomes apparent when you try to restore files.
When you use rdump to dump to a remote system, you specify the identity of the remote tape drive as hostname:device; for example,
# rdump 0uf anchor:/dev/nst0 /spare
Permission to access remote tape drives is controlled by the .rhosts mechanism. We recommend that you use an SSH tunnel instead. See page 672 for more information.
In the past, you had to tell dump exactly how long your tapes were so that it could stop writing before it ran off the end of a tape. Most modern tape drives can tell when they have reached the end of a tape and can report that fact back to dump, which then rewinds and ejects the current tape and requests a new one. Since the variability of hardware compression makes the “virtual length” of each tape somewhat indeterminate, it’s always best to rely on the end-of-tape indication if your hardware and your version of dump support it.
Unfortunately, the nifty end-of-tape detection became available long after the various versions of UNIX had split apart from one another, so different dumps handle the end of the tape in different ways. Some assume that tape drives are capable of generating an EOT unless you tell them otherwise; they place no default limit on the size of a tape. Others assume a tape length of 2,300 feet and a density of 1,600 bpi, which are perfectly good defaults for the 9-track tapes of 15 years ago but not reasonable for today’s media. These versions of dump will usually honor an EOT if it occurs before the expected end of the tape, so the right thing to do in these cases is to lie to dump and tell it that the tape is much longer than it really is.
All versions of dump understand the d and s options, which specify the tape density in bytes per inch and the tape length in cubits, respectively. (OK, OK, it’s actually feet.) A few more-sensible versions let you specify sizes in kilobytes. For those versions that don’t, you must do a little bit of arithmetic to express the size you want.
For example, let’s suppose we want to do a level 5 dump of /work to a DDS-1 (DAT) drive whose native capacity is 1GB and whose typical compressed capacity is about 1.5GB. DAT drives can report EOT, so we need to lie to dump and set the tape size to a value that’s much bigger than 1.5GB, say 4GB. That works out to about 60 kilofeet at 6,250 bpi:
# dump 5usdf 60000 6250 /dev/rst0 /work
DUMP: Date of this level 5 dump: Mon May 8 16:59:45 2000
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/hda2 (/work) to /dev/rst0
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 942223 tape blocks on 0.23 tape(s).
...
The flags 5usdf are followed by the parameters to s (size: 60,000), d (density: 6,250), and f (tape device: /dev/rst0). Finally, the filesystem name (/work), which is always present, is given. Most versions of dump allow you to specify the filesystem by its mount point, as in the example above. Some require you to specify the raw device file.
The last line of output shown above verifies that dump will not attempt to switch tapes on its own initiative, since it believes that only about a quarter of a tape is needed for this dump. It is fine if the number of estimated tapes is more than 1, as long as the specified tape size is larger than the actual tape size. dump will reach the actual EOT before it reaches its own computed limit.
The Solaris dump command has nothing to do with backups; it’s a tool for examining object files. Whenever