Previous section.

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

Information for Backup Services Developers

This appendix is not a normative part of the specification.

Networked Environments

As an implementation example, a specific Backup Service may be provided for a standalone system as a local XBSA subsystem, which supports the Open Systems Backup Services API directly. Alternatively, as an example for a distributed environment, the Backup Service may be provided by one or more BSA Server(s) on a network, and a BSA Client implementation may reside on each Client system, supporting the Open Systems Backup Services API and communicating with the XBSA Server(s) using a suitable communication facility and protocol - see An Example of a Distributed Backup System .

The architecture supports heterogeneous networks and any suitable communication protocol.

Figure: An Example of a Distributed Backup System

Storage Hints

Although not defined in the specification, the objectSpaceName field in the BSA_ObjectName structure may be used to obtain hints on how to store the object's data.

Object Routing

Backup Service implementations may assume that process environment variables can be passed via the shell or command interpreter to the XBSA Client, and from there to the Backup Service to aid the Backup Service in selecting the appropriate backup medium for a session. There are a couple of hidden assumptions behind this - that the program called by the user is the XBSA Client that connects to the Backup Service and that the program is called in such a way that the environment variables can be set by the Backup Service itself. Another flaw in this approach is the presumption that the user is willing or knowledgeable enough to set these variables properly for each backup or restore event in the case that the Client is not invoked by the Backup Service. A third flaw is that all of this knowledge is non-transferable from one XBSA and Backup Service implementation to another. Together, these impose a significant experience or training requirement on the user.

The same problems hold if the user is expected to pass command line arguments to the XBSA Client. The Backup Service should not rely on these mechanisms to transfer routing information through the XBSA Client. Instead, the Backup Service should determine how to route XBSA Object Data by inspecting each XBSA Object individually. Several solutions are possible:

Round-Robin Solution

One possible, but inadequate, solution is for the Backup Service or XBSA implementation to simply route objects to the next-available device. This allows for parallel backups, but at the cost of poor sequencing of objects on backup media and of poor predictability.

Session-Guessing Solutions

A second solution is for the XBSA implementation to try to guess which set of objects belong together and send these to one set of devices, while another set of objects grouped together would be sent to a different set of devices. This takes care of the predictability problem and sequencing problem, but only if the guess is correct.

Some proposed session identification schemes have been based on either timing of backup events, the process ids of the XBSA Clients, or BSAInit/BSATerminate function call pairs. In all of these cases, the XBSA implementation has to make possibly false assumptions about the Client's behavior. For example, if a database administrator starts a database backup at the same time that a system administrator starts a filesystem backup, then a timing-based session guess will combine these completely separate events into a single session. BSAInit/Terminate pairs are also unreliable because a single user request may be distributed across several processes, each of which is required to call BSAInit() to get started.

Object Descriptor Solution

A third mechanism for routing objects is to actually use the metadata passed through XBSA to choose the set of devices or media to which an object should be written. The XBSA implementation or Backup Service can parse the BSA_ObjectDescriptor passed in the BSACreateObject() call. Whether it intelligently uses the contents or simply compares each field with a device mapping provided by the user, this general scheme provides great flexibility. For example, all objects created with a particular resourceType could be sent to the same medium. The Backup Service could allow the administrator to create a configuration file that lists groups of resourceType values and maps them to a particular group of devices or media; a newly created object would then cause the Backup Service to scan the configuration file for this resourceType to find the right backup device or medium to use.

This solution does not address grouping of objects into larger entities. The Backup Service has to make these decisions based on the call sequence and routing. It is up to the Backup Service to group objects, if possible, for performance considerations.

Disadvantages of this approach are that devices cannot be preallocated and media cannot be premounted as the decision of where to put an object is made in the BSACreateObject() call, and that ad-hoc backups may require special steps by the user to temporarily reconfigure the object routing.

Advantages are that the base configuration can be created once, with only occasional maintenance, and routing is extremely predictable. All fields in the BSA_ObjectDescriptor could be used. The routing of backup objects then becomes dependent on the configurability of the storage manager and the accuracy and completeness of the BSA_ObjectDescriptor created by the Backup Client. Either the Backup Service, XBSA implementation, or XBSA Client can then be modified or upgraded without affecting the others' ability to function.

Restore Order

The restoreOrder field in the BSA_ObjectDescriptor is assigned by the Backup Service at the time the XBSA Object is created. Restore order values provide a hint to the XBSA Client as to which sequence of BSAGetObject() calls would make most efficient use of the Backup Service's resources. The XBSA Client is free to ignore these values and the Backup Service has no obligation to completely optimize its assignment of restoreOrder. Multiple objects with the same restoreOrder indicate that the Backup Service has no preference for which of them gets processed first. If the XBSA implementation or the Backup Service do not know how to provide these hints, then the restoreOrder should be left with the value 0/0. Restore order is assigned at object creation time.

To make best use of the restore order suggested for a group of objects, the XBSA Client should call BSAQueryObject() and BSAGetNextQueryObject() for as many of the objects to be restored as possible. It should, within the requirements imposed by the application, restore the objects in ascending restoreOrder sequence. The restoreOrder.left is the primary sort key, and restoreOrder.right is the secondary sort key. If N objects are to be restored at the same time, then the first N objects in ascending sort order should be the ones chosen by the Client.

The values for restoreOrder can be determined in several ways, based on several criteria. One possible mechanism for selecting values is to use dates - assign the restoreOrder.left to the current year, and restoreOrder.right to the number of seconds since midnight, January 1, of the current year. A restore would then sort objects by the time at which they were backed up.

Another method might be to assign each device or medium a unique integer, which gets inserted into the restoreOrder.right for every object that is backed up on that device or medium, and put the position of that object on the device or medium in the restoreOrder.left. A restore could then read the first object on each medium first, then move on to the second object on each medium, and so on. If there are as many devices as there are media, then parallel operations would be quite efficient.

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