HP OpenVMS Systems

Content starts here
SLS to ABS conversion white paper

 

DIGITAL Equipment Corporation

Maynard, Massachusetts

 

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.2.6 Catalog

2.3 Media and Device Management

3. SLS and ABS Operation Overview

3.1 Scheduling

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 Cataloging

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 A. SBK Symbols in ABS Terminology…….………………………………………………..…27

Appendix B. ABS Policy Attributes in SBK Terminology….…………………………………………….30

  1. Executive Summary

 

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

 

    • Give a comparison of SLS and ABS System Backup Policy Management
    • Provide an overview of SLS and ABS System Backup Operations
    • Identify the Process for converting from SLS to ABS

 

This paper does NOT:

 

    • Give a general overview of SLS usage and capabilities
    • Give a general overview of MDMS media and device management
    • Include information about converting SLS Standby Archiving to ABS

 

    1. Why Convert from SLS to ABS?

 

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:

 

    • NT and UNIX Clients
    • Consolidated Policy Management
    • More Intuitive Policy Organization, with Shared Policies
    • Better Logging and Diagnostic Capabilities
    • Automatic Full and Incremental Operations
    • More versatile user-requested operations
    • On-Disk Backups
    • More versatile scheduling options

 

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.

      1. Consolidated Policy Management
      2.  

        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.

      3. More Intuitive Policy Organization

 

ABS Policy is organized into simple policy objects:

 

    • Storage Class objects contain information about where data is stored after it is backed up. This includes what type of media is used, how long the data is stored, and what access is allowed to the data.
    • Execution Environment objects contain information about how data is moved into and out of Storage Classes. This includes data safety options, the user profile under which the backup is performed, logging and listing options, and client file interlocking options.
    • Save Request objects contain information about what data is to be backed up and on what schedule. Multiple sets of disks, files or databases can be combined in a single Save Request. The scheduling options of ABS include schedule intervals, such as a Weekly Full backup with a Daily Incremental, or Log-based schedules.
    • Restore Request objects contain information about restoring data from a Storage Class. This includes what data to restore, and what selection criteria (such as before or after dates) to be used to select the data. ABS supports a "Full Restore" operation, through which both Full and Incremental restores of a disk or set of files are performed automatically.
    • Catalog objects contain information about what data is stored in the ABS Storage Classes. The Catalogs are used for generating reports on the content of Storage Classes, as well as to provide information for restoring files, disks or other data objects.
      1. Better Logging and Diagnostic Capabilities
      2.  

        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.

      3. UNIX and NT Clients
      4.  

        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.

      5. Automatic Full and Incremental Operations
      6.  

        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.

      7. More versatile User requested Operations
      8.  

        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.

      9. Disk Storage Classes

 

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.

  1. SLS and ABS System Backup Policy Overview

 

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:

 

    • What gets backed up
    • When it gets backed up
    • Where it gets backed up to
    • Who backs it up, and who can access the backed up data
    • How it gets backed up

 

    1. SLS Policy with ABS Equivalents
      1. System Backup Policy Configuration
      2.  

        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.

         

        Policy Component

        SBK Symbol(s)

        ABS Equivalent

        What gets backed up

        BACKUP_TYPE

        FILES_n

        NODE_n

        Save Request Include Specification(s) and Object Type

        When it gets backed up

        DAYS_n

        TIME_n

        Save Request Scheduling Option and Start Time

        Where it gets backed up to

        MEDIA_TYPE

        TAPE_POOL

        SCRATCH_DAYS

        DRIVE_TYPE

        Storage Class

        Who backs it up, and who can access the backed up data

        SLS

        PROTECTION

        Execution Environment User Profile, Storage Class ACL

        How it gets backed up

        QUALIFIERS

        QUALIFIERS_n

        PRIVS

        N_DRIVES

        Execution Environment

         

        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).

         

      3. Defining Your System Backup Policy
      4.  

        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.

      5. Restoring Data
        1. Selective File Restores
        2.  

          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.

        3. Full Restore Operations

         

        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.

         

      6. Media Management

       

      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.

    2. ABS Overview with SLS Equivalents
      1. Policy Configuration

 

In ABS, the Backup Policy is stored in five different types of policy objects:

 

    • Storage Classes
    • Execution Environments
    • Save Requests
    • Restore Requests
    • Catalogs

 

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.

      1. Storage Class
      2.  

        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.

         

        Storage Class Parameter

        SBK Equivalent

        Meaning

        Name

        CONTINUE

        A common name which can be referenced by multiple Save Requests

        Primary Archive Location

        <None>

        For on-disk backups, this gives the disk and top-level directory where the savesets will be stored.

        Primary Archive Type

        <None>

        This determines whether the Storage Class is tape-based (type is SLS/MDMS) or disk-based (type is FILES-11)

        Owner

        <None>

        Determines the NODE::USER of the owner of the Storage Class. The owner always has CONTROL access.

        ACL

        PROTECTION

        Determines the access to the backed up data. ABS provides full ACL-based access, while SLS provides only OpenVMS-style system, owner, group and world access.

        Pool

        TAPE_POOL

        The MDMS pool from which volumes will be allocated for backups.

        Type of Media

        MEDIA_TYPE

        The MDMS media type to be allocated for backups.

        Retain

        SCRATCH_DAYS

        The number of days the backed up data will be saved before the tapes are recycled. Note that a Save Request can specify a retention shorter or equal to the value in the Storage Class.

        Consolidation Criteria

        CONTINUE

        This set of parameters determines how backup savesets will be consolidated onto tapes. For example, if the Consolidation Interval is set to 7 days, savesets will be appended onto a volume set for 7 days before a new volume set is created.

        Catalog Name

        HISTORY_SET

        The name of the catalog which stores data about what files have been backed up, and where they are located.

        Number of Streams

        <None>

        The number of simultaneous Save requests which can be writing into the Storage Class. Determines the number of MDMS volume sets simultaneously active in the Storage Class.

        Media Location

        <None>

        The MDMS Location field to match for allocating volumes for backups.

        Drive List

        DRIVE_TYPE

        The list of specific drives to be used for backup operations in this Storage Class. Normally, this should be managed through MDMS Media Types.

         

      3. Execution Environment
      4.  

        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.

         

        Environment Parameter

        SBK Equivalent

        Meaning

        Name

        <None>

        Identifies the Environment for reference by Save Requests

        Owner and ACL

        <None>

        Identifies the owner and access to the Environment.

        Data Safety Options

        QUALIFIERS

        A bitmask containing the data safety options to be applied during the backup. Data safety options include CRC checking, and full data verification.

        Listing Options

        LISTING_GEN

        FULL

        Determines whether a listing file is produced, and whether the listing is a "full" listing or a "brief" listing.

        Span Filesystem Options

        <None>

        For UNIX file systems, determines whether the entire filesystem is backed up, even if it crosses multiple physical devices.

        Links Only

        <None>

        For UNIX file systems, determines whether ABS backs up only the logical links, or backs up the data as well.

        Compression Options

        <None>

        For UNIX file systems, determines the type of compression to be applied to the savesets.

        Original Object Action

        QUALIFIERS

        Determines the action to be taken on the original data objects (e.g. the files backed up). Options include None, Record Backup Date, or Delete

        User Profile

        PRIVS

        Determines the username, privileges and access rights used during the backup operation. The special keyword "<REQUESTER>" indicates the backup operations should be performed with the username, privileges and access rights of the person issuing the ABS Save Command.

        Notification Criteria

        REPLY_MSG

        STATUS_MAIL

        Determines when notification occurs, what method is used, and who is notified.

        Locking Options

        QUALIFIERS

        Determines how much interlocking is done between the backup in progress and an active file system. Options include Ignore File Writers, and Hot Backup.

        Number of Drives

        N_DRIVES

        Determines the number of tape drives to be used during the backup operations.

        Staging Option

        <None>

        Determines whether catalog entries are staged to a sequential file and then inserted into the actual catalog at a later time. This improves performance of the backup.

        Retry Interval and Count

        <None>

        Determines how often and how many times a failed backup should be retried.

        Prolog Command

        PRE_PROCESS_FIRST

        A command to be executed when the backup starts. Contrast to Save Request Prolog.

        Epilog Command

        POST_PROCESS_LAST

        A command to be executed when the backup completes. Contrast to Save Request Epilog.

         

         

      5. Save Request
      6.  

        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.

         

        Save Request Parameter

        SBK Equivalent

        Meaning

        Name

        SBK File name

        Identifies the group of backup operations to be performed.

        Movement Type

        QUALIFIERS

        Determines whether the operations are Full, Incremental or Selective (i.e. individual file) operations.

        Source Node

        NODE_n

        Node on which the data resides.

        Include Specification

        FILES_n

        Identifies the data to be backed up. Multiple include specifications can be given on a single Save Request, and each can have a different Source Node and Object Type.

        Object Type

        BACKUP_TYPE

        Gives the type of the data. ABS Supports many different types of data, including OpenVMS Files, UNIX Files, Oracle RDB Databases, and so forth.

        Agent Qualifiers

        QUALIFIERS

        Allows backup-agent specific qualifiers to be added to the command used to backup the data.

        Since and Before Date

        QUALIFIERS

        Determine whether data objects to be backed up should be selected based upon creation/modification date.

        Exclude Specification

        QUALIFIERS

        Determines selected data objects to be excluded from the backup.

        Storage Class Name

        CONTINUE

        Gives the name of the Storage Class into which the data is backed up.

        Environment Name

        <None>

        Gives the name of the Execution Environment to be used for the backup operations.

        Start Time

        TIME_n

        Indicates the time at which the Save Request should start each time it is scheduled. Note that although an SBK can provide multiple DAYS_n and TIME_n parameters, an ABS Save Request is restricted to a single Start Time and Interval.

        Schedule Options and Explicit

        DAYS_n

        Identifies the repeat interval for the Save Request. ABS provides a variety of pre-defined simple intervals, such as Daily, Weekly, Monthly, as well as several schedule intervals, such as Weekly Full with Daily Incremental, and log-based schedules. See the ABS documentation for full description of log-based schedules.

        Prolog Command

        PRE_PROCESS_EACH

        A command to be executed before each backup operation within the Save Request starts. Contrast to Environment Prolog.

        Epilog Command

        POST_PROCESS_EACH

        A command to be executed after each backup operation within the Save Request completes. Contrast to Environment Epilog.

         

         

      7. Restore Request
      8.  

        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.

         

        Restore Request Parameter

        Meaning

        Name

        Identifies the set of restore operations to be performed.

        Movement Type

        Identifies whether a Full, Incremental or Selective restore is performed. Note that when a Full restore is requested, ABS automatically applies the necessary Incremental restores to bring the restored data up-to-date.

        Source Node

        Gives the node where the data to be restored resided when it was backed up.

        Include Specification

        Identifies the disk, filesystem, set of files or other data objects to be restored. Multiple include specifications can be given in a single Restore Request, each with its own Object Type.

        Object Type

        Identifies the type of data to be restored.

        Agent Qualifiers

        Allows backup-agent specific qualifiers to be added to the command used to restore the data.

        Since and Before Date

        Determine that data objects as of a particular date should be restored. For example, specifying a Before Date of last Thursday would indicate that the most recent copy of the data before this date should be restored.

        Storage Class Name

        Gives the name of the Storage Class from which the data should be restored. The Storage Class identifies the catalog from which restore information is retrieved.

        Environment Name

        Gives the name of the Execution Environment to be used for the restore operations.

        Output Location

        Indicates the data should be restored to an alternate location. By default, ABS restores the data to its original location.

         

      9. Catalog

 

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:

 

Catalog Parameter

SLS Equivalent

Meaning

Name

SBK HISTORY_SET

TAPESTART HSTNAM_n

Gives the name of the catalog to be referenced by a Storage Class.

Type

System History or User History

Provides the type of information stored in the catalog. The type can be Brief, SLS or Full Restore catalog. The SLS Catalog type is provided to allow a Storage Class to retrieve information from SLS History sets.

Owner

<None>

Determines the Owner of the catalog. The Owner has full access to the catalog.

Use Staging

Default behavior for SLS history files

Determines whether catalog entries are staged to a sequential file during the backup, and inserted in the actual catalog at a later time.

 

 

 

    1. Media and Device Management

 

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.

  1. SLS and ABS Operation Overview
  2.  

    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.

    1. Scheduling
      1. SBK Symbols for Scheduling

 

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:

 

    • A list of day names
      • Example: MONDAY, WEDNESDAY, FRIDAY
    • A day offset within the month
      • Example: MONTH + 2 (second day of the month)
      • Example: MONTH - 10 (10 days before the end of the month)
    • A day within a week offset within a month
      • Example: MONTH + 2 * THURSDAY (second Thursday of the month)
      • Example: MONTH - 2 * Sunday (two Sunday before the end of the month)

 

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.

      1. ABS Use of POLYCENTER Scheduler

 

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:

 

    • One-time only (the Save Request is removed after 72 hours)
    • On demand (run with an explicit SCHEDULE RUN command)
    • Daily
    • Weekly
    • Bi-Weekly
    • Monthly
    • Quarterly
    • Semi-Annually
    • Daily with Weekly Full
    • Log-based schedules

 

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.

    1. Types of Operations
    2.  

      This section discusses the various types of operations performed by SLS and/or ABS, and identifies similarities and differences between the two products.

      1. System Backups

 

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:

 

    • It is always executed using the SLS account, with the privileges identified by the PRIVS symbol.
    • The type of the backup is identified in the QUALIFIERS symbol (or QUALIFIERS_n). For example, if /IMAGE is included in QUALIFIERS, this indicates a full, image backup of the disk should be performed. In addition, the QUALIFIERS symbol provides many of the operational characteristics of the backup, such as whether to do a record pass, whether to ignore file writers, and so forth.
    • SLS Executes the SBK file by submitting a Batch job, which then runs a command procedure called SYSBAK.COM. This command procedure is responsible for executing the SBK file, allocating tape drives, mounting volumes, and so forth.
    • The actual backup operations are performed using OpenVMS Backup or Oracle RMU Backup, based upon the backup type specified by the BACKUP_TYPE symbol. These utilities are executed in a subprocess created by SYSBAK.COM, which then communicate to SYSBAK via mailboxes, or pseudo-terminals in the case of Oracle RMU backup.
    • The actual backup operations are run using a utility called SLS$SYSBAK.EXE. This utility creates the subprocesses to house OpenVMS or Oracle RMU backup, and communicates via mailboxes.
    • The log file created in SLS$SYSBAK_LOGS gives the whole output of the execution of SYSBAK.COM.
    • Many functions in SLS are provided by "DCL Utilities". These are images which are executed from SYSBAK.COM to perform functions such as sending mail, opening and reading mailboxes, mounting tapes, and so forth.
    • Some of the tape, robot and drive operations performed during an SLS system backup are performed by SYSBAK.COM via "DCL Utilities", while others are performed in the SLS$SYSBAK image itself. This can cause inconsistencies in the way that load requests are handled depending on where in the backup operation the request is issued.
    • The history-set entries for each saveset created and each file backed up during the System Backup operation are written to a temporary file. After the System Backup completes, a batch job is created, which runs SYS$SBUPDT.EXE (System Backup Update). This utility moves the history set entries from the temporary file into the actual SLS History Files.

 

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:

 

    • It is run using the User Profile of the ABS account.
    • The type of the backup is given on the Save Request, in combination with the scheduling option if a scheduling interval option was chosen. For example, if the "Daily with Weekly Full" scheduling option was chosen, ABS will automatically decide whether to do a FULL or INCREMENTAL backup on any particular day.
    • The Save Request is run using a POLYCENTER Scheduler job. The Scheduler job is executed on the interval specified by the Save Request, and always runs under the ABS account.
    • The Scheduler job runs a program called the ABS Coordinator. It is called this because it coordinates the execution of a Save Request. As it’s command-line parameter, the ABS Coordinator is given the UID (Universal Identifier) of the Save Request to be executed.
    • The ABS Coordinator retrieves the Save Request and its associated Storage Class and Execution Environment from the Policy Database. This may require a network connection if the Policy Database is on another node.
    • The ABS Coordinator then allocates volumes (if necessary) and loads tapes using the Media and Device Management Services. The parameters for these tape operations come from the Storage Class.
    • Once tapes are accessed, the Coordinator then creates multiple "Data Mover" threads to execute each backup operation specified by the Save Request. Each Data Mover then creates a subprocess to hold the backup agent for the given backup operation.
    • The actual backup operations are performed by ABS using "Backup Agents". ABS Supports many different Backup Agents, including OpenVMS Backup, Oracle RMU Backup, and gtar in the case of UNIX and Microsoft Windows/NT clients.
    • During each backup operation, the Catalog entries for each operation performed and each data object backed up are either written directly to the Catalog, or are staged into a temporary staging file. After the Save Request completes, the staged entries are moved into the actual ABS Catalog using a detached process.

 

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:

 

    • ABS Save Requests are run using POLYCENTER Scheduler, while SLS SBK files are executed using an SLS-specific Batch job.
    • ABS System Backups execute under the ABS account, while SLS SBK files execute under the SLS account.
    • ABS Save Requests are coordinated using a program called the Coordinator, which provides good error reporting and recovery, as well as consistent tape management and logging. SLS uses SYSBAK.COM, which is a potentially confusing command procedure.
    • The policy to be executed by ABS is retrieved from a central Policy Database, while the SLS SBK file is executed locally, and the SBK Symbols are used accordingly. ABS Save Requests can share Storage Classes or Environments.
    • ABS supports many different Backup Agents, while SLS supports just OpenVMS Backup and Oracle RMU Backup.
    • ABS provides optional catalog staging, while SLS system backups always require staging.
    • The ABS Log Files are clearer and easier to understand than the SLS log files.

 

 

      1. Full and Incremental Operations

 

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:

 

    • Daily with Weekly Full
    • LOG-2
    • Log-3

 

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: -

/Name=NIGHTLY_BACKUPS -

/Start="18:00" -

/Schedule=LOG-2 -

/Storage=SYSTEM_BACKUPS

 

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.

      1. Selective Operations
      2.  

        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.

         

      3. User-requested Operations

 

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:

 

    • It is normally requested by a user
    • The tapes used for the backup are owned by the user

 

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:

 

/ACCESS=(USER=*::*,ACCESS="READ+WRITE")

 

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:

 

    1. Create an MDMS Pool for the user. This limits the volumes the user is able to use for their personal backups. This step is not required if you wish to allow users to share a pool of tapes.
    2. Create a personal catalog for the user using the ABS_CATALOG_OBJECT utility. If desired, you can move the catalog files to the user’s directory, then redefine the ABS$CATALOG logical name to include that user’s directory. Note that access to the catalog is through the Storage Class, created below.
    3. Create an ABS Storage Class for the user, identifying the Owner as the user, and granting the user full access via the ACL. Specify the correct pool and catalog, as created above. Deny access to other users.
    4. Create an ABS Execution Environment for the user, or let it default to the DEFAULT_ENV object provided by the ABS Installation Kit. The User Profile in the Environment must indicate the keyword "<REQUESTER>" in the user profile as the user under which the backup operations are performed.
    5. Notify the user of their Storage Class Name. This Storage Class should be included on all of the user’s ABS Save commands using the /STORAGE qualifier.
    1. Tape, Robot and Device Management

 

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:

 

      1. Volume Set 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:

 

    • Consolidation Interval - the number of days data will be appended to the volume set
    • Consolidation Size - the maximum number of volumes in the volume set
    • Consolidation Count - the maximum number of savesets to append to the 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.

 

 

      1. Consistency of Volume and Drive Management

 

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.

    1. Cataloging
    2.  

      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.

      1. SLS History Sets
      2.  

        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.

      3. ABS Catalogs
      4.  

        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.

      5. Restoring data with ABS from SLS History Sets

 

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:

 

    1. Create an ABS Catalog with the type of SLS. This is done using the ABS_CATALOG_OBJECT utility, as follows:
    2.  

      $ 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.

       

    3. Create a read-only Storage Class in ABS which references the SLS-type catalog. The Storage Class should be read-only, since SLS History Sets can only be used for restores.
    4. Issue ABS Lookup or ABS Restore commands using the Storage Class created above. The SLS History Set will be used for the lookup or restore.

 

NOTE: You must have the ABS_LOOKUP_ALL access right granted to your account to display entries in the SLS History Files from ABS.

 

  1. Conversion Process
  2.  

    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.

    1. Steps for Conversion
    2.  

      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.

      1. Determine your use of SLS

 

The first step in converting from SLS to ABS is to identify how you use SLS. There are three major uses of SLS:

 

    • System Backups
    • Standby Archiving
    • User Backups

 

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:

 

    • "Archive Classes" are created by the System Administrator
    • When users request a Save, they indicate the Archive Class on their Save request, but the request is only queued, it is not executed immediately or scheduled.
    • At some point in time, the system Operator starts a "standby archive session" for each Archive Class
    • SLS then mounts the tape associated with the Archive Class, and appends any requests queued since the last session to the tape.
    • Until the Operator stops the session, the tape sits on the drive waiting for more requests to come in.
    • When the Operator stops the session, the tape is dismounted and requests go back to being queued.

 

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.

      1. Converting SLS System Backups to ABS
      2.  

        This section describes how to convert SLS System Backups (SBK files) into ABS Policy.

        1. Determine valid SBK files

 

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:

 

    1. They are scheduled regularly by SLS
    2. They are manually executed by you or the Operator

 

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).

        1. Convert the Valid SBK Files to ABS Policy
        2.  

          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

           

          or

           

          $ @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

        3. Evaluate the ABS Conversion Command Files

 

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:

 

    • comments explaining the conversion process
    • ABS DCL Commands to create ABS Policy Objects
    • A Prolog and Epilog command to complete the functions performed by the SBK file

 

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:

 

    • Naming conventions used in the conversion may not be what you want
    • Errors in converting the SBK policy
    • Possible ABS Policy Consolidation

 

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.

 

 

        1. Naming Conventions Used

 

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:

 

    • There are more than one FILES_n is specified
    • The QUALIFIERS_n differ in the type of operation
    • More than eight include specification are found in a single SBK file

 

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.

 

        1. Consolidate the ABS Policy Objects
        2.  

          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.

           

        3. Consolidating Storage Classes
        4.  

          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.

           

          Storage Class Parameter

          Matching Criteria

          Name

          Doesn’t matter – choose meaningful name

          Media Type

          Should match

          Tape Pool

          Should match

          Media Location

          Should match

          Access Control

          OK if different – choose best for intended Storage Class use

          Owner

          Should both be ABS

          Retention

          OK if different – choose best for intended Storage Class use

          Volume Set Name

          Not set, doesn’t matter

          Consolidation Criteria

          OK if different - choose best for intended Storage Class use

          Catalog name

          OK if different

          Number of Streams

          Always set to 1 from Conversion utility

          Execution Node

          Should match

          Drive name

          OK if different - choose best for intended Storage Class use

           

          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.

           

        5. Consolidating Execution Environments
        6.  

          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:

           

          Environment Parameter

          Matching Criteria

          Name

          Doesn’t Matter – choose meaningful name

          Data Safety options

          OK if different – choose best for intended Environment’s use

          Listing options

          OK if different – DIGITAL recommends not producing listings

          Span FileSystems

          Should Match

          Links Only

          Should Match

          Original object action

          Should Match

          User Profile

          Will always be ABS from conversion utility, choose PRIVILEGES best for intended Environment’s use

          Notification

          OK if different – choose best for intended Environment’s use

          Locking options

          Should match

          Number of drives

          OK if different – choose best for intended Environment’s use

          Retry options

          OK if different – choose best for intended Environment’s use

          Prolog and Epilog

          Should match, or be combined

           

          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.

           

        7. Implement the ABS Policy
        8.  

          This section discusses the steps involved in implementing the ABS Policy as produced by the conversion utility and evaluated by the site Administrator.

           

           

          1. Executing the Command Procedures

 

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:

 

    • Create a Storage Class
    • Create an Execution Environment
    • Create one or more Save Requests and associated Scheduler jobs
    • Possibly create a Prolog command procedure
    • Possibly create an Epilog command procedure

 

          1. Integrating the Prolog and Epilog Commands
          2.  

            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:

             

            ABS$SLS_CONVERSION:NIGHTLY_ABS_PROLOG.COM

            ABS$SLS_CONVERSION:NIGHTLY_ABS_EPILOG.COM

             

            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.

            1. SBK Symbols and ABS Logicals

             

            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.

             

             

          3. Disable the SLS SBK Files

 

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).

      1. Converting User Backup policy
      2.  

        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.

         

      3. Monitor the ABS Activity

 

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:

 

    • Show the Scheduler jobs associated with ABS Save Requests. A failed job will be indicated with an asterisk (*) by the job name. You can show all ABS jobs in Scheduler by issuing the command:

 

$ SCHED SHO JOB *=ABS/BRIEF

 

    • Set up Notification criteria on the Execution Environments to send you mail when ABS operations complete. The mail will contain the name of the job and the final status.
    • Examine the ABS Log files. All ABS Log files are created in the ABS$LOG: directory, and are called the same name as the Save Request.
    • For catalog operations:
      • Monitor the Staging Log files
        • These are named ABS$LOG:<catalog_name>_<stream>.LOG
      • Monitor the Catalog cleanup log files
        • These are named ABS$LOG:ABS_CLEAN_CATLG_<node>.LOG
    • Monitor the Policy Engine Log files on your Central Security Domain (CSD)
      • ABS$ROOT:[000000]ABS$START_POLICY_ENGINE.LOG
      • ABS$LOG:ABS_CLEAN_DB_UTIL.LOG

 

      1. Restoring from SLS History Sets

 

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.

  1. Conversion Utility Reference
    1. Command Syntax
    2.  

      $ @ABS$SYSTEM:SLS_CONVERT <wildcard_SBK_spec> [<match1>] [<match2>…]

       

      <wildcard_SBK_spec>

      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.

    3. Output Command File naming and contents

 

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:

 

    • A block of comments indicating that the file was produced by the conversion utility, and the date and time of the conversion.
    • The name of the SBK file represented in the command file
    • The list of SBK parameters which are not handled by the conversion utility, and the reason they are not.
    • An ABS Create Storage command to create a Storage Class.
    • An ABS Create Environment command to create an Execution Environment.
    • One or more ABS Save commands and ABS Set Save commands to create Save Requests.
    • The creation of a Prolog command file. The Prolog command file should be integrated with any site-specific prolog command files to complete the functions defined by the SBK.
    • The creation of an Epilog command file. The Epilog command file should be integrated with any site-specific epilog command files to complete the functions defined by the SBK.
  • SBK Symbols in ABS Terminology
  •  

    SBK Symbol

    ABS Equivalent

    Meaning

    DAYS_n

    Save Request /SCHEDULE and /EXPLICIT

    Defines how often the backup operations are performed

    TIME_n

    Save Request /START_TIME

    Defines when the backup operation starts

    NODE_n

    Save Request /SOURCE_NODE

    Defines the node in your network where the data resides

    BACKUP_TYPE

    Save Request /OBJECT_TYPE

    Defines the type of data to be backed up or restored.

    PRE_PROCESS_FIRST

    Environment /PROLOG

    Defines a command to be executed when the backup job starts

    PRE_PROCESS_EACH

    Save Request /PROLOG

    Defines a command to be executed prior to each backup operation within a job

    POST_PROCESS_EACH

    Save Request /EPILOG

    Defines a command to be executed when each operation within a job finishes

    POST_PROCESS_LAST

    Environment /EPILOG

    Defines a command to be executed when the backup job completes.

    NEXT_JOB

    POLYCENTER Scheduler dependencies

    Defines what job to run next after the current job completes

    SUMMARY_FILE

    ABS REPORT SAVE/FULL and ABS Catalogs

    Gives overview information about a save operation in a job.

    PRIVS

    Environment /PROFILE=(PRIVS)

    Defines the set of privileges to be used when executing the operation

    FILES_n

    Save Request Include Specification

    Defines the set of files or other data objects to be backed up or restored.

    QUALIFIERS and

    QUALIFIERS_n

    Environment /ACTION, /LOCK and /DATA_SAFETY

    Save Request /FULL/SINCE=BACKUP /SELECT

    Defines characteristics of the save operation, such as the type of data movement, and options for execution of the backup.

    MNTFLAGS

    Not supported. ABS controls mounting of tapes.

    Defines how tapes are mounted.

    SAVESET_GEN

    Not supported. ABS generates the saveset names.

    Defines the name of the saveset stored on tape.

    PROTECTION

    Storage Class /ACCESS

    Defines what access is available to the backed up data.

    MEDIA_TYPE

    Storage Class /TYPE_OF_MEDIA

    Defines which MDMS media type is to be used for backup operations.

    DENSITY

    Not supported. ABS expects the MDMS media type, pool, or location to reflect the desired density.

    Defines the tape density to be used for backup operations.

    REEL_SIZE

    Not supported. ABS expects the MDMS media type, pool or location to reflect the desired reel size.

    For 9-track tapes, defines the length of the tape (e.g. 2400 feet)

    TAPE_POOL

    Storage Class /TAPE_POOL

    Defines the MDMS pool from which tapes are drawn for backup operations.

    QUICKLOAD

    ABS conforms to the definition of QUICKLOAD in TAPESTART. This cannot be changed on a per-operation basis.

    Determines whether MDMS will automatically recognize when a tape drive comes online without operator intervention.

    QUICKLOAD_RETRIES

    Logical Name:

    ABS$<sc_name>_LOAD_TIMEOUT

    defined in seconds.

    Defines how long a LOAD request should remain outstanding before being canceled.

    PREALLOC

    ABS allocates and manages volume sets automatically.

    Determines the number of volumes to pre-allocate before a backup begins, forming them into a volume set.

    AUTOSEL

    ABS always automatically selects new volumes to append to volume sets, if needed.

    Determines whether SLS is allowed to automatically select new volumes from the volume database if needed.

    CONTLOADOPT

    Logical Name:

    ABS$DISABLE_SCRATCH_LOADS set to one. By default, ABS will request and accept scratch tapes. The logical can be defined to force specific tapes to be mounted.

    Determines whether the operator can substitute a valid tape for the requested tape.

    UNATTENDED_BACKUPS

    ABS always attempts to perform the backup without operator intervention.

    Determines whether SYSBAK should default responses to questions rather than require operator intervention.

    CONTINUE

    ABS Storage Class Name. Each Storage Class manages one or more volume sets, and appends data to these volume sets until the Consolidation Criteria is exceeded.

    Determines how data is consolidated onto volume sets.

    HISTORY_SET

    Catalog Name

    Storage Class /CATALOG

    Determines the catalog into which a record of the operations performed and the files backed up is written.

    SBUPDT_Q

    Not supported. If a catalog supports staging, ABS always performs the catalog update in a detached process.

    Determines the Batch Queue in which the System history set update is performed.

    SCRATCH_DAYS

    Storage Class /RETAIN

     

    Determines how long data is saved before the tapes are recycled and catalog entries removed.

    OFFSITE_DATE

    ONSITE_DATE

    Not directly supported. The utility SLS_CONVERT will create an epilog command which issues the appropriate STORAGE SET VOLUME commands necessary.

    Determines when the volume sets are moved offsite or onsite (i.e. vaulting).

    TAPE_LABELS

    Not directly supported. The utility SLS_CONVERT will write an epilog command procedure to issue a STORAGE LABEL command.

    Determines if paper labels are printed for the volumes used in the backup

    NOTES

    Not directly supported. The utility SLS_CONVERT will write an epilog command procedure to issue a STORAGE SET VOLUME command.

    Store a free-form text note in the volume record for the volumes used in the backup.

    DRIVE_TYPE

    Storage Class /DRIVE_LIST

    Determines the list of tape drives to be used. It is recommended that MDMS media types be set up correctly rather than using this field.

    N_DRIVES

    Environment /DRIVE_COUNT

    Determines the number of tape drives to use during a backup operation.

    PROGRESS

    Not supported

    Notifies the operator after a certain number of files have been backed up.

    REPLY_MSG

    Environment /NOTIFY

    SLS_CONVERT epilog command.

    Determines the notification to be performed when each backup operation starts and ends.

    STATUS_MAIL

    Environment /NOTIFY

    Determines who should be sent MAIL when the job completes.

    LOG_FILE

    Not supported. ABS generates a log file in ABS$LOG with the same name as the Save Request.

    Determines the name of the log file for the operation.

    LISTING_GEN

    Environment /LISTING. ABS will generate listing files, but they are always located in ABS$LISTINGS, and are named the same as the Save Request and the operation number.

    Determines the name of a backup listing file to be produced from each operation.

    FULL

    Environment /LISTING=FULL

    Determines if the listing file provides all information about backed up files, or only brief information.

    PRINT_Q

    Not supported.

    Determines the Print queue on which the listing file is printed.

     

  • ABS Policy Attributes in SBK Terminology
  •  

    This table gives the ABS Storage Class object parameters and their SLS SBK Equivalents.

     

    Storage Class Parameter

    SBK Equivalent

    Meaning

    Name

    CONTINUE

    A common name which can be referenced by multiple Save Requests

    Primary Archive Location

    <None>

    For on-disk backups, this gives the disk and top-level directory where the savesets will be stored.

    Primary Archive Type

    <None>

    This determines whether the Storage Class is tape-based (type is SLS/MDMS) or disk-based (type is FILES-11)

    Owner

    <None>

    Determines the NODE::USER of the owner of the Storage Class. The owner always has CONTROL access.

    ACL

    PROTECTION

    Determines the access to the backed up data. ABS provides full ACL-based access, while SLS provides only OpenVMS-style system, owner, group and world access.

    Pool

    TAPE_POOL

    The MDMS pool from which volumes will be allocated for backups.

    Type of Media

    MEDIA_TYPE

    The MDMS media type to be allocated for backups.

    Retain

    SCRATCH_DAYS

    The number of days the backed up data will be saved before the tapes are recycled. Note that a Save Request can specify a retention shorter or equal to the value in the Storage Class.

    Consolidation Criteria

    CONTINUE

    This set of parameters determines how backup savesets will be consolidated onto tapes. For example, if the Consolidation Interval is set to 7 days, savesets will be appended onto a volume set for 7 days before a new volume set is created.

    Catalog Name

    HISTORY_SET

    The name of the catalog which stores data about what files have been backed up, and where they are located.

    Number of Streams

    <None>

    The number of simultaneous Save requests which can be writing into the Storage Class. Determines the number of MDMS volume sets simultaneously active in the Storage Class.

    Media Location

    <None>

    The MDMS Location field to match for allocating volumes for backups.

    Drive List

    DRIVE_TYPE

    The list of specific drives to be used for backup operations in this Storage Class. Normally, this should be managed through MDMS Media Types.

     

     

    This table gives the ABS Execution Environment parameters and their SLS SBK Equivalents

     

    Environment Parameter

    SBK Equivalent

    Meaning

    Name

    <None>

    Identifies the Environment for reference by Save Requests

    Owner and ACL

    <None>

    Identifies the owner and access to the Environment.

    Data Safety Options

    QUALIFIERS

    A bitmask containing the data safety options to be applied during the backup. Data safety options include CRC checking, and full data verification.

    Listing Options

    LISTING_GEN

    FULL

    Determines whether a listing file is produced, and whether the listing is a "full" listing or a "brief" listing.

    Span Filesystem Options

    <None>

    For UNIX file systems, determines whether the entire filesystem is backed up, even if it crosses multiple physical devices.

    Links Only

    <None>

    For UNIX file systems, determines whether ABS backs up only the logical links, or backs up the data as well.

    Compression Options

    <None>

    For UNIX file systems, determines the type of compression to be applied to the savesets.

    Original Object Action

    QUALIFIERS

    Determines the action to be taken on the original data objects (e.g. the files backed up). Options include None, Record Backup Date, or Delete

    User Profile

    PRIVS

    Determines the username, privileges and access rights used during the backup operation. The special keyword "<REQUESTER>" indicates the backup operations should be performed with the username, privileges and access rights of the person issuing the ABS Save Command.

    Notification Criteria

    REPLY_MSG

    STATUS_MAIL

    Determines when notification occurs, what method is used, and who is notified.

    Locking Options

    QUALIFIERS

    Determines how much interlocking is done between the backup in progress and an active file system. Options include Ignore File Writers, and Hot Backup.

    Number of Drives

    N_DRIVES

    Determines the number of tape drives to be used during the backup operations.

    Retry Interval and Count

    <None>

    Determines how often and how many times a failed backup should be retried.

    Prolog Command

    PRE_PROCESS_FIRST

    A command to be executed when the backup starts. Contrast to Save Request Prolog.

    Epilog Command

    POST_PROCESS_LAST

    A command to be executed when the backup completes. Contrast to Save Request Epilog.

     

     

    This table gives the ABS Save Request parameters and their SLS SBK equivalents.

     

    Save Request Parameter

    SBK Equivalent

    Meaning

    Name

    SBK File name

    Identifies the group of backup operations to be performed.

    Movement Type

    QUALIFIERS

    Determines whether the operations are Full, Incremental or Selective (i.e. individual file) operations.

    Source Node

    NODE_n

    Node on which the data resides.

    Include Specification

    FILES_n

    Identifies the data to be backed up. Multiple include specifications can be given on a single Save Request, and each can have a different Object Type.

    Object Type

    BACKUP_TYPE

    Gives the type of the data. ABS Supports many different types of data, including OpenVMS Files, UNIX Files, Oracle RDB Databases, and so forth.

    Agent Qualifiers

    QUALIFIERS

    Allows backup-agent specific qualifiers to be added to the command used to backup the data.

    Since and Before Date

    QUALIFIERS

    Determine whether data objects to be backed up should be selected based upon creation/modification date.

    Exclude Specification

    QUALIFIERS

    Determines selected data objects to be excluded from the backup.

    Storage Class Name

    <None>

    Gives the name of the Storage Class into which the data is backed up.

    Environment Name

    <None>

    Gives the name of the Execution Environment to be used for the backup operations.

    Start Time

    TIME_n

    Indicates the time at which the Save Request should start each time it is scheduled. Note that

    an SBK can provide multiple DAYS_n and TIME_n parameters, an ABS Save Request is restricted to a single Start Time and Interval.

    Scheduling Option and Explicit

    DAYS_n

    Identifies the repeat interval for the Save Request. ABS provides a variety of pre-defined simple intervals, such as Daily, Weekly, Monthly, as well as several schedule interval options, such as Weekly Full with Daily Incremental, and log-based schedules. See the ABS documentation for full description of log-based schedules.

    Prolog Command

    PRE_PROCESS_EACH

    A command to be executed before each backup operation within the Save Request starts. Contrast to Environment Prolog.

    Epilog Command

    POST_PROCESS_EACH

    A command to be executed after each backup operation within the Save Request completes. Contrast to Environment Epilog.