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
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
Furthermore, not indicated in
The API Definitions defined in
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:
To reduce the amount of backup data, an incremental
backup may be performed which backs up only objects which
have been changed since a previous backup.
An archive copy, on the other hand, provides long-term storage for an inactive object such as a file, which is often deleted from an application's repository after the archive copy is made. Therefore, an archive copy could be created when an object is classified as inactive, which is a policy of the application. For archives, there is no concept analogous to an incremental backup.
The retention of an archive copy is usually determined by its age, or useful life, and does not depend on other copies of the same data object.
A backup copy operation, on the other hand, may often be
deferred in the interests of improving backup operation
performance. This is acceptable because the original data
object is still available to the application as the
primary copy.
For example, an automated backup operation may choose to
skip an object which is being updated by a (possibly
long-running) application. That object will then be
backed up at the next scheduled backup time. To most
applications, backing up an object (as opposed to keeping
dual copies) is an asynchronous operation, which accepts
the fact that there is an inherent window of
inconsistency between a backup copy and the original
object. An application or user needs to manage the risk
level of this inconsistency in conjunction with
performance and cost.
The application is responsible for implementing suitable
availability policies using XBSA. By itself, XBSA does
not provide availability.
The underlying part of the
architecture that supports XBSA is called the Backup Service.
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.
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
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,
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.
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.
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
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
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
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
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
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.
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
| 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 |
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
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.
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.
| Contents | Next section | Index |