=;The OpenVMS Frequently Asked Questions (FAQ)D

The OpenVMS Frequently Asked Questions (FAQ)



 r \ ^  
PreviousContentsIndex

l

5.42 Please help me with the OpenVMS BACKUP utility?

N

5.42.1 Why isn't BACKUP/SINCE=BACKUP working?



GIf you are seeing more files backed up than previously, you are seeing Ethe result of a change that was made to ensure BACKUP can perform an Gincrementation restoration of the files. In particular, if a directory Hfile modification date changes, all files underneath it are included in @the BACKUP, in order to permit incremental restoration should a directory file get renamed.`

5.42.1.1 Why has OpenVMS gone through the agony of this change?



DWhen a directory is renamed, the modified date is changed. When the Erestoration needs to restore the directory and its contents, and the Hrestoration should not result in the restoration of the older directory @name when a series of incremental BACKUPs are restored. Thus an Aincremental BACKUP operation needs to pick up all of the changes.

HConsider performing an incremental restoration, to test the procedures. EThis testing was how OpenVMS Engineering found out about the problem ?that was latent with the old BACKUP selection scheme---the old Hincremental BACKUP scheme would have missed restoring any files under a @renamed directory. Hence the change to the selection mechanisms Dmentioned in Section 5.42.1.T

5.42.1.2 Can you get the old BACKUP behaviour back?



AYes, please see the /NOINCREMENTAL qualifier available on recent FOpenVMS versions (and ECO kits). Use of this qualifier informs BACKUP Bthat you are aware of the limitations of the old BACKUP behaviour %around incremental disk restorations.T

5.42.2 What can I do to improve BACKUP performance?



EUse the documented commands in the manual for performing incremental EBACKUPs. Use the documented incremental procedures. Don't try to use 2incremental commands in a non-incremental context.

GAlso consider understanding and then using /NOALIAS, which will likely Gbe a bigger win than will anything to do with the incremental BACKUPs, Hparticularly on system disks and any other disks with directory aliases.

5See the OpenVMS documentation for additional details.

EIgnoring hardware performance and process quotas, the performance of DBACKUP during a disk saveset creation is typically limited by three factors:

    A
  1. Default extend size
    The default behavior can have poor H performance, as the extend operation can involve extensive additional F processing and I/O operations. Consider changing the default extend < value on the volume, or change the extend for the process:

     

    "
    $ set rms/extend=65000 
    
    
    @

  2. Output IO size
    The default IO size for writing an RMS H sequential file is 32 blocks, an increase from the value of 16 blocks J used on earlier versions. Setting this to the maximum of 127 can reduce , the number of IOs by almost a factor of 4:

     

    "
    $ set rms/block=127 
    
    
    I
    Note that the performance might be better on some controllers if 1 the block count is a multiple of 4 - e.g. 124H

  3. Synchronous writes to the saveset
    Starting with OpenVMS V7.3, H you can now persuade RMS to turn on write-behind for sequential files E opened unshared. (Please see the V7.3 release notes or more recent C documentation for details.) Enabling the write-behind operations F involves setting the dynamic system parameter RMS_SEQFILE_WBH to 1. 2 This parameter is dynamic, and it can be enabledGand disabled without a reboot, and changes in its setting can and will Edirectly effect the running system. In order to get the full benefit Ffrom write-behind operations, you also need to increase the RMS local Cbuffer count from the default of 2 to a larger number. Raising the Cvalue to 10 is probably a reasonable first estimate for this value.

     

    "
    $ run sys$system:sysman PARAMETERS USE ACTIVE !PARAMETERS SET RMS_SEQFILE_WBH 1 PARAMETERS WRITE ACTIVE EXIT +$ SET RMS/BUFFER=10/EXTEND=65000/BLOCK=127 9$ BACKUP source-specification ddcu:[dir]saveset.bck/SAVE 
    
    
    

K

5.42.3 Why is BACKUP not working as expected?



DFirst, please take the time to review the BACKUP documentation, and Cparticularly the BACKUP command examples. Then please download and Hinstall the most current BACKUP eco kit. Finally, please please set the Dprocess quotas per the System Management documentation. These steps #tend to resolve most problems seen.

DBACKUP has a very complex interface, and there are numerous command Hexamples and extensive user documentation available. For a simpler user ;interface for BACKUP, please see the documentation for the BACKUP$MANAGER tool.

2As for recent BACKUP changes, oddities, bugs, etc:



+When working with BACKUP, you will want to:



*When working with the BACKUP callable API:

K

5.42.4 How do I fix a corrupt BACKUP saveset?



DBACKUP savesets can be corrupted by FTP file transfers and by tools Gsuch as zip (particularly when the zip tool has not been asked to save Hand restore OpenVMS file attributes or when it does not support OpenVMS Dfile attributes; use the zip "-V" option), as well as via other means of corruptions.

FIf you have problems (eg: NOTSAVESET errors) with the BACKUP savesets after unzipping themEor after an FTP file transfer, you can try restoring the appropriate "saveset attributes using the tool:

 

"
$ BACKUP/LIST saveset.bck/SAVE Listing of save set(s)  @%BACKUP-F-NOTSAVESET, saveset.bck/SAVE is not a BACKUP save set B$ @SRH:[UTIL]RESET_BACKUP_SAVESET_FILE_ATTRIBUTES.COM saveset.bck $ BACKUP/LIST saveset.bck/SAVE Listing of save set(s)  Save set:          saveset.bck Written by:        username ... 




BThis tool is available on the OpenVMS Freeware (in the [000TOOLS] Adirectory). The Freeware is available at various sites---see the DFreeware location listings elsewhere in the FAQ---and other similar .tools are also available from various sources.

EIn various cases, a SET FILE/ATTRIBUTES command can also be used. As Cthe parameters of this command must be varied as the target BACKUP :saveset attributes vary, this approach is not recommended.

;Also see the "SITE VMS", /FDL, and various other Afile-attributes options available in various FTP tools. (Not all 9available FTP tools support any or all of these options.)

HBrowser downloads (via FTP) and incorrect (binary or ascii FTP transfer Gmodes) are notorious for causing RMS file corruptions and particularly ABACKUP saveset corruptions. You can sometimes help encourage the Cbrowser to select the correct FTP transfer type code (via RFC1738):



FYou can also often configure the particular web browser to choose the Cappropriate transfer mode by default, based on the particular file Gextensions, using a customization menu available in most web browsers. FYou can select that the specific file extentions involved use the FTP Gbinary transfer mode, which will reduce the number of corruptions seen.V

5.42.5 How do I write a BACKUP saveset to a remote tape?



AHow to do this correctly was described at DECUS long ago. On the DOpenVMS host with the tape drive, create the following SAVE-SET.FDL file:

 

"
RECORD &        FORMAT                  fixed %        SIZE                    8192 




Then create BACKUP_SERVER.COM:

 

"
$ ! @$ ! BACKUP_SERVER.COM - provide remote tape service for BACKUP. $ ! $ set noon $ set rms/network=16 $ allocate mka500 tapedev 3$ mount/nounload/over:id/block=8192/assist tapedev 1$ convert/fdl=SAVE-SET sys$net tapedev:save-set. $ dismount/unload tapedev $ stop/id=0 




AOn the node where you want to do the backup, use the DCL command:

 

"
$ backup -     srcfilespec - 9    node"user pwd"::"task=backup_server"/block=8192/save 




GOne area which does not function here is the volume switch; multi-reel Eor multi-cartridge savesets. Since the tape is being written through FDECnet and RMS and the magtape ACP, BACKUP won't see the media switch Hand will split an XOR group across the reel boundary. BACKUP might well @be willing to read such a multi-reel or multi-cartridge saveset G(directly, not over the net) as the XOR blocks are effectively ignored Euntil and unless needed for error recovery operations. BACKUP likely Awill not be able to perform an XOR-based recovery across reel or cartridge boundaries.

GUnfortunately BACKUP can't read tapes over the network because the RMS Dfile attributes on a network task access look wrong; the attributes )reported include variable length records.S

5.42.6 How to perform a DoD security disk erasure?



BSometimes refered to as disk, tape, or media declassification, as ?formatting, as pattern erasure, or occasionally by the generic Greference of data remanence. Various references to the US Deparment of /Defence (DoD) or NCSC "Rainbow Books". documentation are also seen in this context.

AWhile this erasure task might initially appear quite easy, basic Fcharacteristics of the storage media and of the device error recovery Gand bad block handling can make this effort far more difficult than it might initially appear.

AObviously, data security and sensitivity, the costs of exposure, ?applicable legal or administrative requirements (DoD, HIPPA or Aotherwise), and the intrinsic value of the data involved are all >central factors in this discussion and in the decision of the @appropriate resolution, as is the value of the storage hardware involved.

FWith data of greater value or with data exposure (sometimes far) more Acostly than the residual value of the disk storage involved, the Ephysical destruction of the platters may well be the most expedient, Geconomical, and appropriate approach. The unintended exposure of a bad Hblock containing customer healthcare data or of credit card numbers can Fquite be costly, of course, both in terms of the direct loss, and the 1longer-term and indirect costs of such exposures.

AOther potential options include the Freeware RZDISK package, the FOpenVMS INITIALIZE/ERASE command (and potentially in conjunction with the $erapat system service)Aand OpenVMS Ask The Wizard (ATW) topics including (841), (3926), F(4286), (4598), and (7320). For additional information on sys$erapat, @see the OpenVMS Programming Concepts manual and the OpenVMS VAX Gexamples module SYS$EXAMPLES:DOD_ERAPAT.MAR. Some disk controllers and Heven a few disks contain support for data erasure. Some DSSI Disk ISEs, for instance.

<For the prevention of casual disk data exposures, a generic ?INITIALIZE/ERASE operation is probably sufficient. This is not Hcompletely reliable, particularly if the data is valuable, or if legal, Eadministrative or contractual restrictions are stringent---there may Ewell be revectored blocks that are not overwritten or not completely Foverwritten by this erasure, as discussed above, and these blocks can Hobviously contain at least part of most any data that was stored on the Hdisk -- but this basic disk overwrite operation is likely sufficient to ,prevent the typical information disclosures.

?You will want to consult with your site security officer, your Fcorporate security or legal office, with HP Services or your prefered Dservice organization, or with a firm that specializes in erasure or Ddata declassification tasks. HP Services does traditionally offer a %secure disk declassification service.Q

5.42.7 How to enable telnet virtual terminals?



ATo enable virtual terminal support for telnet and rlogin devices,?add the following logical name definitions into SYLOGICALS.COM:

 

"
0$ DEFINE/SYSTEM/EXECUTIVE TCPIP$RLOGIN_VTA TRUE 0$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNET_VTA TRUE 




HSee SYS$STARTUP:SYLOGICALS.TEMPLATE for details on the typical contents of SYLOGICALS.COM.

HIn SYSTARTUP_VMS.COM, ensure that a command similar to the following is invoked:

 

"
O$ SYSMAN IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE 




FIn MODPARAMS.DAT, add the following line or (if already present) mask Cthe specified hexidecimal value into an existing TTY_DEFCHAR2, and 5perform a subsequent AUTOGEN with an eventual reboot:

 

"
TTY_DEFCHAR2 = %X20000 




This value is TT2$M_DISCONNECT.

EOn older TCP/IP Services---versions prior to V5.0---you will have to "perform the following UCX command:

 

"
$ UCX %UCX> SET CONF COMM/REMOTE=VIRTUAL 


N

5.42.7.1 Volume Shadowing MiniCopy vs MiniMerge?



AMiniMerge support has been available for many years with OpenVMS Fhost-based volume shadowing, so long as you had MSCP controllers (eg: GHSC, HSJ, or HSD) which supported the Volume Shadowing Assist known as ""Write History Logging".

EIf you are interested in mini-merge and similar technologies, please Bsee the Fibre Channel webpage and the information available there:



FMini-Merge support was originally intended to be controller-based and &was expected with HSG80 series storageBcontrollers and was expected to require ACS 8.7 and OpenVMS Alpha V7.3-1.

Host-based Mini-Merge (HBMM)His now available for specific OpenVMS releases via a shadowing ECO kit, Cand is also present in OpenVMS V8.2 and later. HBMM applies to the DHSG80 series and---like host-based volume shadowing---to most other '(all other?) supported storage devices.

GThe following sections describe both Mini-Copy and Mini-Merge, and can provide a basis for discussions.6

5.42.7.1.1 Mini-Copy?



@A Shadowing Full Copy occurs when you add a disk to an existing Eshadowset using a MOUNT command; the entire contents of the disk are Ceffectively copied to the new member (using an algorithm that goes Hthrough in 127-block increments and reads one member, compares with the Dtarget disk, and if the data differs, writes the data to the target Gdisk and loops back to the read step, until the data is equal for that D127-block section). (This is one of the reasons why the traditional Brecommendation for adding new volumes to a shadowset was to use a EBACKUP/PHYSICAL copy of an existing shadowset volume, simply because Fthe reads then usually matched and thus shadowing usually avoided the need for the writes.)

AIf you warn OpenVMS ahead of time (at dismount time) that you're Hplanning to remove a disk from a shadowset but re-add it later, OpenVMS Fwill keep a bitmap tracking what areas of the disk have been modified Fwhile the disk was out of the shadowset, and when you re-add it later Awith a MOUNT command OpenVMS only has to update the areas of the Freturned disk that the bit-map indicates are now out-of-date. OpenVMS Edoes this with a read source / write target algorithm, which is much Ffaster than the shenanigans the Full Copy does, so even if all of the 9disk has changed, a Mini-Copy is faster than a Full Copy.7

5.42.7.1.2 Mini-Merge?



CA Shadowing Merge is initiated when an OpenVMS node in the cluster <(which had a shadowset mounted) crashes or otherwise leaves Eunexpectedly, without dismounting the shadowset first. In this case, @OpenVMS must ensure that the data is identical, since Shadowing Hguarantees that the data on the disks in a shadowset will be identical. EIn a regular Merge operation, Shadowing uses an algorithm similar to Athe Full Copy algorithm (except that it can choose either of the Hmembers' contents as the source data, since both are considered equally Gvalid), and scans the entire disk. Also, to make things worse, for any Eread operations in the area ahead of what has been merged, Shadowing Hwill first merge the area containing the read data, then allow the read to occur.

EA Merge can be very time-consuming and very I/O intensive. If a node Hcrashes, the surviving nodes can query to determine what exact areas of Ethe disk the departed node was writing to just before the crash, and Gthus Shadowing only needs to merge just those few areas, so this tends Eto take seconds, as opposed to potentially requiring many minutes or $even hours for a regular full Merge.l

5.43 Please explain DELETE/ERASE and File Locks?



EDELETE/ERASE holds the file lock and also holds a lock on the parent Fdirectory for the duration of the erasure. This locking can obviously Ecause an access conflict on either the file or on the directory---it Cmight well pay to rename files into a temporary directory location Ebefore issuing the DELETE/ERASE, particularly for large files and/or Cfor systems with multiple overwrite erase patterns in use; for any Csystems where the DELETE/ERASE erasure operation will take a while.Z

5.44 Managing File Versions?



ESome applications will automatically roll file version numbers over, Aand some will require manual intervention. Some will continue to Doperate without the ability to update the version, and some will be Gunable to continue. Some sites will specifically (attempt to) create a Dfile with a version of ;32767 to prevent the creation of additional files, too.

ETo monitor and resolve file versions, you can use commands including:

 

"
$$ SET FILE/VERSION_LIMIT=n filename ,$ SET DIRECTORY/VERSION_LIMIT=n [directory] 




GAnd you can also monitor file version numbers, and can report problems Ewith ever-increasing file versions to the organization(s) supporting Athe application(s) generating files with ever-increasing version Gnumbers for details on potential problems, and for any recommendations Hon resetting the version numbers for the particular product or package. If required, of course.

HThe following pair of DCL commands---though obviously subject to timing Fwindows--- can be used to rename all the versions of a file back down 3to a contiguous sequence of versions starting at 1:

 

"
"$ RENAME file.typ;*   RENAME.TMP;  $ RENAME RENAME.TMP;* file.typ; 




GThe key to the success of this RENAME sequence is the specification of E(only) the trailing semicolon on the second parameter of each of the RENAME commands.

DYou may also see the numbers of files reduced with DELETE commands, Hwith multiple directories, or with PURGE commands such as the following examples:

 

"
$ PURGE/BEFORE="-2-" $ PURGE/BEFORE="TODAY-2-" $ PURGE/KEEP=10" 




You can use DFU (Freeware)E to quickly and efficiently scan for all files with large(r) version numbers:

 

"
 DFU SEARCH/VERSION=MINIMUM=nnnn 




FIf you are creating or supporting an application, selecting temporary @or log file filenames from among a set of filenames---selecting Afilenames based on time, on process id, on the day of week, week !number, or month, on the f$uniqueE lexical (V7.3-2 and later), etc---is often useful, as this approach F more easily permits on-line adjustments to the highest file versions G and easily permits on-line version compression using techniques shown C above. With differing filenames, you are less likely to encounter E errors resulting from files that are currently locked. You can also G detect the impending version number limit within the application, and H can clean up older versions and roll the next file version creation to ;1 or such.

9Also see Section 9.4.




 r Y \ ^  
PreviousNextContentsIndex