HP OpenVMS Systems
DIGITAL Equipment Corporation
DIGITAL Equipment Corporation
January 20, 1998
This paper provides information about converting a set of backup policies from Storage Library System for OpenVMS (SLS) to Archive Backup System for OpenVMS (ABS). Both of these products are produced by DIGITAL Equipment Corporation and both provide data backup services for OpenVMS.
Alpha, DCL, DECnet, DIGITAL UNIX, eXcursion, OpenVMS, VMS, OpenVMS Cluster, StorageWorks, VAX, VMS and the DIGITAL logo are all trademarks of DIGITAL Equipment Corporation.
NT is a trademark of Microsoft Corporation.
Windows and Windows NT are both trademarks of Microsoft Corporation.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.
POLYCENTER Scheduler is a trademark of Computer Associates, Inc.
Oracle, Oracle Rdb, and Oracle RMU are all registered trademarks of Oracle Corporation.
All other trademarks and registered trademarks are the property of their respective holders.
Table of Contents
1. Executive Summary
1.1 Why Convert from SLS to ABS?
1.1.1 Consolidated Policy Management
1.1.2 More Intuitive Policy Organization
1.1.3 Better Logging and Diagnostic Capabilities
1.1.4 UNIX and NT Clients
1.1.5 Automatic Full and Incremental Operations
1.1.6 More versatile User requested Operations
1.1.7 Disk Storage Classes
2. SLS and ABS System Backup Policy Overview
2.1 SLS Policy with ABS Equivalents
2.1.1 System Backup Policy Configuration
2.1.2 Defining Your System Backup Policy
2.1.3 Restoring Data
2.1.4 Media Management
2.2 ABS Overview with SLS Equivalents
2.2.1 Policy Configuration
2.2.2 Storage Class
2.2.3 Execution Environment
2.2.4 Save Request
2.2.5 Restore Request
2.3 Media and Device Management
3. SLS and ABS Operation Overview
3.1.1 SBK Symbols for Scheduling
3.1.2 ABS Use of POLYCENTER Scheduler
3.2 Types of Operations
3.2.1 System Backups
3.2.2 Full and Incremental Operations
3.2.3 Selective Operations
3.2.4 User-requested Operations
3.3 Tape, Robot and Device Management
3.3.1 Volume Set Management
3.3.2 Consistency of Volume and Drive Management
3.4.1 SLS History Sets
3.4.2 ABS Catalogs
3.4.3 Restoring data with ABS from SLS History Sets
4. Conversion Process
4.1 Steps for Conversion
4.1.1 Determine your use of SLS
4.1.2 Converting SLS System Backups to ABS
4.1.3 Converting User Backup policy
4.1.4 Monitor the ABS Activity
4.1.5 Restoring from SLS History Sets
5. Conversion Utility Reference
5.1 Command Syntax
5.2 Output Command File naming and contents
Appendix B. ABS Policy Attributes in SBK Terminology….…………………………………………….30
This paper is intended for Storage Library System (SLS) users who are considering a conversion to the newer Archive/Backup System (ABS) product.
The goals of this paper are to
This paper does NOT:
SLS was the first automated storage management product from DIGITAL Equipment Corporation. Although it is fairly reliable once it is configured, learning to configure SLS is quite a challenge. In addition, when problems do occur, diagnosing the problem and making a fix to the source code is very difficult, and sometimes impossible.
ABS was developed to improve upon and replace SLS over time. It was first released by DIGITAL in 1995. ABS has the following advantages over SLS:
ABS uses the same Media and Device Management Services (MDMS) that SLS uses, so no conversion of volume data is required. ABS has the ability to read old SLS history sets and restore data from old SLS backups, so conversion to ABS can be performed in stages over time.
All of the ABS policy for what gets backed up and how is stored in a single policy database on an OpenVMS cluster in your network called the Central Security Domain, or CSD. Through this centralized policy database, ABS supports the ability to control your entire network’s backup policy from a single location, or allows you to distribute the responsibility for backups and restores to other system managers on other OpenVMS nodes. This is contrary to the SLS method of storing SBK files on each node to be backed up, where a minor change in tape drive configuration or policy can take hours or days to propagate through all SBK files on a large network.
ABS Policy is organized into simple policy objects:
ABS provides improved logging and diagnostic capabilities. Notification of job completion and status can be sent via MAIL or OPCOM. ABS log files are easier to read and interpret than SLS log files.
ABS provides backup and restore capabilities for NT and UNIX clients. This allows the workstation disks to be backed up and cataloged with the reliability and availability of OpenVMS.
ABS makes backup scheduling easy by providing a variety of backup schedule options, such as Weekly Full with Daily Incremental, and log-based scheduling. These backup schedules minimize tape usage and backup time by only doing occasional Full backups, with Incremental backups making up the bulk of the data movement operations. ABS also provides the Full Restore capability for a disk or other data object, automatically restoring the necessary Full and Incremental backups to retrieve the data.
ABS provides users the ability to backup and archive their own files, if allowed by the site management. By setting Access Control Lists (ACL’s) on Storage Classes and Execution Environments, you can allow users to save data and restore data without intervention of the system manager.
ABS provides the ability to backup to disk savesets. This ability is especially useful for optical media, since many optical devices appear as disk devices to the operating system. In addition, disk storage classes can be used for backup operations in which the savesets need to be online for quick restores.
Chapter 2 gives an overview of backup policy as implemented in SLS and ABS, comparing the two products representation and organization of policy.
Backup policy can be viewed as:
SLS Backup policy is stored in SBK files, which are DCL command procedures. These SBK files are located on the system where the backup is to be run. The SBK files define a variety of DCL symbols, which identify the What, When, Where, Who and How of each backup to be performed.
The table below gives the primary DCL symbols of the SBK file which identify each component of the backup policy. There are numerous other parameters in the SBK and ABS policies, but this table gives an overview.
See Appendix Appendix A for a complete description of each SBK Symbol and its ABS equivalent.
In ABS, Backup Policy is consolidated in a network-wide Policy Database. The policy is created and modified using the ABS DCL Interface, or the ABS Graphical User Interface (GUI).
To define a backup policy in SLS, you log onto the system where the backup is to be performed, copy SYSBAK.TEMPLATE to a new SBK file, and then edit the SBK files using a regular text editor. You define each SBK symbol according to what you want the backup policy to do.
This manual editing of SBK files tends to be error prone. Each SBK symbol must be defined in a particular syntax, and it is easy to make typing errors. When syntactic errors are made in the SBK symbols, it is often unclear in the SLS log files what the actual problem is, and how it can be fixed. In addition, in a fairly large network, the management of the SBK files can become quite cumbersome, requiring substantial time and organization on your part.
In ABS, Backup Policy is consolidated in a "Policy Engine", which contains all the backup policy for your network. ABS Backup Policy is defined by creating one or more Storage Classes, one or more Execution Environments, and one or more Save Requests. This is done using either the DCL command interface, or using the Graphical User Interface (GUI). V2.2 of ABS has a new, easy-to-use GUI for convenience of defining your backup policy.
Storage Classes and Execution Environments can be shared by multiple Save Requests. From the Central Security Domain (where your ABS Policy Engine is installed), you can create Save Requests for disks, files or other data objects on remote nodes, which share the common Storage Classes and Execution Environments.
In SLS, to restore a particular set of files for a user, the Operator or System Administrator must regularly get involved. This is because the SLS System History Sets, which store information needed to perform the restore, are not accessible to regular users.
In ABS, the Access Control List (ACL) on the Storage Class can be set up to allow access to all users, or only selected users. This allows individual users to restore their own files from these Storage Classes.
When using the SLS Storage Restore command, the user (or Operator) must specify the specific volume, saveset and version of the file to restore. When using the Storage Restore screen, no choice is given about the version of the file to be restored.
In ABS, a date-oriented selection for a file to restore is provided. Normally, users will request the most recent version of a file to be restored, since user restores are regularly due to accidental deletion. However, in ABS, the user can specify that the most recent copy before a particular date should be restored. This allows the user to fine-tune the restore operation.
In SLS, an operation called a Full Disk Restore is provided. This is a fairly manual method by which a Full backup and associated Incremental backups can be used to restore a full disk.
To perform a Full Disk Restore in SLS, you must manually select the Full and Incremental backups to be applied, and in what order. Although this provides a great deal of versatility, it can also be error prone. Once an automated backup policy is set up, many customers are not familiar with the specific backups which are done, and determining the correct order of a restore can be difficult.
In ABS, when a Restore Request is created for a Disk, the type of restore can be specified as "Full Restore". This causes ABS to automatically find the most recent Full Backup, and all subsequent incremental backups (of appropriate level in the case of log-based backup schedules), and commence the restore in the correct order.
SLS and ABS use the same Media and Device Management Services (MDMS). When moving to ABS, there is no need to learn a new media management system, or convert your existing tape library, media types, tape pools, robot definitions, and drive lists. The same STORAGE commands used to manage media, robots and devices in SLS are used to manage them in ABS.
In ABS, the Backup Policy is stored in five different types of policy objects:
These policy objects each have a Name, and Access Control List (although a catalog’s access is controlled through Storage Class). They are created using the ABS DCL Command, or using the Graphical User Interface (GUI).
These policy objects (except the catalogs) are stored in a central location, called the Policy Database. The Policy Database resides on a single OpenVMS cluster in your network, called the Central Security Domain (CSD). The CSD controls all of the Storage Classes and Execution Environments used throughout the network, but Save and Restore Requests can be created from any OpenVMS node in the network where ABS is installed..
The ABS policy can be completely controlled from the CSD, or responsibility for creating backups and restores can be distributed to the system managers on other OpenVMS nodes. The Access Control on Storage Classes and Execution Environments determine which OpenVMS nodes in the network are allowed to create Save and Restore requests referencing these objects.
Catalogs are stored on each OpenVMS node where backups are performed. Catalogs for the NT and UNIX clients are stored on the ABS server. This substantially reduces the network bandwidth required for doing backups across the network to a centrally-located robot or storage facility.
An ABS Storage Class contains information about where backed up files and other data objects (such as databases or UNIX and NT file systems) are to be stored. As many Storage Classes as necessary can be created in the ABS Policy Database. Multiple Save Requests can share a single Storage Class.
The information in a Storage class, with each parameter’s SBK file equivalent are given in the table below.
An ABS Execution Environment (or simply Environment) object stores information about how backups are to be performed. This includes parameters regarding data-safety, file interlocking, notification, and so forth. As many Environment objects as necessary can be created in the ABS Policy Database. Multiple Save Requests can share a single Execution Environment.
The information in an ABS Environment, along with each parameter’s SBK equivalent, is given in the table below.
An ABS Save Request identifies the data to be backed up, the Storage Class and Environment to be used for the backup(s), and the schedule on which the request is to be executed. As many Save Requests as necessary can be created in the ABS Policy Database, and multiple Save Requests can share any Storage Class or Execution Environment.
The information stored in a Save Request, with each parameter’s SBK equivalent, is given in the following table.
An ABS Restore Request stores information about files, disks, or other data objects to be restored from a Storage Class. As many Restore Requests as necessary can be created in the ABS Policy Database.
The information stored in a Restore Request are given in the table below. Because SLS does not provide a formal Restore Request mechanism, no SBK or other SLS equivalents are given.
An ABS Catalog object stores information about what backup operations have been performed, and what files or other data objects have been backed up. The ABS Catalog object combines the SLS concepts of a Summary File, a System History Set, and a User History Set.
Catalog objects are accessed through one or more Storage Classes. More than one Storage Class can share a Catalog, or each Storage Class can have a separate catalog. The ABS Catalogs can also be queried using the ABS LOOKUP command (or associated GUI function) and the ABS REPORT SAVE command.
ABS Catalogs are created using the ABS$SYSTEM:ABS_CATALOG_OBJECT.EXE utility. An ABS Catalog has the following parameters specified when it is created:
SLS and ABS use the same Media and Device Management Services (MDMS). When moving to ABS, there is no need to learn a new media management system, or convert your existing tape library, media types, tape pools, robot definitions, and drive lists. The same STORAGE commands used to manage media, robots and devices in SLS are used to manage them in ABS.
This chapter gives a comparison of SLS and ABS operations. This gives information about how Save Requests are executed in each product, with similarities and differences between the two pointed out.
In SLS, the SBK symbols DAYS_n and TIME_n identify the schedule and start time for the save request to execute. Each DAYS_n symbol can have one of the following forms:
Every night at midnight, a special utility process in SLS is executed, which scans all the SBK files on the system. It determines which SBK files are to be executed that day and at what time. It then submits a Batch job for each SBK, specifying the start time of the batch job to match the TIME_n parameter.
ABS uses POLYCENTER Scheduler to schedule its Save Requests. A Save Request is scheduled using a Start Time and a Scheduling Option.
A variety of pre-defined scheduling options are provided:
In addition, ABS provides access to POLYCENTER Scheduler "intervals", which can include fiscal intervals, such as "FM D-2", which is the same as the SLS "MONTH - 2" syntax.
An important difference between SLS and ABS is that an ABS Save Request can only have a single schedule and start time, while an SLS SBK file can have multiple DAYS_n and TIME_n parameters. However, because the ABS Save Request can be run using a POLYCENTER Scheduler RUN command, any number of scheduler jobs can be created to run the Save Request as needed.
Another important difference between ABS and SLS is SLS’s ability to specify a list of day names. To provide the same functionality in ABS, the Scheduler SET JOB/DAYS command must be executed.
This section discusses the various types of operations performed by SLS and/or ABS, and identifies similarities and differences between the two products.
System Backups are the type of backup which is performed by the system on behalf of the users. Normally, this type of backup backs up entire disks or file systems, which can then be used to restore any particular file or set of files for any particular user.
The System Backup is what is implemented via the SLS SBK file. It has these characteristics:
In ABS, a System Backup is performed by setting up an Execution Environment whose User Profile indicates the ABS account (with particular privileges and access rights). Then, any Save Request which uses that Environment would be considered a "System Backup".
The ABS installation kit provides out-of-the box policy objects for performing system backups. These are the SYSTEM_BACKUPS Storage Class, and the SYSTEM_BACKUPS_ENV execution environment. If the parameters on these policy objects are not suitable to your environment, they can be modified using the ABS SET command (or equivalent GUI functions).
An ABS System Backup has the following characteristics:
As shown above SLS and ABS System Backup operations are very similar in their overall operation. Both use MDMS to access tapes, robots and tape drives. Both use subprocesses to perform the actual backup operations using other utilities, or Backup Agents. Both produce a catalog of the operations performed and the files (or data objects) backed up.
However, SLS and ABS System Backup operations have these important differences:
A "Full" backup operation is one which saves all the information on a disk, including any file-system specific information. OpenVMS Backup calls these "Image" backups.
An "Incremental" backup only saves data and directory structure that has changed since either a particular date, or since each file was backed up.
Usually, a backup policy combines these two types of operations. Although a Full backup is desirable because it contains all of the data on a disk or filesystem at the time of the backup, it also uses more tape, is more time-consuming, and occupies more catalog space. An Incremental backup uses less tape, less time, and less catalog space, but requires more time during the restore of a full disk.
SLS provides indirect access to Full and Incremental operations. In the SBK file, the QUALIFIERS symbol can be defined to contain the string "/IM" (Image) or "/SINCE=BACKUP" (Incremental) to manually determine whether a particular save operation is a Full or Incremental backup. You must explicitly set up the Full and Incremental schedule using the QUALIFIERS symbol.
In ABS, Full and Incremental operations can be automated using a variety of schedules:
See the ABS Documentation for full information on these schedules.
The interval scheduling options on a Save Request cause the ABS Coordinator to automatically decide the correct operation to perform each time it is executed. For example, a fully functional, efficient backup schedule for a set of disk can be set up to run each night at 6:00PM with the single ABS Command:
$ ABS Save DISK$USER1:,DISK$USER2:,DISK$USER3:,DISK$USER4: -
Then, if one of these disks goes bad, for example DISK$USER3:, you can restore the whole disk to the previous night’s backup by issuing the commands:
$ DISMOUNT/NOUNLOAD/CLUSTER DISK$USER3 ! prepare for restore
$ ABS Restore/Full DISK$USER3:/Storage=SYSTEM_BACKUPS
ABS will automatically find the most recent Full save, apply that to the disk, and then apply each subsequent Incremental backup in the correct order to the disk.
Selective Backup operations are portions of an entire disk or filesystem. For example, you might want to only backup a particular user’s directory, or a particular file or set of files.
A Selective Operation in SLS is identified when neither "/IM" (Image) nor "/SINCE=BACKUP" (Incremental) is found in the QUALIFIERS symbol. This indicates that the files given in FILES_n should be backed up "as is", and not as part of a whole disk or file system.
In ABS, the type of operation is specified on the Save Request. If the operation is specified as "Selective", then sets of files or other data objects can be backed up.
SLS provides the Storage Save command, which allows individual users or the system administrator to backup files "on demand". This type of operation is called a "User Backup" under SLS, because it has the following characteristics:
In ABS, any user with appropriate access levels can issue an ABS Save command, and back up their own files. It is access to the Storage Classes and Execution Environments which constrain which tapes and tape drives can be used by individual users.
For example, if you set the Access Control List (ACL) on the SYSTEM_BACKUPS Storage Class to be:
then any user can write into the Storage Class (do backups to it) or Read from the Storage Class (restore files from it).
The ABS installation kit provides an out-of-the-box set of policy objects for user backup operations. These are the Storage Class USER_BACKUP and the Environment USER_BACKUP_ENV.
The User Profile in the Execution Environment determines the context in which the backup operations are performed. Except in special cases, Environments which are accessible to the average users will have a user profile specifying the keyword "<REQUESTER>" as the user under which the backups are to be performed. This causes ABS to capture the user’s username, privileges and access rights when they create a Save Request using this Environment, and use these parameters during the backup operations.
In ABS, all volumes are owned and managed by the ABS account. The primary goal of ABS is data safety. This primary goal precludes allowing individual users to manage their own tapes, since the user may destroy data accidentally, or misuse the tapes. Access to the tapes owned by ABS is allowed by setting the Access Control on Storage Classes.
Using the USER_BACKUP Storage Class and USER_BACUPS_ENV execution environment, users can issue their own Save and Restore requests. These backup operations share a common pool of tapes and a common catalog with other users, but each user can only access their own backed up data on these tapes.
If you want a user to be limited to a particular set of tapes, or record their backups in a separate catalog, ABS also allows this to be configured by issuing the steps below:
This section describes similarities and differences between how SLS and ABS handle tape, robot and device management.
Tape, robot and tape device management in both SLS and ABS are provided by the Media and Device Management Services (MDMS). This means that moving from SLS to ABS does not require learning a new media manager, or converting a volume database.
There are a couple of significant differences between the way SLS and ABS do volume management:
Volume Sets are a collection of tapes which are treated as a single entity. The tapes are logically appended to one another, allowing more data to be stored and wasting less tape.
SLS only provides very rudimentary volume set management in the form of the CONTINUE symbol. Any SBK file which uses a consistent value of the CONTINUE symbol will have its savesets appended to a volume set managed by SLS. However, the user must explicitly name the volume sets (i.e. the value of the CONTINUE symbol), and creating new volume sets is problematic.
In ABS, data is written to volume sets automatically. Each Storage Class has one or more volume sets which it manages. The number of volume sets managed by a Storage Class is called the Number of Streams, or Number of Simultaneous Read and Write Operations.
ABS automatically creates new volume sets based upon the Storage Class’s Consolidation Criteria. The Consolidation Criteria determines how data is consolidated onto volume sets. There are three criteria which can be used to limit the amount of data written by ABS to a volume set:
Once ABS determines the consolidation criteria has been exceeded on a volume set, it automatically "retires" the volume set. Retiring a volume set allows data to be restored from it, but no more data is written to the volume set. ABS then automatically creates a new volume set for backing up data in the Storage Class.
SLS is very inconsistent in its management of volumes and drives. For example, SLS System Backups do a different style of tape load than SLS User Backups, and the source code is completely different. In addition, the way that tapes are appended to volume sets, the messages indicating problems, and the methods for debugging problems in these areas are completely inconsistent.
ABS does all tape and drive management via MDMS through the ABS Coordinator. All types of data movements, from Selective to Full, Saves and Restores, and all types of Backup Agents are managed by the ABS Coordinator. This means that tape, robot and drive management are completely consistent across all operations.
This section identifies similarities and differences between how SLS and ABS handle cataloging operations. Catalogs (called History Sets in SLS) record what backup operations have taken place, and what files or other data objects have been backed up.
SLS History Sets come in two varieties: System History Sets and User History Sets. System History Sets are updated for system backups (i.e. SBK files), while User History Sets are updated for user backups.
Creating and configuring history sets is troublesome on SLS. The TAPESTART.COM command procedure is used to determine what System History Sets are created, and where they are located. The User History Sets are created on a per-user basis, using the ASNUSRBAK.COM command procedure. Configuring User Histories depends upon the user executing the SLS$TAPSYMBOLS.COM procedure in their LOGIN.COM.
Although the information stored in both System and User History Sets are similar, the source code to write to them, look up files and restore files is totally different. This is a problem for maintenance, and prevents consistency in the data available for data backed up by SLS.
System History Sets are "staged", which means that during the backup operation, the history records are written to a sequential temporary file. This improves the performance of the backups. Then, at a later time, the temporary files are loaded into the actual System History Sets, which can then be used to restore files. User History Sets are never staged.
SLS History Sets contain no protection information. The entire history set must be protected against individual users reading and restoring data. This means that at most sites, restoring data from system backups must be done by the Operator or System Administrator to prevent users from restoring data they would not normally have access to.
ABS has only one catalog format, called a Brief catalog. This catalog provides basic information about what backup operations have been done, and what files or other data objects have been backed up. All ABS Catalogs have the same format, and are written by the ABS Coordinator, so information is consistent across all backups.
Creating catalogs in ABS is done by running the ABS$SYSTEM:ABS_CATALOG_OBJECT utility. Using this utility, you can create new catalogs with any name and owner. The utility also allows you to specify whether the catalog supports staging or not. Staging is where the catalog records are written to a temporary sequential file during the backup to improve performance, and then loaded into the actual catalog at a later time.
By default, ABS stores all catalogs in a single location on each system where backups are performed. This location is referenced by the ABS$CATALOG logical name. If you want to place the catalogs in other locations, you can move the catalog files to another directory, and redefine the ABS$CATALOG logical name. The ABS Documentation provides full information on this procedure.
ABS provides the ability to perform lookups and selective restores using SLS System History Sets. SLS System History Sets are written by SLS system backup operations to locate the tapes and savesets containing backed up data. This ability is an important function for any conversion plan, since the data backed up previously by SLS may be needed even after ABS has been fully deployed.
ABS cannot perform full disk restores or Oracle RDB Database restores using SLS history sets. It can restore VMS files selected using a wildcard file specification. Please see the ABS documentation for full details on this capability.
The steps for restoring data using ABS with SLS History Sets are:
$ Catalog_obj := $ABS$SYSTEM:ABS_CATALOG_OBJECT.EXE
$ Catalog_obj Create <hisnam> SLS ABS NO
where <hisnam> is the name of the SLS history set from TAPESTART.COM. This will also be the name of the ABS catalog.
NOTE: You must have the ABS_LOOKUP_ALL access right granted to your account to display entries in the SLS History Files from ABS.
This chapter identifies the Conversion Process from SLS to ABS. First, the steps involved in converting from SLS to ABS are presented and explained. A Conversion Utility to help with the conversion is then presented.
This section identifies the steps involved in converting a site’s backup management from SLS to ABS. These steps are intended as guidelines, since each site has different requirements and need for their backup management.
The first step in converting from SLS to ABS is to identify how you use SLS. There are three major uses of SLS:
ABS provides the same functionality as SLS System Backups and SLS User Backups. However, ABS cannot perform the same function as SLS Standby Archiving. SLS Standby Archiving has the following characteristics:
If you use SLS System Backups (as many sites do), then converting to ABS is fairly simple. If you use SLS User Backups, converting to ABS is slightly more involved, but is still fairly straightforward. If you use SLS Standby Archiving, ABS will not provide equivalent functionality.
This section describes how to convert SLS System Backups (SBK files) into ABS Policy.
At many sites, only a few of the SBK files which reside in SLS$SYSBAK are actually used. The other SBK files are a result of experimentation, false starts at configuring SLS, or are obsolete.
In order to simplify the conversion of SLS System Backups, you should first identify the SBK files which you actually use. Usually, SBK Files are used at your site if:
A simple way of finding the SBK files which are scheduled by SLS is to search the SBK files for the DAYS_1 symbol. Any SBK file which does not define DAYS_1, or defines it as blank, is not scheduled by SLS for automatic execution. These SBK files are prime candidates for obsolete or unused files.
After identifying the SBK files which are not automatically scheduled, carefully determine which of the files may be invoked manually by you or the Operator.
Once you have identified the obsolete or unused SBK files, you can remove them from SLS$SYSBAK (after backing them up in case of mistakes, of course).
Once you have cleaned up your SLS$SYSBAK directory to only contain those SBK files you actually use, it is time to convert these SBK files to ABS Storage Classes, Execution Environments and Save Requests.
DIGITAL provides a utility to help in this conversion process. The conversion utility is called SLS_CONVERT.COM, and is included as an installation kit on the ABS V2.2 Kit. To install the SLS to ABS Conversion utility, issue the command:
$ @SYS$UPDATE:VMSINSTAL SLSTOVABS022 ABS$SYSTEM: ! VAX System
$ @SYS$UPDATE:VMSINSTAL SLSTOAABS022 ABS$SYSTEM: ! Alpha System
This command will install the conversion utility into ABS$SYSTEM:SLS_CONVERT.COM, and will create a subdirectory under the ABS$ROOT called SLS_CONVERSION. In addition, a logical name, ABS$SLS_CONVERSION will be defined to point to the work directory for the conversion effort.
The conversion utility creates DCL Command Procedures which issue the appropriate ABS DCL commands equivalent to each SBK file. No changes are made to your ABS Policy Configuration directly. This allows you to experiment with the conversion utility safely, without affecting either the execution of your SLS SBK files, or starting ABS Save Requests inadvertently.
Once you have installed the conversion utility, you can create the ABS command procedures for all of your SBK files by issuing the command:
$ @ABS$SYSTEM:SLS_CONVERT *
The asterisk indicates you want to convert all SBK files to ABS DCL Commands. If you only want to convert one SBK file, you can specify the name of the SBK without the _SBK.COM or SLS$SYSBAK on
the command line. For example, to convert NIGHTLY_SBK.COM, you would issue the command:
$ @ABS$SYSTEM:SLS_CONVERT NIGHTLY
After running the conversion utility, the ABS$SLS_CONVERSION directory will contain one ABS DCL Command Procedure for each SBK file converted. These output command files will contain:
You should NOT execute these command procedures blindly. The conversion utility attempts to duplicate the backup policy reflected in each SBK file, but you should carefully examine each command file produced to ensure that errors were not made, and that the ABS Policy to be created correctly reflects the backup policy you expect.
The things you should check for in the produced command procedures are:
The command procedure for each SBK file processed will contain the ABS DCL Commands to create one Storage Class, one Execution Environment and one or more Save Requests.
The name of the Storage Class created for an SBK file will be the value of the CONTINUE symbol (if defined) followed by the suffix "_SC". If the CONTINUE symbol is not defined, the Storage Class will be named the same as the SBK file with the "_SC" suffix.
The Environment created for an SBK will be named the same as the SBK file, but with an "_ENV" suffix. When a Save Request specifies a Storage Class, the default Environment used will be the same name as the Storage Class, but with the "_ENV" suffix. Thus, the Environment created should be used by default.
Each SBK File will produce one or more ABS Save Requests. More than one ABS Save Request will be produced from an SBK file if all the following conditions are met:
For example, if an SBK file has QUALIFIER_1 defined as "/IM" indicating an Image (or Full) backup operation, but QUALIFIERS_2 is defined as "/SINCE=BACKUP" indicating an Incremental operation, then ABS will need two separate Save Requests to implement this policy. This is because an ABS Save Request will only do Full, Incremental or Selective operations, not a mix of them.
If all QUALIFIERS_n specify the same movement type and there are fewer than eight FILES_n, then ABS can combine all the operations into a single Save Request.
The Save Requests created will be named the same as the SBK file, but with "_FULL", "_INC" or "_SEL" to indicate the data movement type included in the Save Request. For example, if the SBK file NIGHTLY_SBK.COM defines FILES_1 through FILES_20, and all qualifiers include the "/IM" Image qualifier, then the conversion tool will create three Save Requests, called NIGHTLY_FULL_1 through NIGHTLY_FULL_3. Because ABS has a limit of 8 operations per save request, NIGHTLY_FULL_1 and NIGHTLY_FULL_2 would perform 8 Full backup operations, and NIGHTLY_FULL_3 would perform the last four.
The Conversion Utility shipped with V2.2 of ABS is a very simple utility. It converts each SBK file into the appropriate ABS DCL Commands to create the Storage Classes, Execution Environments and Save Requests necessary to reflect the backup policy in the SBK file.
No attempt is made to consolidate the Storage Classes and Execution Environments, or to overlay the Save Requests for more optimum performance.
Before executing the command procedures to create the ABS Policy objects, you should try to consolidate Storage Classes and Execution Environments. Save Requests may be combined if warranted by the intended policy, but in some cases, breaking a Save Request into several is better for reducing nightly backup time, simplifying an overall backup policy, or backing up different objects at different intervals.
Consolidating the Storage Classes is done by comparing their parameters. For each pair of Storage Classes, you can determine whether they can be combined by using the table below. Note that in all cases, you can decide that one or the other parameter is correct for both, and consolidate based upon that decision.
Only the Administrator at a site can truly determine if two separate Storage Classes can be consolidated based upon the intended use of the Storage Class.
Consolidating Execution Environments is again done by comparing the parameters of pairs of Environments, and then combining those Environments if your decisions indicate they can serve the same purpose. Use the table below as a guide:
As with Storage Classes, only the Administrator at a site can truly determine if two separate Environments can be consolidated based upon the intended use of the Environment.
This section discusses the steps involved in implementing the ABS Policy as produced by the conversion utility and evaluated by the site Administrator.
After you have examined the raw output command files from the conversion utility and done what consolidation or modifications seem appropriate, the command files can simply be executed using the at-sign (@) operator at DCL. When each command procedure is invoked, it will:
There are several features of an SBK file which are not directly supported by ABS. The conversion utility creates a Prolog command file and an Epilog command file which implement some of these other features.
For example, ABS does not support the Offsite Date or Onsite Date in the SBK file directly. However, by issuing the appropriate STORAGE SET VOLUME command, this can be implemented. The conversion utility writes these commands into the Prolog or Epilog command files.
When the conversion utility produces a Prolog and Epilog command procedure, they will be created in the ABS$SLS_CONVERSION directory, and will be called, the same name as the Save Request, but will have "_PROLOG" or "_EPILOG" appended. For example, if you convert the NIGHTLY_SBK.COM,
you will end up with the Prolog and Epilog command files:
If you need the features implemented in the Prolog or Epilog command procedures, you should integrate these into your own Prolog and Epilog command procedures (if any). Both the Execution Environment and the Save Request may have Prolog and Epilog commands associated with them, which are usually the execution of a site-specific command procedure. If you want the features implemented in the Prolog or Epilog command procedures produced by the conversion utility, you should invoke them from your site-specific command procedure.
When executing an SBK file, SLS makes various DCL symbols accessible to the prolog and epilog command files you invoke. For example, SLS will define the DCL symbol DO_DISK as the name of the disk being backed up during an SBK execution. The objective is to allow the prolog or epilog commands to produce log messages, or perform other operations based upon the SBK file execution.
V2.2 of ABS provides logical names which provide similar functionality. These are fully documented in the V2.2 ABS documentation. For example, ABS defines the logical name ABS_OS_OBJECT_SET_1 as the set of files being backed up in the first data movement operation. Thus, it can be used in the place of the FILES_n symbol in an SBK file.
The conversion utility kit provides a command procedure, SLS_SYMBOLS.COM, which attempts to define many of the same DCL symbols as an SBK file does based upon the ABS logical names. For example, it defines the DO_DISK symbol based upon the ABS logical name ABS_OS_OBJECT_SET_1.
Please see the ABS$SLS_CONVERSION:SBK_SYMBOLS.COM command procedure for details on the definition of each SBK symbol. Not all SLS DCL symbols defined are supported by the command procedure.
It is very important to note that once you have executed the DCL Command procedures produced by the conversion utility, the ABS Save Requests will be executing according to their schedules. This means that you will be doing both SLS and ABS backups if you do not disable the SLS SBK files.
The SLS SBK files can be disabled by changing their DAYS_n and TIME_n qualifiers to empty. This causes SLS to no longer schedule the SBK files for execution.
If you want both SLS and ABS backups to run in parallel, you do not have to disable the SLS SBK files. SLS and ABS can coexist using the same MDMS volume database, the same tape drives, and so forth. However, realize that twice the backup time will be used, twice the tapes, and that ABS and SLS will contend for limited resources (such as network bandwidth or tape drives).
The conversion utility does not convert User Backup policy automatically. It is only intended to make converting SBK files easier or automatic.
To allow a particular user to do their own backups, follow the steps as outlined in Section 3.2.4. Note that there is no automatic way to set up Storage Classes for the entire user population, or a large set of users except by creating a DCL command procedure issuing the correct ABS DCL commands.
After implementing your backup policy in ABS, you should carefully monitor the activities of ABS until you are confident that your policy is being executed as intended.
There are three ways to monitor ABS activity:
$ SCHED SHO JOB *=ABS/BRIEF
ABS has the ability to restore data backed up by SLS. After you have implemented your backup policy using ABS, it may be necessary to restore data which was backed up using SLS prior to the conversion. Please see section 3.4.3 for more information on this capability.
$ @ABS$SYSTEM:SLS_CONVERT <wildcard_SBK_spec> [<match1>] [<match2>…]
This parameter identifies the set of SBK files to be converted by this command. The string given should not include SLS$SYSBAK: or the _SBK.COM suffix. For example, if you want to convert the SBK file SLS$SYSBAK:NIGHTLY*_SBK.COM, you should issue the command:
$ @ABS$SYSTEM:SLS_CONVERT NIGHTLY*
<match1> … <match7>
These optional parameters allow you to search the SBK files defined by the <wildcarded_SBK_spec> and only process those files which contain ALL of the given strings. The strings must all appear on the same line in the SBK file, since the SLS_CONVERT command procedure uses a /MATCH=AND on the Search command.
The output of the SLS_CONVERT conversion utility is one DCL command procedure for each SBK file processed. The command procedures will be created in the ABS$SLS_CONVERSION directory.
Each command procedure will be named the same as the SBK file, but substituting "ABS" for "SBK". For example, if the SBK file SYSTEM_DISK_SBK.COM is converted, the output command procedure will be ABS$SLS_CONVERSION:SYSTEM_DISK_ABS.COM.
Although the command procedures can be executed immediately, it is highly recommended that you review their contents before executing them to ensure that the ABS Policy objects which will be created accurately reflect your intended backup policy.
Each output command file will contain:
This table gives the ABS Storage Class object parameters and their SLS SBK Equivalents.
This table gives the ABS Execution Environment parameters and their SLS SBK Equivalents
This table gives the ABS Save Request parameters and their SLS SBK equivalents.