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.