Restore transaction
The Restore transaction is similar to Backup transaction, except that the data flow is reversed. The restore transaction is defined by a call to BSAGetObject().
To restore an XBSA object, the NetBackup XBSA interface needs to know the copyId of that object. The copyId can be obtained from a catalog that is maintained by the XBSA application or from a previous BSAQueryObject() call. Query operations can be mixed in with restore operations to get this data.
The BSAGetObject() call is used to initiate the restore of an object. It takes as input an object descriptor that contains the copyId of the object to be restored. Then, a series of BSAGetData() calls are used to get data for the object in buffers. The BSAEndData() call signals the end of getting data for the object. It is up to the XBSA application to recreate the object being restored using the object descriptor and data. When restoring multiple objects, the XBSA application must get all data for an object and call BSAEndData() before it calls BSAGetObject() to start restoring the next object.
Within a restore transaction, it is permissible to have BSAQueryObject() and BSAGetNextQueryObject() calls. This lets the XBSA application intermix restore operations with BSAQueryObject() and BSAGetNextQueryObject() calls to restore multiple objects within one transaction. Backup and delete operations are not allowed within a restore transaction.
It should be noted that the use of transactions for restore operations does not provide any functional benefit to the XBSA application but is required for completeness. If a restore is aborted with a call to BSAEndTxn() or BSATerminate() before the restore has completed, the NetBackup XBSA interface frees the NetBackup resources. It is up to the XBSA application to leave the object being restored in a consistent state.