Volume Shadowing for OpenVMS
Testing alone cannot guarantee the correctness of a backup procedure.
However, testing is a critical component of designing any backup and
7.12.13 Restoring Data
Too often, organizations concentrate on the backup process with little
thought to how their data will be restored. Remember that the ultimate
goal of any backup strategy is to recover data in the event of a
disaster. Restore and recovery procedures must be designed and tested
as carefully as the backup procedures.
7.12.14 Revalidation of Data Consistency Methods
The discussion in this section is based on features and behavior of
OpenVMS Version 7.3 and applies to prior versions as well. Future
versions of OpenVMS may have additional features or different behavior
that affect the procedures necessary for data consistency. Sites that
upgrade to future versions of OpenVMS must reevaluate their procedures
and be prepared to make changes or to employ nonstandard settings in
OpenVMS to ensure that their backups remain consistent.
Performing System Management Tasks on Shadowed Systems
This chapter explains how to accomplish system maintenance tasks on a
standalone system or an OpenVMS Cluster system that uses volume
shadowing. Refer to Chapter 3 for information about setting up and
booting a system to use volume shadowing.
8.1 Upgrading the Operating System on a System Disk Shadow Set
It is important to upgrade the operating system at a time when your
system can afford to have its shadowing support disabled. This is
because you cannot upgrade to new versions of the OpenVMS
operating system on a shadowed system disk. If you attempt to upgrade a
system disk while it is an active member of a shadow set, the upgrade
procedure will fail.
Procedure for Upgrading Your Operating System
This procedure is divided into four parts. Part 1 describes how to
prepare a shadowed system disk for the upgrade. Part 2 describes how to
perform the upgrade. Part 3 describes how to enable volume shadowing on
the upgraded system. Part 4 shows how to boot other nodes in an OpenVMS
Cluster system with and without volume shadowing.
Part 1: Preparing a Shadowed System Disk
- On OpenVMS Cluster systems, choose the node on which you want to
perform the upgrade.
- Create a nonshadowed system disk to do the upgrade using either of
- Prepare a copy of the current system disk to use as the target of
the upgrade procedure. See Section 8.3.2.
- Use BACKUP to create a compressed copy of the shadow set on a
single scratch disk (a disk with no useful data). See in
Section 8.3.4 for an example.
- Enter the MOUNT/OVERRIDE=SHADOW_MEMBERSHIP command on the upgrade
disk to zero the shadowing-specific information on the storage control
block (SCB) of the disk. Do not mount the disk for systemwide or
clusterwide access; omit the /SYSTEM and /CLUSTER qualifiers on the
MOUNT command line.
- Use the DCL command SET VOLUME/LABEL=volume-label
device-spec[:] to change the label on the upgrade disk. (The SET
VOLUME/LABEL command requires write access [W] to the index file on the
volume. If you are not the volume owner, you must have either a system
UIC or the SYSPRV privilege.) For OpenVMS Cluster systems, ensure that
the volume label is a unique name across the cluster.
If you need to change the volume label of a disk that is mounted across
the cluster, be sure you change the label on all nodes in the OpenVMS
Cluster system. For example, you could propagate the volume label
change to all nodes in the cluster with one SYSMAN utility command,
after you define the environment as the cluster:
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO SET VOLUME/LABEL=new-label disk-device-name:
- Ensure that the boot command line or file boots from the upgrade
disk. The manner in which you store the boot command information
depends on the processor on which you are working. For more information
about storing boot commands, see the instructions in your hardware
installation guide, the upgrade and installation supplement for your
VAX computer, or the upgrade and installation manual for your Alpha
If volume shadowing is enabled on the node, disable it
according to the instructions in step 6. Otherwise, continue with Part
2 to upgrade the system.
- Prepare to perform the upgrade procedure by disabling system disk
shadowing (if it is enabled) on the node to be upgraded.
You cannot perform an upgrade on a shadowed system disk. If your system
is set up to boot from a shadow set, you must disable shadowing the
system disk before performing the upgrade. This requires changing
SYSGEN parameter values interactively using the SYSGEN utility.
Invoke SYSGEN by entering the following command:
On OpenVMS Alpha systems, enter the following:
SYSGEN> USE upgrade-disk:[SYSn.SYSEXE]ALPHAVMSSYS.PAR
On OpenVMS VAX systems, enter the following:
The USE command defines the system parameter file from which data is to
be retrieved. You should replace the variable upgrade-disk
with the name of the disk to be upgraded. For the variable n
in [SYSn.SYSEXE], use the system root directory you want to
boot from (this is generally the same root you booted from before you
started the upgrade procedure).
SYSGEN> USE upgrade-disk:[SYSn.SYSEXE]VAXVMSSYS.PAR
Disable shadowing of the system
disk by setting the SYSGEN parameter SHADOW_SYS_DISK to 0, as follows:
SYSGEN> SET SHADOW_SYS_DISK 0
On OpenVMS Alpha systems, enter:
SYSGEN> WRITE upgrade-disk:[SYSn.SYSEXE]ALPHAVMSSYS.PAR
On OpenVMS VAX systems, enter:
SYSGEN> WRITE upgrade-disk:[SYSn.SYSEXE]VAXVMSSYS.PAR
Type EXIT or press Ctrl/Z to exit the SYSGEN utility and return to
the DCL command level.
You must also change parameters in the
MODPARAMS.DAT file before shutting down the system. Changing
parameters before shutdown ensures that the new system parameter values
take effect when AUTOGEN reads the MODPARAMS.DAT file and reboots the
nodes. Edit upgrade-disk:[SYSn:SYSEXE]MODPARAMS.DAT
and set SHADOWING and SHADOW_SYS_DISK to 0.
Even if you plan to use the upgraded system disk to upgrade the
operating system on other OpenVMS Cluster nodes, you should complete
the upgrade on one node before altering parameters for other nodes.
Proceed to Part 2.
Part 2: Performing the Upgrade
- Boot from and perform the upgrade on the single, nonshadowed disk.
Follow the upgrade procedure described in the OpenVMS upgrade and
- If you are upgrading a system that already has the volume
shadowing software installed and licensed, then skip to Part 3.
Otherwise, you must register the Volume Shadowing for OpenVMS
Product Authorization Key (PAK) or keys. PAK registration is described
in the release notes and cover letter supplied with your installation
Part 3: Enabling Volume Shadowing on the Upgraded System
Once the upgrade is complete and the upgraded node has finished running
AUTOGEN, you can enable shadowing for the upgraded node using the
- Invoke the System Generation utility (SYSGEN) by entering the
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> USE CURRENT
The USE CURRENT command initializes the SYSGEN work area with the
source information from the current system parameter file on disk. (To
find out the current value of system parameters, use the SHOW command
[for example, SHOW SHADOWING] to see the current system parameter
values as well as the minimum, maximum, and default values of the
To enable shadowing, set the system parameter
SHADOWING to 2. If the system disk is to be a shadow set, set the
system parameter SHADOW_SYS_DISK to 1, and set the SHADOW_SYS_UNIT
parameter to the unit number of the virtual unit, as follows (assume
the system disk virtual unit is DSA54):
SYSGEN> SET SHADOWING 2
SYSGEN> SET SHADOW_SYS_DISK 1
SYSGEN> SET SHADOW_SYS_UNIT 54
SYSGEN> WRITE CURRENT
Type EXIT or press Ctrl/Z to exit the SYSGEN utility and return to
the DCL command level.
- To ensure that volume shadowing is enabled each time AUTOGEN
executes, edit the SYS$SYSTEM:MODPARAMS.DAT file to set the shadowing
parameters. For OpenVMS Cluster systems, set system parameters in
MODPARAMS.DAT on each node that uses volume shadowing. See
Chapter 3 for more information about editing the MODPARAMS.DAT file.
- Shut down the system on which you performed the upgrade, and
Part 4: Booting Other Nodes in the OpenVMS Cluster from the Upgraded Disk
If other nodes boot from the upgraded disk, the OpenVMS upgrade
procedure automatically upgrades and runs AUTOGEN on each node when it
is booted. The procedure for booting other nodes from the upgraded disk
differs based on whether the upgraded disk has been made a shadow set.
- If the upgraded disk is not yet a shadow set:
- Disable shadowing (if it is enabled) for the system disk on the
nodes to be upgraded.
- Alter the boot files for those nodes so they boot from the upgraded
- Make sure the system parameters in the node-specific
SYS$SYSTEM:MODPARAMS.DAT files are correct (as described in
Section 3.3.1). When the OpenVMS upgrade procedure invokes AUTOGEN, it
will use these parameter settings.
- Boot the nodes from the upgraded disk.
- If the upgraded disk is already a shadow set member, additional
steps are required:
- For each node to be booted from the upgraded disk, edit
VAXVMSSYS.PAR for VAX systems and ALPHAVMSSYS.PAR for Alpha systems,
and MODPARAMS.DAT to enable system disk shadowing. Set SHADOWING to 2,
SHADOW_SYS_DISK to 1, and SHADOW_SYS_UNIT to the number of the system
disk's virtual unit name. Remember to modify the files on the upgraded
disk, not on the system disk, prior to upgrade.
- Modify the computer console so that the system boots from the
On VAX computers, depending on which model you have,
you can alter the boot file on the console media or use a console
command to change nonvolatile RAM.
On Alpha computers, you can use
the SET BOOTDEF_DEV console command. For more information, see the
hardware information or the upgrade and installation manual for your
- Boot each node. With shadowing enabled in each node's
ALPHAVMSSYS.PAR or VAXVMSSYS.PAR on the upgraded disk, the node will be
able to boot from the shadowed (upgraded) system disk.
Once you have successfully upgraded the system or systems and you have
completed other postupgrade work (such as layered product
installations), perform the following steps:
- Mount additional shadow set members into the shadow set, if
necessary. Do not use a command procedure to add members to a system
disk shadow set. For more information, see Section 3.4.
- Back up your new system disk shadow set. If you usually use online
BACKUP for this task, you can use one of the procedures described in
Section 8.3. If you usually use standalone BACKUP at this point,
refer to Section 8.3.1.
8.2 Modifying Data on Individual Shadow Set Members
Generally, users and applications access a shadow set through the
virtual unit. Occasionally, you may want to change the data on an
individual shadow set member and then pass the changed data to other
shadow set members.
The following series of commands demonstrates how you can dissolve and
recreate the shadow set to perform specialized processes on one shadow
set member and transfer the change to the other shadow set members.
The following command mounts a shadow set with three shadow set members:
$ MOUNT DSA9:/SHADOW=($45$DUA2:,$45$DUA4:,$45$DUA8:) LURK1
The following command dissolves the shadow set mounted in the previous
command and makes the individual shadow set members available:
The following command mounts one former shadow set member as a disk
volume outside of the shadow set:
$ MOUNT/OVERRIDE=SHADOW_MEMBERSHIP $45$DUA2: LURK1
In this command, in order to have write access, you must use the
/OVERRIDE=SHADOW_MEMBERSHIP qualifier to zero the shadow set generation
number. At this point, the disk is mounted as a nonshadowed volume and
can be modified as required.
Before creating a new shadow set, dismount the $45$DUA2 physical disk,
$ DISMOUNT/NOUNLOAD $45$DUA2
$ MOUNT DSA9:/SHADOW=$45$DUA2: LURK1
The second command recreates the shadow set with $45$DUA2 as the only
Note that mounting $45$DUA2 with the /OVERRIDE=SHADOW_MEMBERSHIP
qualifier automatically zeroed the volume shadowing generation number.
If you were to specify all the former members of the shadow
set in the same command line, the MOUNT command would consider $45$DUA2
an unrelated volume and would determine that it requires a copy
operation. This would overwrite the earlier modifications.
To save the current contents of $45$DUA2, add the other two former
shadow set members to the new shadow set with a subsequent MOUNT
$ MOUNT DSA9:/SHADOW=($45$DUA4:,$45$DUA8:) LURK1
In this command, $45$DUA4 and $45$DUA8 are added to the shadow set
DSA9. This recreates the original shadow set, except that each shadow
set member now has the benefit of the changed data that was done to the
single shadow set member.
8.3 Performing Backup Operations on a Shadow Set
You should think of a shadow set as a single, highly available disk. As
such, backup techniques for nonshadowed disks apply to shadow set
virtual units. However, to preserve the consistency and integrity of
the shadow set, avoid removing a physical member of the shadow set
without dismounting the virtual unit unless you have scrupulously
followed the guidelines in Section 7.12. If you leave some disk
members of a shadow set active during the backup operation, data
integrity is compromised because some disks in the shadow set may have
files open. Refer to Section 4.8.3 for information about obtaining a
member of a shadow set for the source of a backup operation.
The following list describes options that are available when backing up
shadow sets that are not available with nonshadowed disks.
- To obtain a defragmented backup of a shadowed disk, begin by
closing files and stopping application access to the disks. Dismount
the virtual unit to dissolve the shadow set. Use the /NOUNLOAD
qualifier to avoid spinning down the members of the shadow set. Remount
the virtual unit as a private device, and use BACKUP/IMAGE (see
Section 8.3.4) with the virtual unit as the source of the backup
operation. This is the recommended method of backing up shadow sets.
- To minimize the amount of time that data is unavailable to
applications, consider remounting the shadow set with one less member
(see Section 4.8.3). Then back up the dismounted member. This technique
keeps the shadow set in service at the same time that you perform a
backup operation. Once the backup is complete, remount the member into
the shadow set. The shadowing software performs a copy, or minicopy,
operation to make that member consistent with the other members of the
If a spare disk of the type present in the shadow set
is available, consider mounting the spare disk into the shadow set to
minimize the time that the shadow set runs with reduced membership.
Then, the member that served as the source of the backup can become a
- To ensure complete integrity of the backup of the system disk, you
must shut down the systems that boot from it. For system disk shadow
sets, you should also dismount the virtual unit by any other systems
that have it mounted. Then remount the virtual unit as a private device
on one of the systems that was not shut down, and use it as the source
for a BACKUP/IMAGE operations (see Section 8.3.4).
In addition, to
provide system disk shadowing quickly as you perform a backup
operation, remount the shadow set minus one member. Back up that member
and either remount it into the shadow set or mount a spare disk. You
can use standalone BACKUP (VAX) or the menu-driven BACKUP procedure
(Alpha) on one of the systems that is down while the other systems are
- To do an incremental backup, use the virtual unit, not a single
member of the shadow set. This is because incremental backups alter
information in file headers. If you perform an incremental backup on a
removed member of a shadow set, that member needs to be the target of a
HSC BACKUP and RESTORE techniques are not recommended for saving and
restoring the contents of a shadow set member. These HSC utilities are
applicable to the disk geometry only, not to the OpenVMS file system.
Although HSC BACKUP and RESTORE techniques save and restore the
contents of an entire disk volume (including blocks that may not be in
use by the file system on that volume), they do not save and restore
specific files, groups of files, directories, or subdirectories. In
addition, these utilities do not defragment a disk. Moreover, the
utilities cannot restore the context of a shadow set virtual unit.
The following sections describe several approaches to shadow set backup
8.3.1 Restrictions on BACKUP Procedures
On VAX systems, accessing shadow sets from standalone BACKUP is not
supported. The command procedures supplied with OpenVMS for building
standalone BACKUP kits are designed to prevent standalone BACKUP from
using volume shadowing improperly. However, these checks can easily be
overridden by a well-informed and sufficiently privileged user.
Note the following restrictions for standalone BACKUP on VAX systems
that use volume shadowing:
- Do not boot standalone BACKUP from an alternative root on a
shadowed system disk while other nodes are booting from the same
shadowed system disk. If you do this, the boot attempt will fail.
- Standalone BACKUP does not mount virtual units. This makes access
to virtual units impossible from standalone BACKUP.
- Do not assume that standalone BACKUP prevents you from accessing a
shadow set member unit. You must prevent standalone BACKUP from sending
output to a disk mounted on any other OpenVMS Cluster member, either as
a directly accessible disk or as the member of a shadow set.
On Alpha computers, the same restrictions apply. You cannot use the
standalone, menu-driven procedure included on the OpenVMS Alpha
operating system distribution compact disc to perform BACKUP operations
on shadow sets.
8.3.2 Using Copy Operations to Create a Backup
This example shows how to use volume shadowing copy operations to
create an offline identical disk volume that you can then use as a
backup of your shadow set. The following command creates a shadow set
with one shadow set member:
$ MOUNT DSA0:/SHADOW=$1$DUA10: SHADOWFACTS
%MOUNT-I-MOUNTED, SHADOWFACTS mounted on _DSA0:
%MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (DISK01) is now a
valid member of the shadow set
The following command adds a second member, $1$DUA11, to the shadow set:
$ MOUNT DSA0:/SHADOW=$1$DUA11: SHADOWFACTS
%MOUNT-I-SHDWMEMCOPY, _$1$DUA11: (DISK02) added to the shadow
set with a copy operation
At this point you must wait for the copy operation to complete before
dismounting the shadow set. When the copy operation is complete,
messages are sent to the system console and to any operators enabled to
The following command dismounts the shadow set, leaving $1$DUA10 and
$1$DUA11 with logically identical volumes:
At this point you can re-create the shadow set with one of the volumes
and keep the other as a backup, or use it as a source for the backup
8.3.3 Using the OpenVMS Backup Utility
Generally you can use the OpenVMS Backup utility (BACKUP) with shadow
sets as you do with regular volumes. (See the OpenVMS System Manager's Manual, Volume 1: Essentials for a
description of how to back up volumes.) You can create BACKUP save sets
or copies from shadow sets by using the shadow set virtual unit name
instead of a physical device name as the input specifier. However, you
cannot always restore to a shadow set by listing the virtual unit name
as an output specifier. The main restriction to any backup restoration
is that you cannot mount the target volume with the /FOREIGN qualifier.
The proper procedure for a BACKUP/IMAGE restoration is described in
The format for a BACKUP command is as follows:
BACKUP input-specifier output-specifier
The format is the same as for any BACKUP operation. The following
command, for example, designates a virtual unit for the input specifier:
$ BACKUP/RECORD DSA2:[*...]/SINCE=BACKUP MTA0:23DEC.BCK
$ BACKUP/RECORD DSA2:[*...]/SINCE=BACKUP MTA0:23DEC.BCK
This command saves all files on the shadow set DSA2 that have been
created or modified since the last backup and records the current time
as their new backup date.