The ELS External Vaulting Feature (ELS Vault) replaces and vastly improves upon its predecessor, the VSM Offsite Vault Feature. ELS Vault provides the following enhancements for vaulting real tape volumes:
Uses the HSC CDS to store vault and vaulted volume data. Using CDS vaulting information instead of the TMS eliminates:
The risk of human error when returning volumes to the automated environment
Stranding volumes in the vault location when missed on the return pull list
Leaving accidentally returned vault volumes in the automated environment
Uses LCM to manage the vaulting process, which has three vault methods:
Vaulting MVCs for Disaster Recovery (DR); for more information, see "Vaulting MVCs for DR."
Vaulting MVCs for Long Term Retention (LTR); for more information, see "Vaulting MVCs for LTR."
Ejecting volumes to a floor vault; for more information, see "Ejecting Specific Volumes to a Local (Floor) Vault."
The first step is to define the vaulted volume area of the HSC CDS. To do so, you run the SLUADMIN SET VAULTVOL utility. For example:
SET VAULTVOL NBRVOLS(40000)
Note:
If you need to add more vault volumes after the initial definition, you need to do so using MERGEcds, so allow enough volumes at initial definition to cover your anticipated needs.
You must have sufficient FREE blocks in your CDS to accommodate the volumes you plan to vault (real tape volumes) plus some overhead for growth. See Configuring HSC and VTCS for information on calculating the space for vault volumes and see Managing HSC and VTCS for how to expand the CDS if the CDS is not big enough to hold your vaulted volumes.
Step two is to define the vaults that contain your vaulted volumes. To do so, you run the SLUADMIN SET VAULT utility for each vault. For example:
SET VAULT ADD NAME(DRVLT1) SLOTS(10000) DESC(’DR Vault') SET VAULT ADD NAME(LTRVLT1) SLOTS(20000) DESC(’LTR Vault') SET VAULT ADD NAME(FLOOR) SLOTS(500) DESC(’Floor Vault')
Note:
The total number of slots in all the vaults that you define cannot exceed the number of volumes specified in theVAULTVOL statement.While HSC defines the vaults and vaulted volumes, LCM manages them. Note especially the following LCM vaulting parameters:
The number of days between when a volume is selected for return from the vault and when it is actually returned to the automated environment. The grace period provides a safety margin so that new volumes arrive in the vault before the old volumes are returned. The default value if not specified is three days.
DEFAULT is mutually exclusive with GRACEPERIOD and is typically used for the "floor" (manual rack) vault that automatically contains all volumes ejected from the automated environment using an LCM EJECT(ASNEEDED). Other volumes being ejected from the ACS can be assigned to this vault as well, for example, a volume that is active but no longer a good automation candidate. Generally this would be a defined vault that is actually racks on the datacenter floor. DEFAULT is a grace period of zero days to allow these volumes to be reentered into the ACS at anytime.
Also note that standard eject options for are available for all vault volumes. This includes which CAPs to use, defining an eject message, mode for the ejects and whether the ejects are to be in slot or volume serial order.
Whenever MVCs are vaulted for DR, you should make a minimum of two copies of each VTV to separate MVCs, one of which remains on-site while the other MVC is ejected and put in an external vault. This is done by assigning two Storage Classes on the Management Class that is assigned to the VTV.
So the challenge is, you want to safeguard your data but you want to use MVC space as economically as possible, as follows:
Define as few Storage Classes as possible. Too many Storage Classes usually means too many MVCs and/or MVCs with few VTVs.
Use as few VTSSs as possible to create MVCs. If at all possible, use one VTSS only to create vault MVCs.
What are other considerations for creating and vaulting MVCs? Consider the following:
First, VTVs need to migrate to vault MVCs as soon as possible so that they can be ejected and moved to the vault because these VTVs are generally not used as input for other job steps.
Second, because DR VTVs expire at different rates, consider grouping VTVs with similar expiration dates on MVCs. However, to reduce the total number of MVCs being created to send to the vault, limit the number of these groups. As there will already be activity to consolidate VTVs to fewer MVCs, the benefit is minimal beyond two groups, one for VTVs with very short expiration periods, like within the next 7 days, and one for all other volumes. VTVs under catalog control should be considered to be part of the second group as there is no way to know the actual expiration date.
Third, while it is not necessary to have separate vaults for DR and LTR purposes, it may be advantageous to have the DR MVCs located in a separate vault. This allows these volumes to be gathered and sent to the DR site when needed.
For LTR data the considerations are slightly different. First, LTR data by definition will not expire for an extended period. Thus, unlike DR data which expires over time, LTR MVCs will not become fragmented. There will be initial periodic processing of these MVCs to get the vaulted MVCs to be as full as possible, just as with the DR MVCs, but once sufficiently full, these MVCs will remain static. There is no need to have more than a single storage class for these volumes. However, note that you may want to migrate immediately some LTR data, other data can be migrated as VTCS automigration selects it. Therefore, you may want to have one Storage Class but two Management Classes for LTR data.
You use the DELSCR parameter of the MGMTclas statement to specify whether VSM deletes scratched VTVs, where DELSCR(YES) causes VSM to delete scratched VTVs, which frees VTSS buffer space and MVC space. Consider specifying DELSCR(YES) for the DR and LTR Management Classes. If you specify DELSCR(YES), only use the LCM SYNCVTV for scratch synchronization. For more information about using LCM to manage scratch synchronization, see LCM User's Guide.
HSC enter process has been modified for the ELS vaulting function so that every volume being entered is checked to determine if the volume is an externally vaulted volume. For such vaulted volumes, one of two actions will take place based upon the return date field in the CDS vault record:
If the return date has occurred, the volume is entered, the stored volume metadata from the eject process is restored, and the volume is removed from the vault records.
If the return date has not occurred or no return date has been set for the volume, the volume is entered, the stored volume metadata from the eject process is restored, but the volume is left in the vault records and it will automatically be ejected by the next eject process. Why does this occur? There are several reasons, where the two most common are that the volume was returned for some sort of data recovery process or the incorrect volume was pulled from the vault (a very common occurrence). Whatever the reason, the volume belongs in the vault and will be returned to that location and resume its protected status.
Note that this is the process for volumes vaulted in a physical vault. For volumes vaulted in a remote library, it is slightly different; see "DR Vaulting with MVCs in a Remote Library."
In a DR scenario, you have the overall business goals of optimizing VTSS buffer use, ensuring speedy migration of critical data, while maintaining data availability.
In this approach, DR volumes are created every day, thus the processing to move them to the DR vault runs every day to ensure that the MVCs are safely moved offsite and protected.
Note:
All VTVs created for DR purposes and all native tapes, including the Manifest File tape created in "Step 2 – Exporting the Vault MVCs," are controlled by the site's TMS (for volumeexpiration).This process is limited to the vaulting of the related MVCs and those selected native volumes involved.
MVCs can only be assigned to one vault. To assign a volume to a new vault, the volume must first be removed from a prior vault assignment.
"Step 7 – Prepare Vaulted MVCs for Return" begins the periodic processing, which allows recycling of DR MVCs that have become fragmented or were only partially filled at creation. This is done by performing "logical" MVC drains of the vaulted MVCs using the copies of the still current VTVs located on the local MVCs. The periodic processing minimizes the number of total volumes in the vault while ensuring that overall related activity is reduced to a minimum, which is done by using selection criteria appropriate to the specific environment. After a successful "logical" drain of a vaulted MVC, the return date is set in the CDS for that volume. In the case of native volumes, such as the Manifest File tapes, volumes that have gone to a scratch status in the TMS are selected and set to be returned. You decide how often to run the periodic processing, ranging from daily to monthly.
DR Vault VTVs are created using a Management Class that points to two Storage Classes, one that creates MVCs that will remain within the local environment and one that creates MVCs that are vaulted. For example:
STOR NAME(DRLOC)ACS(00) MEDIA(STK1RD) STOR NAME(DRVLT1) ACS(00) MEDIA(STK1RD)
You export Vault MVCs through an LCM parameter file such as shown in the following example.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
NoSync
GracePeriod(3)
;
Action
Export
Control(Serial )
MVC
DSN(DRVAULT.MANIFEST)
Storageclass(DRVLT1)
Vault('DRVLT')
;
In this example:
The OPTIONS statement specifies NOSYNC and NOTMS because vaulting does not use TMS information for vaulting and no TMS metadata is required.
The VAULT statement specifies DRVLT as the DR vault.
The ACTION EXPORT statement specifies:
Export MVCs by volser.
Create an Export Manifest File (DRVAULT.MANIFEST), in this case, a volume in the ACS that is ejected and stored with the DR MVCs.
Point to the vault Storage Class created in "Step 1 – Creation of Vault VTVs/MVCs."
Define the DR Vault (DRVLT) and assign MVCs to it not previously assigned to the vault.
Note:
Exported MVCs are marked read-only by the export processing.You can create multiple Vault Storage Classes (for example, to segregate MVCs with VTVs with different expiration dates). If you want to assign different Vault Storage Classes to the same vault, you can do so in a single ACTION EXPORT statement. For example, the following statements assigns Storage Classes DRVLT1 and DRVLT2 to the same vault (DRVLT):
Action
Export
Control(Serial )
MVC
DSN(DRVAULT.MANIFEST)
Storageclass(DRVLT1
DRVLT2)
Vault('DRVLT')
;
After you create the Manifest File tape in "Step 2 – Exporting the Vault MVCs," you can run a job that copies the HSC Control Data Set (CDS), the TMS catalog, the system catalog, and other significant "point in time" data sets to the Manifest File tape to provide additional DR recovery points.
You eject Vault MVCs using an LCM parameter file such as shown in the following example.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Eject
When(
(inLsm)
and
(VaultName EQ 'DRVLT')
Control(Serial)
Ejmsg('Move to DR Vault')
;
In this example:
The OPTIONS statement specifies NOSYNC and NOTMS because vaulting does not use TMS information for vaulting and no TMS metadata is required.
The VAULT statement specifies DRVLT as the DR vault.
The ACTION EJECT statement specifies:
Eject MVCs assigned to DRVLT; eject by volser.
The eject message.
You eject native volumes (including the Manifest File tape) using an LCM parameter file such as shown in the following example.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Eject
When(
(InLsm)
and
(DataSetName EQ 'DRVLT.MANIFEST')
and
(TMSScratch EQ False)
)
Control(Serial)
Ejmsg('Move to DR Vault')
;
In this example:
The OPTIONS statement specifies NOSYNC because vaulting does not use TMS information for vaulting.
The VAULT statement specifies DRVLT as the DR vault.
The ACTION EJECT statement specifies:
Eject the Manifest File tape.
Eject any native volumes not scratched by the TMS.
The eject message.
You create a Pull List using an LCM parameter file such as shown in the following example.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Report
Volume
Sysout(*)
Title('Return Report')
When(
(VaultName EQ 'DRVLT')
and
(VaultReturnDate LE TODAY)
and
(VaultReturnDate NE MISSING)
)
Column (Serial,
VaultSlot)
;
In this example:
The OPTIONS statement specifies NOSYNC and NOTMS because vaulting does not use TMS information for vaulting and no TMS metadata is required.
The VAULT statement specifies DRVLT as the DR vault.
The REPORT VOLUME statement creates a report that lists the volumes in the vault that have reached their previously assigned Return Dates. This is a simple example, you can add more selection criteria for the volumes you want returned.
Note:
TODAY and MISSING are unique values when considering dates. TODAY is translated to the date of the LCM run execution. MISSING means that there is no value for the date. In this example, it means that no date has been set. Both conditions are required as a missing date would be seen as Less Than the current date.
Steps 4, 5, and 6 can be combined into a single jobstep. In some cases, Step 6 is executed on a periodic basis, generally the day before any volumes would be returned from the vault.
You prepare Vaulted MVCs for return using an LCM parameter file such as shown in the following example.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Drain
When(
(MVC EQ True)
and
(VaultName EQ 'DRVLT')
and
(MVCVTVCount LE 30)
and
(MVCInUse LE 30)
and
(Days_Since(VaultAssignmentDate) GT 7)
)
Control(MVCVTVCount
Ascending)
Limit(30)
;
In this example:
The OPTIONS statement specifies NOSYNC and NOTMS because vaulting does not use TMS information for vaulting and no TMS metadata is required.
The VAULT statement specifies DRVLT as the DR vault.
For MVCs currently in the DR vault, the ACTION DRAIN statement specifies draining MVCs that:
Have fewer than 30 VTVs.
Are in use less than 30% of the time.
Have been in the vault at least 7 days.
Limit the number of returned MVCs to a maximum of 30.
The return date is set to 3 days by the GracePeriod parameter.
When you create a parameter file to drain MVCs, you want to balance between the processing cycles for the drain and the need to recycle fragmented or partially filled MVCs. Accordingly, the MVCVTVCount, MVCInUse, Days_Since, and LIMIT parameters provide the controls to balance these requirements.
You prepare native volumes for return using an LCM parameter file such as shown in the following example.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Return
When(
Not (MVC)
and
(VaultName EQ 'DRVLT')
and
(TMSScratch EQ True)
)
;
In this example:
The OPTIONS statement specifies NOSYNC because vaulting does not use TMS information for vaulting.
The TMS RMM statement is necessary to add the processing of TMS metadata.
The VAULT statement specifies DRVLT as the DR vault.
The ACTION VAULT RETURN statement sets a return date (using the GracePeriod parameter) for volumes that are not MVCs and are in scratch status in the TMS.
Volumes that appear on the report created in "Step 6 – Create a Pull List of Volumes for Return from the Vault" are removed from the DR vault and returned to the local environment. When you enter these volumes in the ACS, HSC checks if the assigned Vault Return Date has occurred for each volume. If it has, the volume has attained its scheduled return date, and it is removed from the vault. Returned MVCs are then made eligible for migration and native volumes are made scratch in the CDS the next time that LCM SYNC processing occurs. If the Vault Return Date has not occurred, the volume is ejected by "Step 4 – Eject Vault MVCs."
If desired, you can combine Steps 7 and 8 in a single LCM parameter file as shown in the following example:
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Drain
When(
(MVC EQ True)
and
(VaultName EQ 'DRVLT')
and
(MVCVTVCount LE 30)
and
(MVCInUse LE 30)
and
(Days_Since(VaultAssignmentDate) GT 7)
)
Control(MVCVTVCount
Ascending)
Limit(30)
;
Action
Vault
Return
When(
Not (MVC)
and
(VaultName EQ 'DRVLT')
and
(TMSScratch EQ True)
)
;
Some sites may elect to use a multiple week process where DR processing includes a weekly full volume backup of critical data, followed by daily incremental backups over the next six days. The external vaulting process moves volumes offsite on day of creation. This process assumes a four week cycle that keeps the DR data offsite and complete until the fourth week starts. Note that the only change between "Basic DR Vaulting with MVCs" and the multiple week process is the difference in selection criteria for Steps 7 and 8 as described below. This is done by setting the expiration dates so that the vault VTVs on the associated MVCs and the Manifest File tapes (and any other native tapes involved) all expire on the specific date 22 days after creation.
The multiple week timeline is as follows:
Day 1 – Full Volume Backups (Expire on Day 22).
Day 2 – Incremental Backup #1 (Expire on Day 22).
Day 3 – Incremental Backup #2 (Expire on Day 22).
Day 4 – Incremental Backup #3 (Expire on Day 22).
Day 5 – Incremental Backup #4 (Expire on Day 22).
Day 6 – Incremental Backup #5 (Expire on Day 22).
Day 7 – Incremental Backup #6 (Expire on Day 22).
Days 8 through 21 – volumes remain off site.
Day 22 – Backups and Manifest File tapes from Days 1 through 7 expire and VTVs go scratch in CDS through the LCM VTVSYNC process. MVCs are drained using the following parameter in the selection criteria for "Step 7 – Prepare Vaulted MVCs for Return" and "Step 8 – Prepare Vaulted Native Volumes for Return."
DAYS SINCE (VaultAssignmentDate) GT 15
The return date for drained MVCs and Manifest File tapes is set for Day 25.
Note:
All MVCs assigned to the vault during the first seven days of the cycle are drained. If the expiration date of the DR VTVs was set correctly, there should be no current VTVs at this point and the logical drain process will execute quickly. If current VTVs are written to a new MVC, the cause would be an incorrect expiration date being set.Day 23 and 24 – Volumes remain offsite.
Day 25 – Vaulted volumes from Days 1 through 7 are returned and removed from vault status and are available for reuse.
Day 29 – Cycle repeats.
Note:
Some sites may elect to only take the full volume backups off site, keeping the incremental backups on site. In this case, place the incremental MVCs and the related Manifest File and native volumes in a container that is locked and not reopened until its return on Day 25. At that point, all volumes created on Day 1 should be expired.In this process, instead of vaulting volumes in a physical vault, the volumes are vaulted in a remote library (ACS). This process is similar to "Basic DR Vaulting with MVCs" with the following exceptions:
Steps 1 through 3 - No change.
Step 4 - Eliminated because no ejects of vaulted MVCs are done.
Step 5 - As with Step 4, native volumes are not ejected. Instead, an Action Vault Assign statement assigns native volumes to the vault using the same selection criteria that would have been used to perform and eject of these native volumes as shown in the following example.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Assign
Vault('DRVLT')
When(
(InLsm)
and
(DataSetName EQ 'DRVLT.MANIFEST')
and
(TMSScratch EQ False)
)
;
Step 6 - Eliminated because no volumes are reentered.
Step 7 - No change.
Note:
Because the drain processing occurs within the remote library, drains execute more efficiently than the logical drain processing for volumes in a manual vault.Step 8 - No change.
Step 9 - In the Basic Process, the vault assignment is removed by the enter processing which does not occur in the remote library scenario. To remove the vaulted volume, use the Action Vault Release statement. The vaulted volumes to be released are selected by Vault Name and the Return Date as was previously done to generate a Pull List. The Action Vault Release statement only processes vaulted volumes whose Return Date has occurred.
The following shows an example of the Action Vault Release statement.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Release
When(
(VaultName EQ 'DRVAULT')
and
(VaultReturnDate LE TODAY)
and
(VaultReturnDate NE MISSING)
)
;
The process for using MVCs to hold Long Term Retention (LTR) MVCs is essentially the same as described in the Basic Process for Disaster Recovery described in "Basic DR Vaulting with MVCs." The two major considerations for LTR usage are:
Movement to the vault, "Step 2 – Exporting the Vault MVCs" through "Step 5 - Eject Native Volumes (Including Manifest File Tape)," may not be a daily function so that more LTR volumes are completely filled before being vaulted.
The LTR VTVs will not expire for long periods of time, thus the periodic process described may only occur at longer time intervals. There will still be LTR MVCs that are only partially filled, so at some interval, those partially filled MVCs with fewer VTVs and low MVC usage must be processed so that the VTVs on the partially filled MVCs are consolidated on fewer LTR MVCs.
At some point in the future, there may be a need perform the logical drains of the LTR MVCs to move the archived data to new media. The basic process easily performs that activity by simply making the appropriate selection criteria choices and limiting the number of vaulted LTR MVCs processed at one time. With each execution, the still current VTVS are moved to the new media, those new MVCs are moved to the vault and the logically drained MVCs are returned for reuse or destruction.
Many sites may require specific volumes to be removed from the automated environment and need to efficiently store these volumes locally in racks in the local environment. This requirement may come from such activities as retiring volumes from use and desiring to keep the volumes available for some time. Multiple local/floor vaults can be defined with specific volumes being sent to different vaults, but only one local/floor vault can be defined as a "Default" vault. All volumes placed in a local/floor vault are automatically assigned a Return Date of the current date. This allows these volumes to be returned to the automated environment and deleted from their vault assignment with no further action.
The following example shows an LCM parameter file example of ejecting specific volumes to a Floor Vault.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('FLOOR')
Default
;
Action
Eject
When(
(InLsm EQ True)
and
(DaysSinceReference GT 100)
and
(MVC EQ False)
and
Not
(DataSetName Matches 'HMIG.**')
)
Control(
VaultSlot
Ascending
)
Ejmsg('Move to Floor Vault')
;
Manage
ACSID(00)
Numfree(500)
;
In this example:
The OPTIONS statement specifies NOSYNCH because vaulting does not use TMS information for vaulting.
The TMS RMM statement is necessary to add the processing of TMS metadata.
The VAULT statement specifies FLOOR as the default floor vault.
The ACTION EJECT statement specifies to eject the volumes to the Floor Vault that:
Are in the LSM.
Have not been referenced in over 100 days.
Are not MVCs.
Have a data set name mask of HMIG.**.
The ACTION EJECT statement also specifies:
Process volumes in ascending volser order.
Eject by TMS slot numbers.
The eject message.
The MANAGE statement specifies:
Manage volumes in ACS 00.
Ensure 500 free cells in the ACS.