Previous section.

Systems Management: Backup Services API (XBSA)
Copyright © 1998 The Open Group

Backup and Archive Architecture

This chapter presents a general architecture of a backup and restore environment to serve as a framework for discussing the Open Backup Services API functions in the next chapter.

In the course of describing this architecture, examples or scenarios will be given to illustrate the use of the XBSA interfaces. These examples are not intended to imply the only use of XBSA. The XBSA architecture was designed to permit a wide flexibility of use.

An overview of the general roles and responsibilities for backup and archive operations is provided in Architectural Overview , Backup and Archive Operations , Open Backup Services API , and XBSA Applications . The remaining sections of this chapter then introduce the terminology and descriptions of the XBSA model necessary to understand the API presented in the subsequent chapters.

Architectural Overview

Context for XBSA Interfaces shows a high-level view of this architecture, identifying the major components and highlighting the Open Backup Services API (XBSA). The functions provided by these components are described in turn below.
Figure: Context for XBSA Interfaces

Except for the specification of the XBSA Data Movement API, there are no internal or external interfaces specified for any of these components. For example, the user interfaces (Administrator Role or Client Role) are defined by the application developers, and the interfaces between a Backup Service and a particular catalog are left to the implementor of a particular Backup Service.

Design choices which pertain to trade-offs on performance, storage consumption or availability (reliability) are implementation decisions outside the scope of XBSA.

Any Backup Service implementation could have Private Management Routines (administrative interfaces) which are not visible to users through the Open Backup Services API. A specific Backup Service implementation may also have components not shown in Context for XBSA Interfaces , such as an Index Manager, a Storage Manager, a Hierarchy Manager, a Log Manager, or a Communication Manager. Depending on the particular system configuration environment, certain system services may be used to support some of these components.

Furthermore, not indicated in Context for XBSA Interfaces , a Backup Service implementation may be either local to a single system node or distributed across multiple system nodes.

The API Definitions defined in Backup Services API Definitions comprise the XBSA Data Movement API. Through the use of these functions, the XBSA Application may use the data repository functions of a particular Backup Service.

Backup and Archive Operations

Through this API, one or more data objects may be backed up (that is, a backup copy of each object is created in the Repository controlled by the Backup Service). They can then be subsequently restored if the original objects become corrupted or lost due to storage or system failure, or to human error.

Similarly, one or more data objects may be archived (that is, an archive copy of each object is created in the Repository controlled by the Backup Service). This permits long-term, often low-usage, storage so as to reduce the storage cost. Machine-assisted management of these archived objects is facilitated, such that they can be subsequently retrieved when they are needed again.

Backup operations are frequently repetitive and tedious. Applications may provide a facility to support automated backup and to generate logs or reports. Thus XBSA expects that the XBSA Application (not the Backup Service) will actually initiate and control the data transfer functions.

Although Backup/Restore functions are operationally similar to Archive/Retrieve functions, they differ in their usage and requirements. This is primarily a user distinction relating to the way in which the XBSA API is used, rather than reflecting any specific features within the API itself.

The following discussion elaborates on these differences:

Open Backup Services API

Backup services are offered through a source-code Open Systems Backup Services API (XBSA) using a synchronous call interface. The structure of the calls is system-independent and application-independent.

The underlying part of the architecture that supports XBSA is called the Backup Service. The users of this API are collectively called XBSA Applications, which refers to both the dedicated management applications (XBSA Manager) and typical user applications which make use of the Backup Service (XBSA Client).

The end-users who backup/restore their data objects (User Role) or manage the Backup Service (Administrator Role) through XBSA use interfaces which are outside the scope of this Technical Standard.

At any point in time, a single Backup Service may support multiple XBSA Managers and multiple XBSA Clients, and a single XBSA Client that uses multiple processes can have concurrent calls through XBSA to the Backup Service.

Multiple Backup Service implementations can potentially exist on a single platform. Since the association of a particular XBSA Application to a particular Backup Service is dependent on which library of source code interfaces is used, the static or dynamic binding of executable modules determines which Backup Service is invoked. It should be noted that an XBSA Application in a single process can only interact with a single Backup Service at a time.

XBSA Applications

An XBSA Client makes use of certain Backup Services for specific applications or end-user services. Examples of these are a UNIX file system, a document management system, a database management system (DBMS), an information retrieval (IR) system, or a cache manager.

An XBSA Manager is also an end-user application, but it is distinguished in that its primary role is to provide management of services for an application through XBSA. This XBSA Manager may be provided by the vendor of the Backup Service, or an independent vendor may create a more universal manager. In either case, the Backup Service vendor could have private management interfaces (Private Management Routines) which are not defined in this Technical Standard.

An XBSA Client interacts with specific applications to access their Application Objects which they manage (for example, files, directories, byte streams). It then constructs suitable XBSA Objects from the application objects for backup/archive, calls the Open Backup Services API, reconstructs the application objects from restored/retrieved XBSA Objects, maintains a backup/archive log for the application it interacts with, engages a scheduler to automate deferred or periodic backup tasks, and possibly provides a customized end-user interface (graphical or command-line) to support interactive operations.

An XBSA Client also understands the requirements of the specific application, the format and relationships of the application objects, and the semantics of backup/archive (including incremental backup and consistency requirements). It may handle attribute extraction, data conversion, mappings of application objects to XBSA Objects (which do not have to be one-to-one), object packing, compression/decompression, encryption/decryption, constraint enforcement, and/or application-specific access control. It may itself support a distributed environment, such as interacting with a distributed file system or supporting a remote end-user interface via RPC calls.

The precise semantics of backup and restore for any application, and in particular the notion of incremental backup, is application-dependent and thus must be handled by a suitable XBSA Client. For example, the incremental backup of a file system directory (as a named set of files) may mean the backing up of the changes to the directory since the last backup was performed. These changes could include all the modified and newly created files in the directory, as well as all the file deletions.

On the other hand, an incremental backup of a large, continually appended log file may mean the backing up of all the appends added since the last backup. An incremental backup of a database may mean the backing up of only the modified pages in the database.

XBSA Session

An XBSA session is a logical connection between an XBSA Application and a Backup Service implementation. A session begins with a call to BSAInit() and ends with a call to BSATerminate(). Nested sessions, and multiple sessions in the same address space, are not supported in this version of the Technical Standard.

Every XBSA session between a particular XBSA Application and Backup Service uses a bsa_ObjectOwner, which is registered with the Backup Service and used by Backup Service to control access to the objects it manages. This bsa_ObjectOwner is a fixed-length character string. No specific format is required (that is, it may be a combination of a node name and resource manager name, or a globally unique name associated with a distributed resource manager). Different instances of an XBSA Application may or may not use the same bsa_ObjectOwner. The bsa_ObjectOwner is authenticated for each session.

XBSA Objects and Object Names

This Open Backup Services API uses an object-based paradigm. Every data object visible and transferred at the XBSA interface is an XBSA Object, which is not to be confused with the Application Object shown in Context for XBSA Interfaces . The latter is an object managed by an application or service, and is the original source object which is to be backed up or archived.

Hierarchical Character Strings

A hierarchical character string has one or more components or fields, separated by a user-specifiable delimiter character (specified in the Backup Service-dependent Environment structure). Each component is a variable-length character string, and there is a length limit for the entire string. However, there is no restriction on the number of components (levels) a string can have. Two consecutive delimiters specify an empty level. A leading delimiter indicates an empty top level.

A hierarchical character string is interpreted one component at a time starting with the first component and ending whenever a resolution is made. For example, when comparing two strings, interpretation ceases whenever a distinction, or relative ordering, between the strings is determined. The delimiter character is implementation dependent and should be queried using BSAGetEnvironment().

Hierarchical strings facilitate the aggregation and segregation of objects, and may be used syntactically and structurally for object grouping, filtering, or selection. However, the semantics of a hierarchical name, including any naming constraints, is totally application-dependent, and unknown to the Backup Service.

A limited wild card capability is provided, see BSAQueryObject().

XBSA Object Naming

An XBSA Object has a two-part name: BSA_ObjectOwner, and BSA_ObjectName, which is summarized in Structure of an XBSA Object Name .
Figure: Structure of an XBSA Object Name

The BSA_ObjectOwner is the name of the owner of the object and consists of two parts: bsa_ObjectOwner, and app_ObjectOwner. The BSA_ObjectName is the name assigned by the XBSA Application. It also consists of two parts: objectSpaceName, and pathName. The details of the data structures are defined in Type Definitions and Data Structures .

As neither an app_ObjectOwner nor an objectSpaceName are required in the BSA_ObjectDescriptor, the bsa_ObjectOwner and pathName alone can name an XBSA Object. The BSA_ObjectName does not uniquely identify a single XBSA Object since multiple XBSA Objects with the same name can exist within the Backup Service (as multiple copies of the corresponding Application Object are made).

The Backup Service assigns to each XBSA Object a unique, persistent, fixed-length Object Identifier called copyid in the type definitions (see Type Definitions and Data Structures ), which remains unchanged throughout the life of the XBSA Object. This identifier must be used to retrieve an XBSA Object, subject to the applicable access control rules.


Adequate security is a major requirement for any backup system. Authentication and access control may be administered via an underlying infrastructure. In those cases where it is not, a simple, but extensible, handle-based access model is supported by the Open Backup Services API, where the Backup Service provides session authentication and access control services for stored objects.

To support authentication, a registry of each authorized bsa_ObjectOwner and associated authorities may be maintained by the Backup Service. At the beginning of each XBSA session, the bsa_ObjectOwner may be verified against this registry, typically (though not necessarily) by means of a BSA_SecurityToken (for example, a password or a key). If the caller is authenticated, a unique handle is issued by the Backup Service to the XBSA Application for use during the session. The verification of the bsa_ObjectOwner may be performed internal to the Backup Service, or it may rely on the services of an external authentication system.

If the XBSA Client wants to alter this registry, communicate with the authentication system directly, or establish a new security token, the XBSA Client has to use a private API that has been provided by the Backup Service or by the authentication system. Such an API is not part of this Technical Standard.

The XBSA Application must then use the handle issued by the Backup Service in every subsequent API call during the session to identify itself as well as the particular session. This architecture allows an XBSA Application and a Backup Service to use a third-party authenticator (for example, Kerberos, which issues a similar validating token). The choice and operation of a particular validation system is implementation dependent.

An XBSA Application may also supply an app_ObjectOwner (for example, an end-user id) when initializing a session. If given, this name will not be authenticated by the Backup Service against the registry, but will be used for checking object ownership and access rules when objects are accessed during the session. If the app_ObjectOwner is not given, all objects owned by the bsa_ObjectOwner may be accessed.

Every XBSA Object is created by a BSA_ObjectOwner. As shown in Structure of an XBSA Object Name , a BSA_ObjectOwner consists of a bsa_ObjectOwner and app_ObjectOwner pair. The bsa_ObjectOwner possesses all access rights to the object.

The authentication of XBSA Application sessions as well as access control at that level are handled by the Backup Service. An XBSA Application, responsible for its own security domain, in turn handles the authentication and access control at the application level, possibly with the aid of the respective Application. The Backup Service provides object filtering support (utilizing the app_ObjectOwner provided by an XBSA Application to check object ownership and access rules) to reduce the amount of information that the XBSA Application has to retrieve, and thereby improving the overall retrieval performance.

Object Descriptors

An XBSA Object has a BSA_ObjectDescriptor, containing cataloging information and optional application specific object metadata. Cataloging information is capable of interpretation and searching by XBSA. Application-specific object metadata is not interpretable by XBSA but may be retrieved and interpreted by an application. Using an object's objectName or its assigned copyId identifier, the corresponding BSA_ObjectDescriptor and/or object data can be retrieved through the Open Backup Services API.

For the intended storage purpose (that is, backup or archive), each XBSA Object is a copy of certain application object(s). To preserve the semantics of the use of each copy within the BSA_ObjectDescriptor, each XBSA Object has a copyType of either backup or archive, which is recognized by the Backup Service so that the two types of objects can be managed differently and accessed separately.

Furthermore, each XBSA Object has an objectStatus of either most-recent or not-most-recent. The significance of an XBSA Object's status is implementation defined. For example, an implementation might implement a policy that for backup copies, only the latest copy of an existing application object is active, whereas all archive copies are considered active.

In addition, to capture an application object's type information, the corresponding XBSA Object may have a resourceType (for example, "DOS filesystem") and a possibly resource-specific BSA_ObjectType (for example, BSA_ObjectType_FILE).

A BSA_ObjectDescriptor consists of a collection of object attributes. To be able to define an attribute, the appropriate attribute data type must be used in each XBSA Application and Backup Service implementation. The basic data types used for XBSA Object attributes are:

A particular Backup Service implementation may keep index(s) on some or all of these attributes to enhance search performance

The attributes are shown in the following table:

Attribute Data Type Searchable?
objectOwner   yes
(consisting of two parts)    
bsa_ObjectOwner [fixed-length character string]  
app_ObjectOwner [hierarchical character string]  
objectName   yes
(consisting of two parts)    
objectSpaceName [fixed-length character string]  
pathName [hierarchical character string]  
createTime [date-time] no
copyType [enumeration] yes
copyId 64-bit unsigned integer no
restoreOrder 64-bit unsigned integer no
resourceType [fixed-length character string] no
objectType [enumeration] yes
objectStatus [enumeration] yes
objectDescription [fixed-length character string] no
estimatedSize [64-bit unsigned integer] no
objectInfo [fixed-length byte string] no

Table: Object Attributes

An XBSA Application may search for a particular XBSA Object within a certain search scope (for example, among objects belonging to an owner) by qualifying the search on the value of the appropriate searchable attributes. For character strings, a substring match (prefix, infix or suffix) is also supported.

On the other hand, non-searchable, application-specific attributes may be provided by an XBSA Application for storage in the BSA_ObjectDescriptor, but they are not interpreted by the Backup Service. They are stored in the XBSA Object attributes objectInfo, resourceType, and objectDescription.

Through this objectInfo attribute, application-specific metadata may be stored in the catalog so that this metadata can be efficiently retrieved without retrieving the actual object data stored in the repository.

Furthermore, this objectInfo attribute can also be used by an XBSA Application to maintain inter-object relationships and dependencies.

For more information on the BSA_ObjectDescriptor structure, see BSA_ObjectDescriptor .

Object Data

Object data contains the actual data entity that is archived or backed up by an XBSA Application. The Open Backup Services API supports only one type of object data, namely, a variable-length, unstructured and uninterpreted byte-string with a very large size limit.

To a particular XBSA Client, however, the XBSA Object Data can contain an internal structure that reflects the data of the Application Object or Objects that the XBSA Clients archived or backed up. In this context the XBSA Object Data can contain for example one of the following: a UNIX file system, a UNIX directory, a DOS file, a document, a disk image, a data stream, or a memory dump.

Through the Open Backup Services API, object data can be stored, retrieved, or deleted, but not searched or modified. Since object data may be stored on slow (or off-line) media, it is generally not advisable for an XBSA Application to store metadata in object data, especially information that could influence a data-retrieval decision.

However, the metadata of an XBSA Object which is stored in the catalog may be replicated in its object data to facilitate media interchange (interoperability). This is an XBSA Application implementation decision.

The mapping from the repository to physical storage media is a Backup Service implementation decision. A particular Backup Service implementation should accommodate different types of storage media, including disk, automated library, and shelf media. All opportunities for optimization or design trade-off are considered Backup Service implementation options. These include device exploitation, hierarchy management, object packing and placement, and redundancy.

Transaction Management

A backup task usually involves many updates to the catalog and repository. To protect their integrity and assure consistency between an Object Descriptor and the corresponding object data, and to provide atomicity for storing a group of objects, the concept of a transaction is used. Either all the operations within a transaction are correctly performed or none is performed.

Nested transactions are not permitted. One or more non-overlapping transactions may occur within any active session between an XBSA Application and a Backup Service. To define a transaction, an XBSA Application must begin a transaction before performing XBSA operations, and end the transaction after the appropriate XBSA calls have been made. Special XBSA calls are provided to begin and end transactions.The effect of a transaction is not visible until it is committed.

If a transaction is aborted by an XBSA Application, or if there is an error or failure encountered in the midst of a transaction, the transaction will be rolled back (that is, the effect of the transaction will be not be visible). It should be noted a rolled-back transaction may still have some observable effects. For instance, accumulated tape movement involved in the transaction may not be rewound. In such a case, no information relating to the data written to tape will be stored, and thus any information stored during the transaction will not be retrievable. In the case of a large, aborted transaction, considerable wastage of tape is possible.

The following XBSA calls are not affected by transaction management and take effect immediately without the possibility of being rolled back:

All XBSA backup and restore operations are required to be contained within transactions. Although XBSA restore operations are in a transaction, it does not provide any useful functionality to the XBSA Application. Transactions are constrained to be uni-directional, that is, it is not permitted to mix backup and restore operations in the same transaction.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index