IRIX Advanced Site and Server Administration Guide |
As a site administrator, you must make sure there are backups of the files at your site. Users depend on you to recover files that have been accidentally erased, or lost due to hardware problems.
This chapter describes how to create backups of system files. In particular, it discusses:
The available backup utilities. See "Choosing
a Backup Tool".
How to make a backup copy of a single file, or a small number of files.
See "Making Backups".
How to back up a directory or series of directories. See "Backing
Up File Systems".
How to back up entire file systems. See "Backing
Up File Systems".
How to check your backups to make sure they are valid. See "Checking
an Archive".
How to restore file systems and individual files and directories. See
"Restoring
Files and File Systems".
Recovering from a system crash. See "Recovery
after System Corruption".
How to make a bootable backup tape. See "Copying
the Software Distribution".
Backup strategies - how to keep important data from being lost. See "Backup Strategies".
IRIX provides several different utilities for backing up your data:
The System Manager
bru(1M)
Backup(1M) and Restore(1M), which use bru
tar(1M)
cpio(1M)
dump(1M) and restore(1M)
dd(1M)
The sections in this chapter present the most common tasks a site administrator must perform. Each section describes how to perform a task using one or more of the commands listed above.
For a complete list of options for a particular command, see the reference page for that command.
Throughout this chapter we refer to tapes, tape drives, media, and backup media. These terms apply to whichever backup media you use at your site.
Common types of media include:
1/4" cartridge tape, 4-track
1/2" magnetic tape, reel, 9-track
8 mm cartridge
DAT
It should be apparent when certain limitations or conditions do not apply to your specific media. For example, if you back up a 350 MB file system with an 8 mm cartridge drive (which can hold up to 1.2 GB), you probably don't have to worry about using more than one tape. For more information on tape capacities, see "Tape Capacities".
The IRIX system provides different back-up tools, both file system-oriented and file and directory-oriented utilities. Differences between the two kinds of tools are discussed in the next section. The most convenient tool to use is the System Manager, described in detail in the Personal System Administration Guide.
Use whichever programs you like. If many users at your site are already familiar with one backup program, you may wish to use that program consistently. If there are workstations at your site from other manufacturers, you may wish to use a back-up utility that is common to all the workstations.
Two basic types of backup tools are available with IRIX:
File system-oriented programs, like bru, Backup, and dump;
these are designed primarily to back up entire file systems, although bru
can also back up individual files and directories.
File- and directory-oriented programs, like tar and cpio; these can back up entire file systems, but are also convenient for individual files and directories.
In addition, you can use dd(1) to read images exactly as they are written, with or without conversions. The dd command is useful to read data that is written in a format incompatible with the other backup utilities. However, you do not normally use dd to create backups.
The System Manager is the default tool for performing backups on your system. See the Personal System Administration Guide for a complete description of the System Manager and its backup and recovery facilities.
The bru utility is a flexible tool that contains such features as:
file compression
the ability to locate and back up files based on modification date
the ability to calculate space requirements for backups
the ability to check the integrity of the data on the tape
varying levels of ``verbosity'' while performing operations
Because it not only backs up file systems but also individual files and directories, it combines the features of both file system-oriented and file-oriented backup utilities. See the bru(1M) reference page for a complete description of the program's capabilities.
Be aware that although bru is available on a variety of UNIX systems, it is not as widely used as the other backup utilities. At a site that has workstations from a variety of vendors, not all of which provide bru, you may wish to use one of the other IRIX backup utilities for consistency. tar(1M) is the most widely accepted format.
If your site has predominately IRIS workstations, and you don't need to move file system backups between different brands of computers, bru is probably a good choice.
Note that the System Manager backup menu uses the Backup interface to bru to back up workstations.
If a bru backup is made that requires more than one tape, bru stops and prompts you to insert another tape before it continues. Be aware that if bru (or any front end interface to bru) is used in a noninteractive mode (such as through a cron command) and the information fills a tape, bru cannot prompt for a new tape, and automatically overwrites the information it has just written on the tape. Obviously, this is not a good backup practice, and backups of large systems made with bru should be performed interactively.
The Backup and Restore utilities are front end interfaces to bru. They support the remote host name and tape device options, and Backup creates a volume header file listing that Restore uses for recovering the files and directories. For complete information, consult the Backup(1) and Restore reference pages. If you are planning to use the IRIS System Maintenance Menu System Recovery option, you should use Backup or the backup facility of the graphical System Manager, as those are the only formats accepted by the System Maintenance Menu. The System Manager is described in detail in the Personal System Administration Guide.
The dump and restore programs are standard file system backup utilities used on many UNIX systems. The dump program makes incremental backups of entire file systems.
Use restore to retrieve files from a dump archive. With restore, you can restore an entire file system or specific files. It also has an interactive mode that lets you browse the contents of an archive, select specific files, and restore them.
The tar utility backs up files and directories. You can copy files to tape, create tar files, compare files on tape to files on disk, read standard input, and pipe the output of tar to other processes. This command is widely used on UNIX systems worldwide.
Like tar, cpio archives files and directories. With cpio, you can copy files to tape or disk, archive empty directories, swap byte order, create portable ASCII archives, and read from and write to standard output. cpio is also useful for copying files and directories when the cp(1) command is unable to do so. For example, you cannot use cp to copy a directory to a different file system.
The dd program reads from a specified input file (stdin is the default), performs whatever conversions you specify, and writes the result to a specified output file. (stdout is the default.) It is not specifically a backup tool, but has many extremely useful features, including the ability to:
skip specific blocks in an archive
skip blocks of output
change input and output block size
copy a specific number of blocks
perform various data conversions such as byte swapping
Follow these steps when making a backup, no matter which backup utility you use:
Make sure the tape drive is clean. The hardware manual that came with your drive should state how, and how often, to clean the drive.
Dirty tape heads can cause read and write errors. New tapes shed more
oxide than older tapes, so you should clean your drive more frequently
if you use a lot of new tapes.
Make sure you have enough backup media on hand. The bru utility
has an option to check the size of a backup, so you can determine if you
have enough media. You can also use such utilities as du(1) and
df(1) to determine the size of directories and file systems, respectively.
Use good-quality media. Considering the value of your data, you should
use the best quality media you can afford.
If you are backing up an entire file system, for example with bru or dump, run fsck(1M) on the file system to make sure you do not create a tape of a damaged file system. You must unmount a file system before checking it with fsck, so plan your backup schedule accordingly.
This step is not necessary if you are backing up only a few files (for
example, with tar).
The default tape device for any drives you may have is /dev/tape.
If you do not wish to use the default device, you must specify a device
in your backup command line.
Label your backups. If you plan to reuse the media, use pencil. Include
the date, time, name of the machine, the name of the utility. The exact
command line used to make the backup (so you'll remember how to extract
the files later), and a general indication of the contents. If more than
one administrator performs backups at your site, include your name.
Verify the backup when you are finished. Some utilities (such as dump
and bru) provide explicit options to verify a backup. With other
programs, you can simply list the contents of the archive - this is usually
sufficient to catch errors in the backup.
Write-protect your media after you make the backup.
Note the number of times you use each tape. It's sufficient to keep a running tally on the tape label.
See "Storing Backups" for information on safely storing your backups.
The following sections describe different ways to back up data.
The following sections describe how to back up file systems. Although this information is oriented toward file systems, you can also recover individual files from a file system backup.
A file system backup is most useful for:
quickly reconstructing a workstation after a hardware failure
backing up user files on a large multiuser server where the administrator may not be aware of all the subtleties of the users' data
A file system backup made from the System Manager is useful in reconstructing a workstation after a disk failure because it contains the various device nodes and symbolic links used by your system.
To make a backup of your system with the System Manager on any system with a graphical user interface, bring up the System Manager and select the Backup and Restore icon. From this window, follow the prompts to perform your backup. A complete set of instructions for this procedure is available in the Personal System Administration Guide.
Backups made with the System Manager are the easiest to make and use, and are accessible from the System Maintenance Menu if they are full system backups. When you make a full system backup, the command also makes a backup of the files in the disk volume header and saves the information in a file that is stored on tape. This file is used during system recovery to restore a damaged volume header.
The bru command is the shell command used by the System Manager to create backups. If you are using a server and do not have access to the graphical System Manager, use bru instead. Backups made with bru are readable by the System Maintenance Menu and Command Monitor. This command backs up the /usr file system:
bru -c /usr
To back up a file system with Backup, place a tape or other media in the drive. Make sure the tape is locked in the drive. Enter:
Backup /
The Backup command archives the entire system. You can make a specific file system backup of /usr by specifying /usr as the directory name. The current date is saved in the file /etc/lastbackup.
Note: In order to use a Backup tape to restore your system from the System Maintenance Menu, you must make a full system backup. When you make a full system backup, the command also makes a backup of the files in the disk volume header and saves the information in a file that is stored on tape. This file is used during system recovery to restore a damaged volume header.
To use a remote tape drive, use the -h option:
Backup -h guest@alice.cbs.tv.com:/dev/tape /usr/people/ralph
You must have at least guest login privileges on the remote system in order to use a remote tape drive. The file /tmp/volhdrlist contains a list of the root volume header.
The dump utility archives not only regular files, but also device files and special files such as links and named pipes. To recover files from an archive, you use the restore command.The date on which you last ran the dump program is stored in the file /etc/dumpdates when you specify the u key to indicate an update.
This command backs up all files on the /usr file system:
dump 0 /dev/usr
The dump program is described in further detail in "Incremental Backups with dump".
This command copies an image of a file system to the default tape device:
dd if=/dev/usr of=/dev/tape
To back up a single file system (such as /usr) use the following series of commands:
cd /usr
find . -mount -type f -print | cpio -ovBc > /dev/tape
You may wish to prevent certain directories, such as /usr/tmp, from being backed up. In this case, you could use a command such as this one (type the command on one line):
find . -mount -type f -print |
grep -v '^./usr/tmp/' | cpio -ovBc > /dev/tape
This example uses grep to remove all occurrences of ./usr/tmp/ at the beginning of the line. Put additional grep-v commands in the pipeline to remove other unwanted files or directories. Because we use the -mount argument on the find command, we don't have to worry about data that is not mounted on /usr.
For more information on this topic, see the reference pages cpio(1), find(1), and grep(1).
To back up the /usr file system with tar, use the command series:
cd /usr tar cv .
The following sections provide instructions on backing up files and directories with the various utilities available to you. As always, it is recommended that you perform your backups using the graphical System Manager or with bru. If your backup tape is to be read by a different manufacturer's system, however, it is usually best to find out in advance what formats the receiving system is able to use. tar and cpio are the most commonly accepted formats worldwide.
To back up individual files with bru, enter:
bru -c files
You can specify one or more files. You can also read file names from another file:
bru -c `cat listfile`
To back up individual files with tar, use the command:
tar c files
To back up files with cpio, use the command:
cat filelist | cpio -o > /dev/tape
To save specific files that have changed since a particular time, you can use bru with the -n option. The following command backs up files on the /usr file system that have been modified since November 26, 1990:
bru -c -n 26-Nov-1990 /usr
Neither tar nor cpio has this capability built in. However, you can use the find command to archive files that have not been modified in a particular number of days. With tar:
tar cv `find /usr -mtime 5 -type f -o -type othertypes -print`
The left quote marks cause the shell to execute the find command, then send its output to the tar command. The find command locates regular files that have not been modified in five days.
With cpio:
find /usr -mtime 5 -depth -print | cpio -oO /dev/tape
The -depth argument causes find to print the name of the directory after printing the files in that directory. This ensures that cpio has permission to place the files in the directory in case the directory is read-only.
The ``table of contents'' flag, -t, displays the contents of a bru archive:
bru -t
You can combine this with the -v option for more information:
bru -tv
Use up to four `` v'' arguments for the most verbose output possible.
For tar archives, use the v keyword for verbose listing of the archive contents:
tar tv
For cpio archives, use the following command to obtain a verbose listing:
cpio -itvI /dev/tape
Use the -e option with bru for an estimate of how much space is required for an archive:
bru -e /usr
You can compress files as are they are archived. Use the -Z flag:
bru -Z
bru uses a 12-bit LZW file compression algorithm. Note that not all versions of bru support LZW compression. If you plan to transfer a bru archive to another vendor's workstation, make sure the other version of bru supports LZW data compression.
If you add the -v option, bru displays the compression ratio for each file (as a percentage). If you use -t and -Z to display the table of contents of an archive that contains compressed files, bru displays the current file names and compressed sizes, instead of the original file names and sizes before archiving.
The standard or normal default tape device, /dev/tape, will rewind the tape after executing a command. To add additional tape files to the tape, you must use a tape device that will skip forward on the tape and then stop there without rewinding the tape. This is called the no-rewind tape device.
The default no-rewind tape device is /dev/nrtape.
It is assumed that the default tape drive is being used for this operation.
Caution: If you are not careful when appending files to a tape, you can overwrite the existing files and these files will no longer be accessible. It is recommended that you try this procedure on a scratch tape before trying this on an important tape.
When you use tar to first create a tape archive, all the files written to the tape are put into a single tape file. At the end of this tape file is an end of file marker (EOF) and if this is the only tape file, an end of tape (EOT) marker. If additional files are added to this the tape, they will be placed into a second tape file after the first tape file's EOF marker and the final tape file will be followed by an EOT marker. For a more detailed explanation of this see the reference page for tps (7M). To add an additional tape file and subsequently read the tape file, you must skip past the first tape file.
There are two ways to write an additional tape file depending on how the previous tape file was created. These examples will assume that the previous tape file was created using tar unless otherwise specified.
For the first example, the previous tape file was created using the command:
tar cvf /dev/tape [files]
where [files] is a list of filenames on the tape.
This command writes the files onto the tape into a single tape file. When all the files are written, this command will cause the tape to rewind.
Now you want to write a second set of files onto the tape and so you must skip past the first tape file. To do this you need to use the mt command and skip to the end of tape marker (feom). This time you will specify the no-rewind tape device so that when the command is finished, it stops there and doesn't rewind back to the beginning of the tape. Once this is done, you can write your second set of files onto the tape.
mt -t /dev/nrtape feom tar cvf /dev/tape [files]
This process can be repeated for as many tape files as you wish, constrained only by the capacity of your tape.
Another way of appending tape files is to use the no-rewind device when creating the tape files. In this way, the tape is never rewound.
Note: This process will only work if the tape is never removed from the tape drive and for each tar command issued, the no-rewind device is specified.
tar cvf /dev/nrtape [files]
This process can be repeated for as many tape files as you wish.
If at any time you are unsure of whether or not the tape has been rewound, follow the instruction in the first example shown above. If the tape has been rewound and you continue with these steps you will destroy the tar files written previously.
Since there are now multiple tape files on the tape, you must skip forward to find the specific tape file from which you wish to read or extract files. To do this, you must use the mt command and specify how many tape files you want to skip forward (fsf #). Two examples of doing this are shown below.
For the first example, it is assumed that you know which tape file contains the file john_file.
You have 4 tape files on a tape and you want to read the third tape file. This means you want to skip past the first and second tape files and stop the tape there so that you can read the third tape file. To do this you need to use the no-rewind device with the following commands:
mt -t /dev/tape rewind mt -t /dev/nrtape fsf 2 tar xvf /dev/tape john_file
Note, first you use the mt command to rewind the tape to the beginning to verify the starting point of the tape. The second time the mt command is used with the no-rewind device in order to skip past the first two tape files. The regular tape device is used with the tar command. Once the table of contents of this third tape file is listed, the tape will rewind to the beginning of the tape.
For the second example, you have a tape that has many tape files on it and you want to extract a specific file named john_file, but you don't know which tape file contains this file.
You could use the approach discussed above and continue to increase the number of file to skip past and then list the table of contents for the tape file. However, in this case, it would be easier to use the no-rewind device each time you list the table of contents. After each listing of the table of contents check to see if john_file is in that tape file. If yes, then note which tape file the file is in and use the mt and tar commands to extract the file. If no, read the next tape file with the tar command.
mt -t /dev/tape rewind tar tvf /dev/nrtape tar tvf /dev/nrtape tar tvf /dev/nrtape
When you have found the correct tape file, then note how many times you had to execute the tar command. If you found your file after the third tar command, then the file is in the third tape file. At this point you will want to rewind your tape with the following command:
mt -t /dev/tape rewind
To extract this file, you will use the mt command to skip past the first and second tape file and then use the tar command to retrieve the file as follows:
mt -t /dev/nrtape fsf 2 tar xvf /dev/tape john_file
To perform a backup to a tape device that is attached to a remote machine (either a Silicon Graphics system, or any UNIX system), you must know:
the name of the machine
the tape device on the remote machine
the name (preferably un-passworded) of an account on that system.
Note: This procedure assumes that the remote machine is running UNIX and that it does support the BSD rmt(1M) (remote tape protocol).
Caution: Keep in mind that a backup won't do you any good if you can't recover it when you need it. If you make a backup on a non-Silicon Graphics machine, then the only way to recover that backup might depend on having the Silicon Graphics machine running, the non-Silicon Graphics machine running, and the network operational. You must adequately design and test your backup recovery procedure before you need it.
If you do not have a user login name without a password, you will have to set up a .rhosts file on the remote machine. Refer to the reference pages on hosts(4), rhosts(4), and hosts.equiv(4) for information on setting up a .rhosts file.
The reference page for each of the various tape utilities describe the method for accessing a remote tape drive. While it is not necessary for the remote tape drive to be on a Silicon Graphics system, some thought should be given to how these backups will be recovered if it is not a Silicon Graphics system.
The following examples use tar(1), bru(1), and cpio(1) to write to a remote tape drive. In these examples, the <host_name> is the name of the remote system, and the <tape_device> is the name of the device on the remote system. On a Silicon Graphics system, this could be /dev/tape, or a device in /dev/rmt*. If you do not know the name(s) of the available tape devices on the remote system, contact whoever is responsible for maintaining the system, or read the reference page on tps(1).
To use tar(1) to write, read, and extract a tape written on a remote system use the following commands (be sure to type each tar command on one line):
tar cvf guest@<host_name>:/dev/<tape_device> <files_to_backup> tar tvf guest@<host_name>:/dev/<tape_device> tar xvf guest@<host_name>:/dev/<tape_device>
To use bru(1) to write, read, and extract a tape written on a remote machine use the following commands be sure to type each bru command on one line):
bru cvf guest@<host_name>:/dev/<tape_device> <files_to_backup> bru tvf guest@<host_name>:/dev/<tape_device> bru xvf guest@<host_name>:/dev/<tape_device>
To use cpio(1) to write, read and extract a tape written on a remote machine, use the following commands (be sure to type each cpio command on one line):
find <filelist_to_backup> -print | cpio -ovc -C1024000 -O guest@<host_name>:/dev/<tape_device> cpio -itvc -C1024000 -I guest@<host_name>:/dev/<tape_device> cpio -ivc -C1024000 -I guest@<host_name>:/dev/<tape_device>
It is strongly recommended that full system backups be completed on either the local tape drive, or on another Silicon Graphics machine.
If you are performing a critical operation, such as changing the size of a file system, or upgrading hard disks, you should always completely back up the system.
In addition, you should check the integrity of the archive. Sometimes, a backup program will appear to function correctly, but the data is incorrectly copied to the archive.
The following are methods for checking data integrity.
You can compare files that are archived with the original files.
With bru, use the -d option. For example:
bru -d /usr
If you specify a single -d, bru reports when it discovers that a regular file's size or contents have changed since the archive was made.
If you use -dd, bru reports additional differences in modification dates, access modes, number of links for non-directory files, differences in the contents of symbolic links, owner IDs, and group IDs.
If you specify -ddd, bru reports additional differences in host devices, major and minor devices for special files, and time of last access for regular files.
If you use -dddd, bru reports all differences except the time of the last status change, major and minor device numbers for non-special files, and size differences for directories. Usually, -dddd provides information that is meaningful only when verifying a full backup of a relatively static file system.
You can also compare files using tar:
tar C
You see messages about the status of the files. Each message begins with a key character (a letter or symbol) that signifies the status of the file in the archive versus the original file. These characters are shown in Table 6-1.
Key | Meaning: |
---|---|
= | The files compare |
! | The files don't compare |
? | Can't read the disk file |
> | Disk file doesn't exist |
L | Linked to an earlier file on the tape |
S | Symbolic link |
B | Block special file |
C | Character special file |
P | Named pipe |
The cpio program does not have a built-in option to compare files. To compare the files on a cpio archive, you must extract the archive onto disk, then use a comparing program, such as gdiff(1), diff(1), cmp(1), or dircmp(1), or compare the checksum (sum(1)) of the extracted file with that of the original.
The bru program provides an option, -i, to inspect an archive for internal consistency and data integrity. For example:
bru -i
If you add -vv, bru prints information from the archive header block:
bru -ivv
Neither tar nor cpio provides this sort of check. However, listing the contents of an archive is usually sufficient. Also, a reasonable check is to extract the files in the archive whilore sending the output to /dev/null.
The principal reason to make backups of system files is to protect those files from loss in the event of human error or hardware failure. When a file is lost, it must then be restored from a backup. Sometimes entire file systems are lost and must be reconstructed from backups.
You restore an entire file system if there has been data corruption (for example, due to bad tracks); if you remade the file system (for example, if you replaced a disk drive); or if all the files have been accidentally removed.
If your root file system is damaged and your system cannot boot, you will need to restore your system from the System Maintenance Menu. This is the menu that appears when you interrupt the boot sequence before the operating system takes over the machine. To perform this recovery, you need two different tapes: your system backup tape and a bootable tape with the miniroot.
To be used with the System Recovery option of the System Maintenance Menu, the backup tape must have been created with the System Manager or with the Backup(1) command and must be a full system backup (beginning in the root directory (/) and containing all the files and directories on your system). Although the Backup(1) command is a front-end interface to the bru(1) command, Backup also writes the disk volume header on the tape so that the System Recovery option can reconstruct the boot blocks, which are not written to the tape using other backup tools.
For information on creating the system backup, see "Backing Up File Systems". For information on creating the bootable tape, see "Making a Bootable Tape".
If you do not have a full system backup made with the Backup command or System Manager, you will have to reinstall your system if your root or usr file systems are so badly damaged that the operating system cannot boot.
If you need to reinstall the system to read your tapes, install a minimal system configuration and then read your full system backup (made with any backup tool you prefer) over the freshly installed software. Existing files of the same path name on the disk are overwritten during a restore operation, even if they are more recent than the files on tape. This procedure should restore your system to its former state.
When you first start up your machine, you see the following prompt:
Starting up the system.... To perform system maintenance instead, press <Esc>
Press the <Esc> key. You see the following menu:
System Maintenance Menu 1 Start System 2 Install System Software 3 Run Diagnostics 4 Recover System 5 Enter Command Monitor
Enter the numeral 4, and press <Return>. You see the message:
System Recovery... Press Esc to return to the menu.
After a few moments, you see the message:
Insert the installation tape, then press <enter>:
Insert your bootable tape or your original distribution (CD or tape) and press the <Enter> key. You see some messages while the miniroot is loaded. Next you see the message:
Copying installation program to disk....
Several lines of dots appear on your screen while this copy takes place.
You see the message:
CRASH RECOVERY You may type sh to get a shell prompt at most questions. Remote or local restore: ([r]emote, [l]ocal): [l]
Press <Enter> for a local restoration. If your tape drive is on another system accessible by the network, press r and then the <Enter> key. You are prompted for the name of the remote host and the name of the tape device on that host. If you press <Enter> to select a local restoration, you see the message:
Enter the name of the tape device: [/dev/tape]
You may need to enter the exact device name of the tape device on your
system, since the miniroot may not recognize the link to the convenient
/dev/tape file name. As an example, if your tape drive is drive
#2 on your integral SCSI bus (bus 0), the most likely device name is /dev/rmt/tps0d2nr.
If it is drive #3, the device is /dev/rmt/tps0d3nr.
The system prompts you to insert the backup tape. When the tape has been read back onto your system disks, you are prompted to reboot your system.
Ensure that you have a Silicon Graphics distribution tape with installation tools on it. It will say, ContainsInstallationTools.
Determine the remote tape drive you are using.
Insert the tape in the remote drive.
Execute the mtret command on all backup tapes you will be using.
You must edit the /usr/etc/inetd.conf file on the remote system with the tape drive before continuing (each entry below will appear on one continuous line with commands separated by tabs):
Find this entry:
tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/local/boot
And change it to read as follows:
tftp dgram udp wait guest /usr/etc/tftpd tftpd
Bring the system you are recovering to the System Maintenance Menu.
Select option 5) Command Monitor from the System Maintenance
Menu.
Enter the commands:
setenv netaddraddress (address = your internet address)
init
exit
Select 4) Recover System from the System Maintenance Menu.
Follow the directions for recovering from the backup tapes.
When done, exit the program and bring up the system.
Complete information on using the bru command and all its options is available in the bru(1) reference page. This command extracts the entire contents of a backup tape:
bru -x
The Restore command is a shell script that uses bru to extract files from a backup. Tapes made using the graphical System Manager can also be read from the System Maintenance Menu, using Restore. The following are examples of the Restore command:
Restore
You are prompted to insert the tape into the drive. You can recover multi-volume backups with Restore.
To extract a single file, use this command:
Restore file1
With the -h option, you can specify the tape drive on a different host workstation:
Restore -h guest@alice.cbs.tv.com file1
You must have guest login privileges in order to use files from a remote drive.
Files are restored into the current directory if the backup was made with relative path names. Relative path names are those that do not begin with a slash (/) character. Path names that begin with a slash are known as absolute path names. For example, /usr/bin/vi is an absolute path name. The leading slash indicates that the path name begins at the root directory of the system. In contrast, work/special.project/chapter1 is a relative path name since the lack of a leading slash indicates that the path begins with a directory name in the current directory.
Existing files of the same path name on the disk are overwritten during a restore operation even if they are more recent than the files on tape.
Use restore to recover files and file systems made with the dump program. There are two ways to use restore:
interactively
non-interactively
Use the interactive option to recover moderate numbers of files from a dump archive. With the interactive feature of restore, you can browse the contents of a tape to locate and extract specific files.
Use the non-interactive mode to recover an entire backup. For example, place the backup in the drive and enter:
restore -x
Note that you cannot restore an active root file system. If your root file system is damaged and needs to be completely restored, you should probably reinstall the system, then rebuild it by extracting selected files from backup tapes.
The most common type of restoration you can perform is replacing single files that have been removed due to human error.
To restore an individual file, type:
bru -x filename
If the file already exists on the file system, bru compares its modification date with that of the copy on tape. If the version of the file in the file system is more recent than the one on tape, bru does not extract the archived file.
To overwrite a file no matter what the modification dates are, use the -u option. With -u, you must specify what kinds of files to overwrite:
b for block special files
c for character special files
d for directories
l for symbolic links
p for fifos (named pipes)
r for regular files
For example, to force updating of any regular files on the archive, enter:
bru -xur
To recover individual files from a tar archive, specify the name of the files on the command line:
tar xv file1 file2 directory/file3
The cpio command works much the same way; for example, enter:
cpio -id file1 directory/file2 < /dev/tape
The -i option causes cpio to read input from the tape drive, and the -d option causes it to create the directory it is extracting, if it doesn't already exist.
To recover individual files from a dump archive, follow these steps:
Place the tape in the tape drive. Make sure it is write protected.
Enter:
restore vi
You see something like this:
Verify tape and initialize maps Tape block size is 32 Dump date: Wed Feb 13 10:18:59 1991 Dumped from: the epoch Level 0 dump of an unlisted file system on ralph:/dev/rusr Label: none Extract directories from tape Initialize symbol table. restore >>
You are now at the restore> prompt. You can browse the tape with cd and ls:
restore > ls
You see something like this:
2 *./ 973 source 1502 net/ 2 *../ 149 d2/ 1445 os/ 10 .cshrc 155016 debug/ 1437 proto3.5/ 1463 .gamma 69899 dev/ 1494 revE 1464 .gamtables 696 etc/ 2122 stand/ 160 .kshrc 137 bin/ 3 tmp/ 1540 .lastlogin 1311412 jake/ 128 unix 819 .login 424 lib/ 128 unix.debug 820 .profile 9 lost+found/ 4 usr/
To continue browsing, enter the following commands to the restore prompt:
restore > cd etc restore > pwd /etc
Start building a list of files that you want to extract. Use the add command to add the names of the files you want to the extract list:
restore > add fstab restore > add fsck
If you enter ls at this point, you see a list of files, and fsck and fstab are marked with an asterisk to show they will be extracted.
If you want to remove a file from the list of those to be extracted, use the delete command:
restore > delete fstab
To restore the specified files, use the extract command:
restore > extract Extract requested files You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 Mount tape volume 1 then enter tape name (default: /dev/tape) <Return> extract file ./etc/fsck Add links Set directory mode, owner, and times. set owner/mode for '.'? [yn] n restore > q
To recover only a few files, you may wish to use the non-interactive options of restore. For example, enter:
restore -x ./usr/people/ralph/bus.schedule ./etc/passwd
This recovers the files bus.schedule and passwd from the archive.
From time to time you may experience a system crash due to file corruption. Systems cease operating (''crash'') for a variety of reasons. Most common are software crashes, followed by power failures of some sort, and least common are actual hardware failures. Regardless of the type of system crash, if your system files are lost or corrupted, you may need to recover your system from backups to its pre-crash configuration.
Regardless of the nature of your crash, once you repair or replace any damaged hardware and you are ready to recover the system, see "Restoring a File System From the System Maintenance Menu".
The System Maintenance Menu recovery command is designed for use as a full backup system recovery. After you have done a full restore from your last complete backup, you may restore newer files from incremental backups at your convenience. This command is designed to be used with archives made using the Backup(1) utility or through the System Manager. The System Manager is described in detail in the Personal System Administration Guide. System Recovery from the System Maintenance Menu is not intended for use with the tar(1), cpio(1), dd(1), or dump(1) utilities. You can use these other utilities after you have recovered your system.
Caution: This section does not contain step-by-step instructions. The information in this article provides suggestions or tips designed for the advanced system administrator.
For more information on system recovery, see the reference pages for savecore(1M) and crpt(1).
If your system crashes, it will attempt to save the contents of physical memory to aid in debugging the problem. The savecore command will recover the information needed to troubleshoot the problem in the directory /usr/adm/crash. crpt will automatically do some basic debugging and generate a report about the crash.
Sometimes, a system error causes the kernel to panic and savecore is called to save a copy of the contents of system memory. An error message similar to the following is displayed:
savecore: reboot after panic:
The contents of system memory is called core dump, and savecore writes the files to /usr/adm/crash, and writes a reboot message in the shutdown log. These files are large and can be removed after analysis. Panics can be caused by software bugs or hardware failures.
To determine the cause of a panic or crash requires some investigative work. These suggestions may help to isolate what caused the crash:
Check /usr/adm/SYSLOG for other error messages.
Save files in /usr/adm/crash to tape before deleting them.
Contact your support provider.
Running diagnostics and getting a backtrace of the crash can help to isolate the problem.
Make sure that versions of the operating system are consistent, particularly
if you recently upgraded system software.
Remove any third party hardware.
Run system diagnostics.
Try to isolate what software was running on the machine when it crashed.
Examine the core files using crpt (available on some machines).
Contact your support provider.
For more information on this error, see the reference pages for crpt, dbx(1), and savecore(1M).
At some point in the life of your workstation, you may choose to add a new storage media device. If you wish to change the default backup device to use your new hardware, the following instructions provide complete information. You can also use the graphical System Manager; it is the preferred tool for this operation and is described completely in the Personal System Administration Guide. Note, however, that no matter which method you use to select your preferred device, installing new system software or using the MAKEDEV(1M) command may reset the default Backup device. For more information on adding a storage media device, see "Tape Devices".
The method of changing the system default tape device is to relink /dev/nrtape to the desired device.
Jot down in the system log book the name of the current tape device to which /dev/nrtape is linked. To identify the device, examine the major and minor device numbers of /dev/nrtape and the device nodes in /dev/mt. Next, remove the link /dev/nrtape and create a new link to the new device. In this case, the new device will be mt/tps0d4. Use the following procedure:
Enter the commands:
cd /dev ls -l nrtape
You see something similar to this:
crw-rw-rw- 3 root sys 144, 65 Mar 15 16:10 nrtape
The major and minor device numbers are 144 and 65, respectively.
Examine the device numbers of all tape devices by entering the command:
ls -l mt
You see something similar to this:
total 0 crw-rw-rw- 2 root sys 144, 32 Mar 23 1993 tps0d4 crw-rw-rw- 2 root sys 144, 33 Mar 23 1993 tps0d4nr crw-rw-rw- 2 root sys 144, 35 Mar 23 1993 tps0d4nrns crw-rw-rw- 2 root sys 144, 34 Mar 23 1993 tps0d4nrs crw-rw-rw- 3 root sys 144, 64 Mar 23 1993 tps0d2 crw-rw-rw- 3 root sys 144, 65 Mar 23 1993 tps0d2nr
The device at the bottom of this listing has the matching major and
minor device numbers and therefore must be the device you're looking for.
If more than one device has the correct major and minor numbers, then either
device will do.
Remove the /dev/nrtape link and create the new link with the same name. Use the commands:
rm /dev/nrtape ln mt/tps0d4 /dev/nrtape
Most programs use /dev/nrtape as the default tape device. If a program does not seem to be working correctly, first ensure that it is using the correct tape device.
From time to time you may need to recover your system from a particularly bad failure, such as a hard disk failure. For most circumstances, you should need to use only your existing distribution media to boot your system for recovery purposes. However, if you have made a complete backup of your system, including any system files that may have changed in the course of your system tuning and development, it is a simple matter to restore your system.
As part of your IRIX software distribution, you received media (tape or CD) containing the ''miniroot.'' This media is specially formatted to allow you to boot the miniroot operating system to allow installation of the IRIX software.
If you do not have constant access to the distribution media, you can make a bootable tape. This process requires access to the distribution from the media at least once, or access to a distribution directory. The bootable software on the distribution is saved in a special format that cannot be archived like normal files and directories.
You may wish to make a copy of your entire distribution media to save wear on your original distribution. (This is more of a concern for tape media than for CD-ROM.)
If your distribution media is a compact disc, you must have a CD-ROM device and a tape drive. If your distribution media is a tape, you must have either two tape drives, or a tape drive and significant free disk space on your system. However, if the distribution software already exists in a distribution directory on your workstation or another workstation, you can copy it directly to your new media.
When you are ready to create the new bootable media, you will need your distribution media and your new tape. To effect a tape-to-tape transfer with one tape drive, perform the following steps:
Use the command:
/bin/su
To become the superuser on your system, you need to know the root password
for the workstation. If the distribution software is present on a remote
system, you should also be logged in to that system as the superuser.
Use the distcp(1M) command to copy the bootable image from the original distribution media to your disk or new media. The following example command copies the distribution from the original tape media to a distribution directory on your system:
distcp /dev/nrtape /usr/tmp/dist
Remove the original media from the tape drive and insert your new tape. Use the distcp command to copy the distribution to the tape:
distcp /usr/tmp/dist/* /dev/tape
Your bootable tape should now be ready.
If your system has two tape drives, the distcp command to use is:
distcp /dev/nrtape1 /dev/tape2
If your distribution media is on compact disc, mount the CD-ROM file system on your system, and use distcp to copy the distribution software to your tape drive. The following command performs the copy:
distcp /CDROM/dist/* /dev/nrtape
If the distribution already exists in a directory on your system or a network host, the distcp command is similar to that for a compact disc, except that the directory where the CD file system is mounted should be replaced with the name of the host system and the distribution directory on the host system. The following example command illustrates this:
distcp hostname:/dist/* /dev/tape
For complete information on the use of the distcp and mkboottape commands, see the distcp(1M) and mkboottape(1M) reference pages.
It is likely that a current software distribution will be too large to fit on an average 1/4 inch cartridge tape. It is often valuable (especially for system recovery) to have a tape that includes only the stand-alone shell (SASH). Using this tape, you can boot your system from the System Recovery option of the System Maintenance Menu and restore your system from full system backups made with the Backup(1M) command or the System Manager. See "Restoring a File System From the System Maintenance Menu" for more information.
To make a miniroot (SASH) tape, follow the instructions for copying the distribution but instead of giving the asterisk to indicate all files in the distribution, specify the sa file alone. For example, from a CD-ROM distribution, give the following command:
distcp hostname:/CDROM/dist/sa /dev/tape
You should develop a regimen for backing up the system or systems at your site and follow it closely. That way, you can accurately assess which data you can and cannot recover in the event of a mishap.
Exactly how you perform backups depends upon your workstation configuration and other factors. Regardless of the strategy you choose, though, you should always keep at least two full sets of reasonably current backups. You should also encourage users to make their own backups, particularly of critical, rapidly-changing files. Users' needs can change overnight, and they know best the value of their data.
Workstation users can back up important files using the System Manager, found in the ``System'' tile on your screen. The System Manager is described in detail in the Personal System Administration Guide. Make sure users have access to an adequate supply of media (for example, cartridge tapes), whether new or used.
If your media can handle your largest file system with a single volume, you don't have to use an incremental backup scheme, though such a system reduces the amount of time you spend making backups. However, if you must regularly use multiple volumes to back up your file systems, then an incremental backup system will reduce the number of tapes you use.
The following sections discuss the different aspects of backing up data.
How often you back up your data depends upon how busy a system is and how critical the data is. A simple rule of thumb is to back up any data on the system that is irreplaceable or that someone would not want to reenter.
On most systems, the root file system is fairly static. You do not need to back it up as frequently as the /usr file system.
Changes may occur when you add software, reconfigure hardware , change the site-networking (and the system is a server or network information service [NIS] master workstation), or change some aspect of the workstation configuration. In some cases, you can maintain backups only of the individual files that change, for example, /unix, /etc/passwd, and so forth.
This process of backing up single files is not always simple. Even a minor system change such as adding a user affects files all over the system, and if you use the graphical System Manager, you may tend to forget all the files that may have changed. Also, if you are not the only administrator at the site, you may not be aware of changes made by your coworkers. Using complete file system backup utilities, such as the System Manager or bru, on a regular schedule avoids these problems.
A reasonable approach would be to back up the root partition once a month. In addition to regular backups, here are some specific times to back up a root file system:
whenever you add users to the system, especially if the workstation
is an NIS master workstation
just before installing new software
after installing new software and when you are certain the software is working properly
If your system is very active, or if you are not the only administrator, you should back up the root file system regularly.
The /usr file system, which often contains both system programs (such as in /usr/bin) and user accounts, is usually more active than a root file system. Therefore, you should back it up more frequently.
At a typical multiuser installation, backing up once per day, using an incremental scheme, should be sufficient.
Incremental backups can use fewer tapes to provide the same level of protection as repeatedly backing up the entire file system. They are also faster than backing up every file on the system.
An incremental scheme for a particular file system looks something like this:
On the first day, back up the entire file system. This is a monthly
backup.
On the second through seventh days, back up only the files that changed
from the previous day. These are daily backups.
On the eighth day, back up all the files that changed the previous week.
This is a weekly backup.
Repeat steps 2 through 3 for four weeks (about one month).
After four weeks (about a month), start over, repeating steps 1
through 4.
You can recycle daily tapes every month, or whenever you feel safe about doing so. You can keep the weekly tapes for a few months. You should keep the monthly tapes for about one year before recycling them.
You can use the incremental option bru to create incremental backups. For example:
Create a complete backup of the /usr file system:
bru -c
Each day, back up the files that have changed since the previous daily backup:
bru -c -n 25-Nov-1992 /usr bru -c -n 26-Nov-1992 /usr bru -c -n 27-Nov-1992 /usr bru -c -n 28-Nov-1992 /usr bru -c -n 29-Nov-1992 /usr bru -c -n 30-Nov-1992 /usr bru -c -n 1-Dec-1992 /usr
Every week, back up the files that have changed since the last weekly backup:
bru -c -n 25-Nov-1992 /usr
Note that the dates listed in the command examples above are place holders.
Use appropriate current dates in your command lines.
At the end of four weeks, perform a complete backup and start the process over.
This is a common incremental backup scheme.
Although tar and cpio do not have built-in mechanisms for incremental backups, you can use other system commands to accomplish this task.
The following example uses the same incremental scheme as presented in the preceding section to back up the /usr file system. It uses the find command to determine which files to archive:
Go to the top of the file system that you want to back up. For example:
cd /usr
Create a complete backup of the file system. With tar:
tar cv .
With cpio:
cpio -oLp .
Each day, back up the files that have changed since the previous daily backup. With tar:
find /usr -mtime 1 -print | tar cvf -
With cpio:
find /usr -mtime 1 -print | cpio -pdL
Every week, back up the files that have changed since the last weekly backup. With tar:
find /usr -mtime 7 -type f -print | tar cvf -
With cpio:
find /usr -mtime 7 -type f -print | cpio -pdL
At the end of four weeks, perform a complete backup and start the process over.
The dump utility is designed for incremental backups, and it archives not only regular files and directories, but also special files, links, and pipes.
To create an incremental backup, specify an increment number when you use dump. The dump program archives all files that have changed since the last appropriate increment and special files such as links and named pipes. To recover files from an archive, use the restore command.
The dump program is designed specifically to create incremental backups. It refers to the increments as levels, and each level is assigned a number:
A level 0 backup archives all files in a file system.
Backup levels 19 archive all files that have changed since the previous backup of the same or lesser level.
For example, this command backs up all files on the /usr file system:
dump 0 /dev/usr
This command backs up those files that have changed since the previous level 0 dump:
dump 1 /dev/usr
This command archives those files that have changed since the previous level 1 dump:
dump 2 /dev/usr
If the next dump command you give specifies level 1, dump backs up the files that have changed since the last level 0, but not those that have changed since the last level 2.
This numbering system gives you enormous flexibility so you can create a backup schedule to fit your specific needs.
If you are managing a site with many networked workstations, you may wish to save backups on a device located on a central workstation.
To back up across a network, use the same basic backup commands, but with a slight change. Enter:
systemname:/dev/tape
If required, specify an account on the remote device:
user@systemname:/dev/tape
Users can use a central tape drive from their workstations with this method. Note that if you are backing up to a remote tape drive on a workstation that is not made by Silicon Graphics, the device name /dev/tape may not be the correct name for the tape drive. Always learn the pathname of the tape device before executing the backup commands.
For example:
tar cvf guest@alice:/dev/tape ./bus.schedule
or
cpio -ovcO guest@alice:/dev/tape ./bus.schedule
You can use the cron utility to automatically back up file systems at predetermined times. The backup media must be already mounted in the drive, and, if you want this to be truly automatic, it should have enough capacity to store all the data being backed up on a single volume. If all the data won't fit on a single volume, then someone must manually change volumes.
Here is an example cron command to back up the /usr/src hierarchy to /dev/tape (tape drive) every morning at 03:00 using bru:
0 3 * * * bru -c -f /dev/tape /usr/src
Place this line in a crontabs file, such as /var/spool/cron/crontabs/root.
This sort of command is useful as a safety net, but you should not rely on automatic backups. There is no substitute for having a person monitor backup process from start to finish and properly archive and label the media when the backup is finished. For more information on using cron to perform jobs automatically, see "Automating Tasks with at(1), batch(1), and cron(1M)".
Store your backup tapes carefully. Even if you create backups on more durable media, such as optical disks, take care not to abuse them.
Do not subject backups to extremes of temperature and humidity, and keep tapes away from strong electromagnetic fields. If there are a large number of workstations at your site, you may wish to devote a special room to storing backups.
Store magnetic tapes, including 1/4 in. and 8 mm cartridges, upright. Do not store tapes on their sides, as this can deform the tape material and cause the tapes to read incorrectly.
Make sure the media is clearly labeled and, if applicable, write-protected. Choose a label-color scheme to identify such aspects of the backup as what system it is from, what level of backup (complete versus partial), what file system, and so forth.
To minimize the impact of a disaster at your site, such as a fire, you may want to store main copies of backups in a different building from the actual workstations. You will have to balance this practice, though, with the need to have backups handy for recovering files.
If backups contain sensitive data, take the appropriate security precautions, such as placing them in a locked, secure room. Anyone can read a backup tape on a system that has the appropriate utilities.
You can keep backups as long as you think you need to. In practice, few sites keep system backup tapes longer than about a year before recycling the tape for new backups. Usually, data for specific purposes and projects is backed up at specific project milestones (for example, when a project is started or finished). As site administrator, you should consult with your users to determine how long to keep file system backups.
With magnetic tapes, however, there are certain physical limitations. Tape gradually loses its flux (magnetism) over time. After about two years, tape can start to lose data.
For long-term storage, you should re-copy magnetic tapes every year to year-and-a-half to prevent data loss through deterioration. When possible, use checksum programs, such as the sum(1) utility, to make sure data hasn't deteriorated or altered in the copying process. If you want to reliably store data for several years, consider using optical disk.
You can reuse tapes, but with wear, the quality of a tape degrades. The more important the data, the more precautions you should take, including using new tapes.
If a tape goes bad, mark it as ``bad'' and discard it. You should write ``bad'' on the tape case before you throw it out so that someone doesn't accidentally try to use it. You should never try to reuse an obviously bad tape. The cost of a new tape is minimal compared to the value of the data you are storing on it.
From time to time you will experience backup failures. It is vitally important that you determine the cause of the failure. Most often, the failure will be due to worn or faulty media. Proceeding without determining the cause of a failure makes all your future backups suspect and defeats the purpose of backups.
The reasons a backup tape might be unreadable include:
the data on the backup tape is corrupted due to age or media fault
the tape head is misaligned now, or was when the backup was made
the tape head is dirty now, or was when the backup was made
A wrong density tape drive.
The wrong program is being used to restore the tape to disk.
If you suspect the problem is that the tape drive is the wrong density, enter the command:
mt stat The command will return information about the tape drive, including the drive type.
Use the following table to determine which tapes that can be read given a particular tape drive.
Tape Drive | Tapes That Can Be Read |
---|---|
QIC150 | QIC150, QIC24, QIC 1000 |
QIC24 | QIC24 |
QIC02 | QIC02 |
If the problem is the wrong program being used to restore the tape to disk, it is most likely that the tape is mislabeled as to the command used to create the archive, or you are attempting to restore a System Manager backup onto a running system. To install a system backup tape, you must shut down the system first. A backup made with the System Manager tool can only be restored by following the directions in "Restoring a File System From the System Maintenance Menu".
The following is a table of commands and tools for making a tape backup and the corresponding command and tool to restore the backup tape:
You may not be able to read data created on another vendor's workstation, even if it was made using a standard utility, such as tar or cpio. One problem may be that the tape format is incompatible. Make sure the tape drive where the media originated is compatible with your drive.
If you are unable to verify that the drives are completely compatible, use dd to see if you can read the tape at the lowest possible level. Place the tape in the drive and enter the command:
mt blksize output
The mt(1M) command with these options will tell you the blocksize used to write the tape. Set the blocksize correspondingly (or larger) when you use dd to read the tape. For example, if the blocksize used was 1024 bytes, use the command:
dd if=/dev/tape of=/usr/tmp/outfile bs=1024
If dd can read the tape, it displays a count of the number of records it read in and wrote out. If dd cannot read the tape, make sure your drive is clean and in good working order. Test the drive with a tape you made on your system.
If you can read the tape with dd, and the tape was created using a standard utility, such as tar or cpio, you may be able to convert the data format with dd. Several conversions may help:
swabswap every pair of bytes
syncpad every input block to ibs
blockconvert ASCII to blocked ASCII
unblockconvert blocked ASCII to ASCII
noerrordo not stop processing on an error
The dd program can convert some completely different formats:
asciiconvert EBCDIC to ASCII
ebcdicconvert ASCII to EBCDIC
ibmslightly different map of ASCII to EBCDIC
Converting case of letters:
lcasemap alphabetics to lower case
ucasemap alphabetics to upper case
If the data was written on another vendor's system, you may be able
to convert it using dd, then pipe the converted output to another
utility to
read it.
Many other vendors use byte-ordering that is the reverse of the order used by IRIX. If this is the case, you can swap them with the following command:
dd if=/dev/tape conv=swab of=/usr/tmp.O/tapefile
Then use the appropriate archiving utility to extract the information from /tmp/tapefile (or whatever filename you choose). For example, use this command to extract information if the tar utility was used to make the tape on a byte-swapped system:
tar xvf /usr/tmp.O/tapefile .
Or you can use the no-swap tape device to read your files with the following tar command line:
tar xvf /dev/rmt/tps0d4ns
Of course, if your tape device is not configured on SCSI channel 4, the exact /dev/rmt device name may be slightly different. For example, it could be /dev/rmt/tps0d3ns.
It is good practice to preview the contents of a tar archive with the t keyword before extracting. If the tape contains a system file and was made with absolute pathnames, that system file on your system could be overwritten. For example, if the tape contains a kernel, /unix, and you extract it, your own system kernel will be destroyed. The following command previews our above example archive:
tar tvf /tmp/tarfile
If you wish to extract such a tape on your system without overwriting your current files, use this command to force the extraction to use relative pathnames:
tar Rx
or the corresponding bru command:
bru -j
If you see errors on the system console when trying to create a backup, some causes are:
The tape is not locked in the drive. You may see an error message similar to this:
/dev/nrtape rewind 1 failed:Resource temporarily unavailable
Make sure the tape is locked in the drive properly. See your Owner's
Guide if you do not know how to lock the tape in the drive.
File permission problems. These are especially likely with file-oriented
backup programs; make sure you have permission to access all the files
in the hierarchy you are backing up.
The drive requires cleaning and maintenance.
Bad media; see "Testing for Bad Media".
If you encounter problems creating backups, fixing the problem should be your top priority.
If you accidentally restore the wrong backup, you should rebuild the system from backups. Unless you are very sure of what you are doing, you should not simply restore the correct backup version over the incorrect version. This is because the incorrect backup may have altered files that the correct backup won't restore.
In the worst possible case, you may have to reinstall the system, then apply backups to bring it to the desired state.
Here are some basic steps to recovering a file system. If you used incremental backups, such as from backup or bru:
Make a complete backup of the current state of the file system. If you
successfully recover the file system, you will not need this particular
backup. But if there is a problem, you may need to return to the current,
though undesirable, state.
Start with the first complete backup of the file system that was made
prior to the backup that you want to have when you're finished. Restore
this complete backup.
Apply the series of incremental backups until you reach the desired (correct) backup.
If you accidentally restored the wrong file-oriented backup (such as a tar or cpio archive):
Make a complete backup of the affected file system or directory hierarchy.
You may need this not only as protection against an unforeseen problem,
but to fill any gaps in your backups.
Bring the system to the condition it was in just before you applied the wrong backup.
If you use an incremental backup scheme, follow steps 2 and 3 above (recovering from the wrong incremental backup).
If you use only utilities such as tar and cpio for backups,
use what backups you have to get the system to the desired state.
Once the system is as close as possible to the correct state, restore the correct backup. You are finished. If the system is in the desired state, skip the remaining steps.
If you cannot bring the system to the state it was in just before you
applied the wrong backup, continue with the next series of steps.
If you cannot manage to bring the system to the correct state (where
it was just before you restored the wrong backup), get it as close as possible.
Make a backup of this interim state.
Compare the current interim state with the backup you made at the outset of this process (with the incorrect backup applied) and with the backup you wish to restore. Note which files changed, which were added and removed, and which files remain unchanged in the process of bringing the system to the desired state.
Using these notes, manually extract the correct versions of the files from the various tapes.
Even the best media can go bad over time. Symptoms are:
Data appears to load onto the tape correctly, but the backup fails verification tests. (This is a good reason to always verify backups immediately after you make them.)
Another tape is then able to back up the data successfully and pass
verification tests.
Data retrieved from the tape is corrupted, while the same data loaded
onto a different tape is retrieved without problems.
The backup media device driver (such as the SCSI tape driver) displays
errors on the system console when trying to access the tape.
You are unable to write information onto the tape.
If errors occur when you try to write information on a tape, make sure the tape is not simply write-protected. Be sure you are using the correct length and density tape for your drive.
Make sure that your drive is clean and that tape heads are aligned properly. It is especially important to check tape head alignment if a series of formerly good tapes suddenly appear to go bad.
Once you are satisfied that a tape is bad, mark it as a bad tape and discard it. Be sure to mark it ``bad'' to prevent someone else from accidentally using it.
|
Send feedback to Technical Publications.
Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information