Summary
This article provides information on how to configure Catalogic Block Backup for protecting SAP MAXDB implementation instances. Note that the description here illustrates a protection method that relies on a vendor supplied binary. Catalogic Software does not directly support application interfaces to coordinate application-consistent backup of SAP MAXDB. The methodology described here uses a vendor supplied binary, and only describes how this binary can be automated in a backup job to quiesce and back up data. Any questions relating to backup, transaction logs, data recovery, or SAP MAXDB best practices should be directed to SAP MAXDB.
Resolution
Catalog software data protection uses several methods to quiesce applications by using pre/post-scripts for snapshots. The pre/post-script functionality automates a script triggered to occur right before Volume Snapshot Service (VSS) or Logical Volume Manager (LVM) snapshot, right after VSS or LVM snapshot, and right after data transfer is complete. For applications that Catalogic Software does not directly support, it is common to use pre/post snapshot scripts to quiesce the application, perform the VSS/LVM snapshot, and then resume the application back to normal activity. In many cases, this pre/post snapshot feature is used to stop the application, snapshot the data in "cold backup" mode, and then bring the application up again. In the case of SAP MAXDB, a script can be used to freeze the database files (with new activity being sent to transaction logs), perform the VSS/LVM snapshot, and then unfreeze the database files to resume normal activity. In either case, once the VSS/LVM snapshot is complete, the backup software is free to transfer that data while the application continues to serve data.
For a complete and general description of how pre/post snapshot scripting works, see the section "Implementing Pre-Script and Post-Script for Snapshots Operations" in the DPX User's Guide available at the Catalogic MySupport site.
You need to do the following:
- Install the Catalogic DPX client to your SAP MAXDB host.
- Create a script containing the necessary actions to freeze the DB (for example SAP MAXDBfreeze.bat/SAP MAXDBfreeze.sh), and save this to the DPX 'sched\scripts' directory.
- Create a a script containing the necessary actions to thaw the DB (for example SAP MAXDBthaw.bat/SAP MAXDBthaw.sh), and save this to the DPX 'sched\scripts' directory.
- Following the section "Implementing Pre-Script and Post-Script for Snapshots Operations" in the DPX User's Guide, create the required scrinfo.txt and save this script to the DPX 'bin' directory.
For example, If your DPX Block backup job name is SAP MAXDBprotect, the scrinfo.txt file would read:
# SAP MAXDB freeze thaw script
cmd=SAP MAXDBfreeze.bat/SAP MAXDBfreeze.sh<>type=presnap<>jobname=SAP MAXDBprotect<>abort_on_fail=1
cmd=SAP MAXDBthaw.bat/SAP MAXDBthaw.sh<>type=postsnap<>jobname=maxdpbrotect
As with any scripting or programming effort, it is strongly suggested to check and print accurate status messages for job log auditing and job control. Note that if error status is not checked and handled properly, it is possible that the expected result from the vendor supplied binary is not achieved. The backup can continue with live data that is not in a quiesced application-consistent state and later result in difficulty and failure at restore time. It is strongly suggested to use the Catalogic ’bexit’ binary to pass any failure status to the job for error processing. With the scrinfo.txt example above, the job will fail if the user supplied script returns an error status. Backup job failure in this case is preferred as the failure will be visible to the data protection engineer who can alert the application owner for corrective action. For more information on the use of 'bexit' for error code passing on Windows platforms, see the section "Implementing Pre-Script and Post-Script for Snapshots Operations" in the DPX User's Guide.
Using pre/post snapshot scripting along with SAP MAXDB script should result in a very brief period of time where the database files are frozen (read-only). According to the SAP MAXDB documentation, the SAP MAXDB database engine should remain active during this time and send any new commits to transaction logs, which will be flushed after the database files are unfrozen.
For additional details on placement of database files, transaction logs, and SAP MAXDB best practices for backup and recovery, please consult SAP documentation and/or technical support at SAP MAXDB.