Veritas NetBackup™ DataStore SDK Programmer's Guide for XBSA 1.1.0
- Introduction to NetBackup XBSA
- How to set up the SDK
- Using the NetBackup XBSA interface
- Getting help with the API
- NetBackup XBSA data structures
- NetBackup XBSA environment
- XBSA sessions and transactions
- Creating a NetBackup XBSA application
- How to build an XBSA application
- How to run a NetBackup XBSA application
- API reference
- Error messages
- Function calls
- Function specifications
- BSABeginTxn
- BSACreateObject
- BSADeleteObject
- BSAEndData
- BSAEndTxn
- BSAGetData
- BSAGetEnvironment
- BSAGetLastError
- BSAGetNextQueryObject
- BSAGetObject
- BSAInit
- BSAQueryApiVersion
- BSAQueryObject
- BSAQueryServiceProvider
- BSASendData
- BSATerminate
- NBBSAAddToMultiObjectRestoreList
- NBBSADeleteImage
- NBBSAEndGetMultipleObjects
- NBBSAFreeJobInfo
- NBBSAGetEnv
- NBBSAGetErrorString
- NBBSAGetJobId
- NBBSAGetJobInfo
- NBBSAGetMediaIds
- NBBSAGetMultipleObjects
- NBBSAGetServerError
- NBBSALogMsg
- NBBSASetEnv
- NBBSAUpdateEnv
- NBBSAValidateFeatureId
- Type definitions
- Process flow and troubleshooting
- How to use the sample files
- Support and updates
Performance considerations
For the most part, the performance of the NetBackup XBSA interface in conjunction with the XBSA application is dependent on how NetBackup is configured and how fast the XBSA application sends or receives data. It is important that the developers of an XBSA application have some understanding of NetBackup to get the most out of it. Most of that is determined by any individual implementation. But there are areas where the application can make a difference in performance.
Here are some hints to help you get the most out of the NetBackup XBSA interface.
Use copyId if you know it. If the XBSA application has the ability to know or keep the copyId for further reference, this is the most efficient method of getting the object for restore.
Specify dates when doing a query. If start and end dates are not specified when doing a query, the NetBackup XBSA interface may need to search through the entire NetBackup catalog to find the object. Specifying dates allows it to narrow its search.
Limit use of wildcards when doing a query. Wildcards, including the "ANY" value of the enumeration types, cause more overhead searching and can also cause large portions of the NetBackup catalog to be searched. This is especially true of the pathName. Wildcards can be very useful, but from a performance perspective they are harmful.
Use OBJECT_STATUS_MOST_RECENT. If the XBSA application knows that a pathName is unique, or that it is searching for only the most recent copy of that object, set the objectStatus of the query descriptor to OBJECT_STATUS_MOST_RECENT. This will let NetBackup stop searching once one copy has been found.
Unless the images are very large, create multiple objects per transaction rather than one object per transaction when there are multiple objects being created. Every transaction creates a NetBackup job that must be scheduled, open sockets, mount tapes, etc. For large objects, this overhead is dwarfed by the time it takes to backup the data. On the other hand if there are many small objects, this overhead becomes significant. Note that when creating multiple objects with one transaction, there is no mechanism in the NetBackup XBSA interface to delete a single object. However, the entire NetBackup image can be deleted by calling NBBSADeleteImage().