OpenVMS VAXBACK04_061 VAX V6.1 BACKUP ECO Summary
Copyright (c) Digital Equipment Corporation 1994, 1995. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENT: BACKUP Utility
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXBACK04_061
ECO Kits Superseded by This ECO Kit: VAXBACK03_061
VAXBACK02_061
VAXBACK01_061
ECO Kit Approximate Size: 580 Blocks
Kit Applies To: OpenVMS VAX V6.1
System/Cluster Reboot Necessary: No
ECO KIT SUMMARY:
An ECO kit exists for BACKUP on OpenVMS VAX V6.1. This kit addresses
the following problems:
Problems addressed in the VAXBACK04_061 kit:
Documentation Added:
o VAXBACK04_061 contains the same fixes as VAXBACK03_061.
Documentation regarding new features and restrictions has been
added.
Added Features:
The following items are added by the VAXBACK03_061 BACKUP.EXE image:
o The /(NO)ALIAS qualifier has been added to allow users more
control over how alias (synonym) file entries are processed by
the OpenVMS Backup utility (BACKUP). The default is /ALIAS.
The /ALIAS qualifier maintains the previous BACKUP behavior of
treating alias file entries the same as primary file entries.
Therefore, a primary file may be processed multiple times by
BACKUP if one or more alias file entries reference the same
primary file entry.
If you specify /NOALIAS, alias directory and file entries are
ignored. Therefore, multiple processing of primary files may be
avoided, which saves time and saveset file space. If a restore
operation is performed using the /ALIAS qualifier but the saveset
was created by using the /NOALIAS qualifier, a message is
displayed that the /ALIAS qualifier will be ignored.
o New messages associated with this fix are:
AECREATED: created alias file entry 'dev:[directory]entry.ALIAS'
Indicates that the specified alias file entry was created
during a backup restore operation. Requires no user action.
ALIASQUAL: SAVESET WAS CREATED /NOALIAS, RESTORE /ALIAS qualifier
will be ignored.
Indicates that the backup restore operation could not be
performed as specified because the saveset was created
ignoring alias entries. Therefore, there are no separate
files in the saveset to restore in place of the alias
directory entries. The restore operation was performed by
processing the alias file entries as directory entries
instead of as separate file entries.
The user should examine the saveset used in the backup
restore operation to determine if it is the correct save
set. If not, restore the correct image and incremental save
sets in the recommended order. If the save set is the
correct one, no additional action is required.
ARESTERR: error restoring alias file entry
'dev:[directory]entry.alias', the primary file entry
was 'dev:[prim_dir]primary.file'
Indicates that an error occurred when the Backup utility tried
to restore an alias file entry. The alias file entry was not
restored. Note that in most cases the alias file is eliminated
from the directory.
User should examine the primary file, the directory, and the
alias entry directory to determine the cause of the error.
Then, based on the data in this error message and any secondary
error status, correct the problem and create the alias file
entry using the DCL command SET FILE/ENTER.
As a general practice, Digital recommends that you execute the
DCL command ANALYZE/DISK after Backup restore operations of all
save sets have been completed and any subsequent error
corrections have been made, for example, using SET FILE/ENTER
commands.
Problems And Restrictions:
o The first time you back up a disk, you must perform an image backup
using the BACKUP/IMAGE/RECORD command before you perform regular
incremental backups. The image backup saves a copy of the entire
disk and marks each file as being saved. Subsequent incremental
backups assume an image backup has been performed and therefore save
only new or modified files.
If an image backup was not performed first, the incremental backups
save more files than might be necessary to ensure that an
incremental restore will be successful.
o An incompatibility between the operating procedures of the PATHWORKS
for OpenVMS Macintosh server and OpenVMS incremental backup
operations can cause BACKUP to save entire disks or directory
structures, including subdirectories and files.
A recent change to fix other problems now causes Backup to detect
whether a directory file has been modified since the date indicated
by the Backup date field in the file header. If a directory file
has been modified, all subdirectories and files of that directory
are saved for possible later restore operations. Updating the
modification date of directory files is unusual for OpenVMS systems,
but it can happen, for example, if you rename a directory file from
one version to another.
By contrast, the PATHWORKS Macintosh server maintains the
modification date of directory files for Macintosh users; that is,
it updates the modification data for each directory change, file
creation and file deletion.
Thus, an incremental backup of a disk where PATHWORKS is used to
serve files to Macintosh users may result in saving the entire disk
or entire directories (including their subdirectories and files)
instead of just the user files that were created or modified since
the last incremental backup operation.
This incompatibility will be addressed in a future version of
OpenVMS.
For now, you can avoid the needless saving of files by performing a
dummy BACKUP/RECORD operation on all directory files immediately
before performing the incremental backup. The following example
illustrates this workaround:
$ BACKUP/RECORD/IGNORE= (INTERLOCK) -
_$ disk:[000000...]*.DIR;* -
_$ NLA0:DUMMY.BCK/SAVE/NOCRC/GROUP_SIZE=0
$
$ BACKUP/VERIFY/FAST/RECORD/IGNORE= (INTERLOCK) -
_$ /NOASSIST/COMMENT="Incremental backup of DISK:" -
_$ disk:[000000...]*.*;*/SINCE=BACKUP -
_$ tape:incr.bck/LABEL=incr/SAVE
In this example , the first BACKUP command performs the dummy backup
operation and the second performs the actual incremental backup.
The first command updates the Backup Date field for all the
directory files. Specifying the null output device [000000...]
causes no saveset file to actually be written. Since no file
information need be retained from this operation, the /NOCRC and
/GROUP_SIZE=0 qualifiers are specified to avoid CRC and XOR block
calculation.
o An ANALYZE/DISK operation performed immediately after a BACKUP/IMAGE
restore of a disk might result in a warning message similar to the
following:
%ANALDISK-W-ALLOCLR, blocks incorrectly marked allocated
LBN 97 to 105, RVN 1
This can be caused by attempting to perform a BACKUP/IMAGE restore
operation where alias file entries are restored as separate
(primary) file entries. (The primary file which uses the same file
header but allocates different data storage blocks, is also
restored.)
Note that there is no BACKUP error or loss of data.
This problem will be addressed in a future version of OpenVMS.
Problems addressed in the VAXBACK03_061 kit:
o BACKUP may not incrementally restore a disk to the same
directory and file structure that existed at the time of
the most recent incremental save operation. Some of the
directories and their files may not be deleted properly,
which results additional files. This may cause restore
errors due to insufficient space on the output disk
device because the additional files are not deleted.
This problem is corrected in OpenVMS VAX V6.2
o When a BACKUP/LIST ddcu:*.*/SAVE_SET operation is performed
on a tape that contains many save sets, the BACKUP utility may
eventually abort with one of the following errors:
- %BACKUP-F-ALLOCMEM, error allocating virtual memory
SYSTEM-F-EXQUOTA, exceeded quota
- %BACKUP-F-INSBUFSPACE, Insufficient virtual memory to
accommodate minimum buffer count
- %BACKUP-F-BUFFERSLOST, all buffers are lost
This problem is corrected in OpenVMS VAX V6.2
o A listing file produced during an image backup and a listing
file created from the saveset may not be the same. One may
show several files to be at the end of a tape and the other
may show those same files to be at the beginning of the next
tape. In reality, the files only exist only at the beginning
of the next tape.
This problem is corrected in OpenVMS VAX V6.2.
o If an existing file name version for a disk saveset is used
for a new disk saveset, BACKUP will overwrite the file. This
causes the destruction of the information in the file and
possibly the loss of data.
This problem is corrected in OpenVMS VAX V6.2
o If the /RECORD qualifier is used on a RESTORE operation, an
ACCVIO may occur due to improper checking of qualifiers.
This problem is corrected in OpenVMS VAX V6.2
o On a BACKUP file restore operation, a file gets an ACL with
the default ACE created even though there was not one before.
The [DIRECTORY] that the file was in had a default ACE. An
ACE with the DEFAULT option on a directory file causes this
ACE to be added to the restored file's ACL.
NOTE: This problem does not occur on BACKUP/image
save/restore operations.
This problem is corrected in OpenVMS VAX V6.2
o Behavior of OpenVMS V6.1 and OpenVMS V6.0 is different with an
input saveset that has errors. Essentially V6.1 prompts the
user for action where V6.0 did not. A problem introduced by
the change in behavior is that besides prompting for (QUIT OR
CONTINUE) on every count of 100, it also prompts on the first
error detected before any XOR recovery could be attempted on
the failing block.
This problem is corrected in OpenVMS VAX V6.2
o BACKUP will erroneously abort with a GENMINUS1 error on a
non-shadowed disk.
This problem is corrected in OpenVMS VAX V6.2
o If the /INCREMENTAL and the /SINCE qualifier are used on the
same BACKUP command line, unpredictable results occur.
This problem is corrected in OpenVMS VAX V6.2
o A power fail test on two tape storage devices, TA90E and TA78,
ended up with two different results. The TA78 recovered the
power fail test but the TA90E failed with:
%BACKUP-E-FATALERR, fatal error on $88$MUA3:[]TEST.BCK;
BACKUP/IMAGE/REW/VER/IGN=INTER SYS$SYSDEVICE:
$88$MUA3:TEST.BCK/SAVE
Power fail the tape storage unit during I/O.
This problem is corrected in OpenVMS VAX V6.2
o BACKUP does not continue on the tape that is mounted while
using the /EXACT_ORDER qualifier.
When the first BACKUP command completes on the tape_volume
label "W0" and that volume is only about half full, the second
command requests a tape with label "W0". BACKUP complains and
will not allow that label "W0" to be used. However, if the
tape is dismounted and BACKUP remounts the same tape_volume to
do the append operation or the the /EXACT_ORDER qualifier is
removed from the command line, the tape_volume is mounted
correctly.
This is illustrated by the following command file:
$ write sys$output " backup av ingtab1 "
$ backup/journal/fast -
/exclude=(pppp*.t*,*.m*,*.d*,*.sm*) -
ingtab1:[ingres.data.tds01]*.* -
tape:ingtab1.bck -
/norew -
/block=65024 -
/label=(N0,V0,W0,N1,V1,W1) -
/exact_order
$!
$ write sys$output " backup av ingtab2 "
$ backup/journal/fast -
/exclude=(pppp*.t*,*.m*,*.d*,*.sm*) -
ingtab2:[ingres.data.tds01]*.* -
tape:ingtab2.bck -
/norew -
/block=65024 -
/label=(W0,N1,V1,W1) -
/exact_order
$!
$ exit
This problem is corrected in OpenVMS V6.2
o A RESTORE operation completes successfully, but returns the
INVRECTYP message that may cause doubt about the integrity of
the data.
This problem is corrected in OpenVMS VAX V6.2
o If a tape volume switch is required during a BACKUP operation
and the Media Manager (MME) is running, the BACKUP operation
will fail with:
"BACKUP-F-NOTANSI - tape is not valid ANSI format".
This problem is corrected in OpenVMS VAX V6.2
o OpenVMS BACKUP cannot selectively process directory structures
exceeding 8 levels. Only the BACKUP/IMAGE save and restore
will work.
This problem is corrected in OpenVMS VAX V6.2
Problems addressed in the VAXBACK02_061 (Special Release 9) kit:
o BACKUP inadvertently queries the user when the first CRC error
occurs and before XOR recovery takes place. BACKUP should
prompt only on every 100th error logged internally. Responding
to the query with a CONTINUE usually allows the BACKUP operation
to proceed. However, it is possible the process could hang.
This problem will be fixed in a future version of OpenVMS VAX.
o The code to update the RMS journaling date was not terminating
the RMS journaling attribute descriptor correctly.
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP may terminate during a /VERIFY pass with the following
error messages when excessive read errors occur on a marginal
tape media:
%BACKUP-E-READERRS, excessive error rate reading TAPE:[000000].;
-SYSTEM-F-CTRLERR, fatal controller error
The same failure may occur during a restore from the bad
saveset. Thus, if /VERIFY is not used during the saves, the
user is unaware the tapes are bad until an attempt is made to
restore the data.
This problem will be fixed in a future version of OpenVMS VAX.
Problems addressed in the VAXBACK01_061 (Special Release 8) kit:
o When /VOLUME is used in the BACKUP command line and the input
volume is not part of a volume set, a possible ACCVIO may occur.
BACKUP will now test for this situation and issue an informational
message that the /VOLUME qualifier will be ignored.
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP does not allow the /RECORD or /DELETE qualifiers if the
input disk is writelocked. Previously, BACKUP started the save
operation and failed later during the recording or delete pass
because of the writelocked disk.
BACKUP will now check early whether or not a /RECORD or /DELETE can
be performed. If it can not be performed, BACKUP will inform the
user and exit immediately
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP does not deal with a corrupted directory. For example,
the following BACKUP 'system messages' may occur if a corrupted
directory is backed up and 'namecount' field is at fault:
%BACKUP-F-FREEMEM, error freeing virtual memory
-LIB-F-BADBLOSIZ, bad block size
or
%BACKUP-F-FREEMEM, error freeing virtual memory
-LIB-BADBLOADR , bad block address
After informing the user with the following message,
%BACKUP-E-BADDIR, directory device:[dir_filespec] has invalid
format
BACKUP will now skip the bad directory. BACKUP will then continue
with the next available directory.
This problem will be fixed in a future version of OpenVMS VAX.
o Systems that have the Media Management Extensions [MME] enabled and
active and that specify files successfully saved be post-processed
(either /RECORD or /DELETE) may receive a message indicating that
postprocessing did not occur for any saved files. Those files will
not in fact have been post-processed as requested. For example,
$ BACKUP/RECORD/LOG SYS$lOGIN:LOGIN.COM SYS$lOGIN:TEST.BCK/SAVE
%BACKUP-S-COPIED, copied DISK:[DIR]LOGIN.COM;3
%BACKUP-S-COPIED, copied DISK:[DIR]LOGIN.COM;2
%BACKUP-S-COPIED, copied DISK:[DIR]LOGIN.COM;1
%BACKUP-I-STARTRECORD, starting backup date recording pass
%BACKUP-W-NONEREC, no files processed on recording pass
This problem will be fixed in a future version of OpenVMS VAX.
INSTALLATION NOTES:
The system/cluster does not need to be rebooted after this kit is
installed.
DCLTABLES is modified with this kit to include the new BACKUP qualifiers.
To take advantage of the new syntax, without having to logout/login, a
process' copy of DCLTABLES can be updated by typing:
$ SET COMMAND/TABLE=SYS$LIBRARY:DCLTABLES
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxback04_061.README
vaxback04_061.CHKSUM
vaxback04_061.CVRLET_TXT
vaxback04_061.a-dcx_vaxexe
|
