skip book previous and next navigation links
go up to top of book: HP OpenVMS System Manager's Manual, Volume 1:... HP OpenVMS System Manager's Manual, Volume 1:...
go to beginning of chapter: Using BACKUP Using BACKUP
go to previous page: Ensuring Data Integrity Ensuring Data Integrity
go to next page: Security ConsiderationsSecurity Considerations
end of book navigation links

Troubleshooting  



This section describes some common BACKUP errors and how to recover from them.

BACKUP Fatal Error Options  

If, in the course of a backup operation, the Backup utility or standalone BACKUP encounters fatal hardware- or media-related errors or encounters more media errors than considered reasonable for data reliability, BACKUP generates the following informational message and prompt:

%BACKUP-I-SPECIFY, specify option (CONTINUE, RESTART, QUIT) 
BACKUP>

NoteIf BACKUP is running interactively and you used the command qualifier /NOASSIST, you can enter an option in response to the BACKUP> prompt. If BACKUP is executing as a batch job or you specified the command qualifier /ASSIST, the operator must use the DCL command REPLY to enter an option.

The option you choose depends on several factors, as explained in BACKUP Error Options and Results.

Table 9   BACKUP Error Options and Results
Option Restrictions Result
CONTINUE
May compromise data reliability. Use only if the position of the tape has not changed since the original error and if the error does not imply that data has already been lost.
If possible, BACKUP ignores the error and continues processing.
RESTART
Not valid if the output volume is the first volume in the backup operation.
BACKUP unloads the current tape from the drive and prompts for another volume. After you load another tape, BACKUP restarts the save operation from the point at which the original tape was mounted.
QUIT
None.
BACKUP terminates the operation and you can reenter the command.

The following example illustrates the sequence of events that occurs when BACKUP encounters an excessive rate of media errors on VOL3 and you choose the RESTART option:

  1. BACKUP indicates that the magnetic tape has an excessive number of media errors and displays the following error message and prompt:
    %BACKUP-F-WRITEERRS, excessive error rate writing VOL3
    %BACKUP-I-SPECIFY, specify option (CONTINUE, RESTART, QUIT) 
    BACKUP>
  2. Enter RESTART.
  3. BACKUP dismounts VOL3 and prompts for a new tape. Remove VOL3 from the drive and discard this tape.
  4. Place a new tape into the drive and enter YES in response to the prompt for a new tape.
  5. BACKUP restarts the save operation from the beginning of VOL3; no data is lost.

Tape Label Errors  

When you instruct BACKUP to use a tape that has a label other than the one you specified, BACKUP issues the following message:

 
%MOUNT-I-MOUNTED, DKA0 mounted on _SODAK$MUA0:
%BACKUP-W-MOUNTERR, volume 1 on _SODAK$MUA0 was not mounted because
its label does not match the one requested
%BACKUP-W-EXLABEER, volume label processing failed because3
 volume TAPE4 is out of order, Volume label TAPE1 was expected
 specify option (QUIT, NEW tape, OVERWRITE tape, USE loaded tape)
BACKUP>
Depending on the option you specify, you can quit the backup operation (QUIT), dismount the old tape and mount a new one (NEW), overwrite the data on the tape (OVERWRITE), or USE the loaded tape.

If you use blank tapes or tapes that you intend to overwrite, use the /IGNORE=LABEL_PROCESSING qualifier. This suppresses the previous BACKUP message, which normally occurs if BACKUP encounters a non-ANSI-labeled tape during a save operation.

VMS$COMMON.DIR File Restore Problems 

On an OpenVMS system disk, the file [SYSx]SYSCOMMON.DIR is an alias directory of the file [000000]VMS$COMMON.DIR. This means that both files point to the same file header. Prior to OpenVMS VAX Version 5.5-2 and OpenVMS Alpha Version 1.5, because it operated on files in alphabetic order, BACKUP did not properly restore the relationship between the VMS$COMMON.DIR file and the [SYSx]SYSCOMMON.DIR alias. Although this does not affect the system disk, it can produce errors with DCL lexical functions.

OpenVMS VAX Version 5.5-2 and OpenVMS Alpha Version 1.5 corrected this problem. However, if you restore image backups that were created with an older version of OpenVMS, the problem can recur.

You can check both the save set and the system disk to determine whether either of these has an incorrect relationship between the VMS$COMMON.DIR file and the [SYSx]SYSCOMMON.DIR alias.


NoteIf you delete any files listed under [SYSx]SYSCOMMON.DIR, you must restore the system disk from the save set, and verify that the relationship between the VMS$COMMON.DIR file and the [SYSx]SYSCOMMON.DIR alias is correct as described in "Checking the System Disk."

Checking the Save Set

To determine if a save set has an incorrect relationship between the VMS$COMMON.DIR file and the [SYSx]SYSCOMMON.DIR alias, enter a BACKUP/LIST command to display information about the files contained in the VMS$COMMON directory in the save set. For example, here is the relevant portion of the output of the BACKUP/LIST command:

.		
.		
.		
[000000]VOLSET.SYS;1          0      24-SEP-2002 19:31
[]000000.DIR;1                1      24-SEP-2002 19:31
[]SYSCOMMON.DIR;1             2      24-SEP-2002 19:31
[]SYSLIB.DIR;1               18      24-SEP-2002 19:31
[]SYSTEST.DIR;1               1      24-SEP-2002 19:31
[]SYSMAINT.DIR;1              1      24-SEP-2002 19:31
[]SYSMGR.DIR;1                6      24-SEP-2002 19:31
[]SYSHLP.DIR;1                6      24-SEP-2002 19:31
[]EXAMPLES.DIR;1              1      24-SEP-2002 19:31
[]SYSUPD.DIR;1                4      24-SEP-2002 19:31
[]SYSMSG.DIR;1                3      24-SEP-2002 19:31
.		
.		
.		
[]SECURITY_AUDIT.AUDIT        3       3-FEB-2003 15:23
[]SECURITY_AUDIT.AUDIT       11       3-FEB-2003 15:23
[]BACKUP.EXE;33             273       4-FEB-2003 09:37
[]STABACKUP.EXE;9           486       4-FEB-2003 09:38
If the display lists lost files in the VMS$COMMON directory, as indicated by an empty directory specification ([]), the system disk information in this save set is affected by this problem. Whenever you perform a system restore using this save set, you must subsequently perform the procedure described in "Correcting the Problem" to correct it.

If you have access to the system from which the save set was created, perform the procedure described in "Checking the System Disk" to determine whether that system still has the problem. If so, perform the procedure described in "Correcting the Problem."

Checking the System Disk

To check the relationship between the VMS$COMMON.DIR file and the [SYSx]SYSCOMMON.DIR alias on the system disk, enter a DIRECTORY/HEADER command. For example:

$ DUMP/HEAD/BLOCK=COUNT:0 dr301:[000000]VMS$COMMON.DIR;1

Dump of file $4$DKA301:[000000]VMS$COMMON.DIR;1 on 14-FEB-2002 09:59:14.02
 
File ID (15,1,0)  End of file block 3 / Allocated 9
             
                            File Header
 
Header area
    Identification area offset:          40
   . 
   .
   .
Identification area
    File name:                           VMS$COMMON.DIR;1
   .
   .
   .

If the name displayed in the File name: field is VMS$COMMON.DIR;1, as shown in the example, the relationship is correct, and you need take no further action.

However, if the name displayed in the File name: field is SYSCOMMON.DIR;1, the relationship is not correct, and you must perform the procedure described in "Correcting the Problem" to correct it.

Correcting the Problem

To restore VMS$COMMON to its proper state, enter the following commands:

$ SET FILE/ENTER=SYSCOMMON.DIR VMS$COMMON.DIR
$ SET FILE/REMOVE VMS$COMMON.DIR;
$ RENAME SYSCOMMON.DIR VMS$COMMON.DIR



go to previous page: Ensuring Data Integrity Ensuring Data Integrity
go to next page: Security ConsiderationsSecurity Considerations