When using a third-party backup tool, one of the major challenges that we encounter while backing up SAP HANA log segments is that, if the external storage system cannot be accessed, log backups will fail repeatedly.
For example, access to an external storage system could be lost as a result of impacted network response times, an outage due to planned maintenance, or hardware failure.
In a critical productive environment, this can quickly cause the log area to grow until the file system is full. If, as a consequence, no more log segments can be created, this will cause SAP HANA to freeze.
This was not the case during traditional file based backups.
With the release of HANA 2.0 SPS06, this problem can be easily avoided, by enablement of log backup fallback to automatically detect downtimes in a third-party backup tool, and to temporarily redirect the writing of log backups to the file system.
If a fallback is active and HANA finds backint to be available again the fallback ends. Otherwise, the fallback will remain in effect until the next attempt.
For more details about the behavior of this configuration, follow here.
To enable automatic log backup fallback, you need the SAP HANA system privilege DATABASE ADMIN. This can be configured by changing below parameter value to ‘true’ :
# Parameter change is online and no database restart is needed to affect. log_backup_backint_fallback = true
Note : –
- A log backup fallback to the filesystem will also apply to catalog backups if catalog_using_backint=true.
- Requires log_backup_using_backint=true in order to take effect.
Log Backup Fallback Location
If automatic log backup fallback is active, log backups are written to the path in the file system defined by the parameter basepath_logbackup. This path must be accessible by SAP HANA.
If the backup catalog is configured to be backed up to a third-party backup tool, if a fallback is active, backups of the backup catalog are written to the path in the file system defined by the parameter basepath_catalogbackup.
Identifying Which Log Backups Used Fallback
To check whether a log backup was written to the file system due to a fallback or not, refer to the monitoring view M_BACKUP_CATALOG_FILES. Column BACKINT_FALLBACK_USED has the following values:
FALSE : A log backup was written to the file system as configured. TRUE : A log backup was originally configured to be written to a third-party backup tool, but was written to the file system due to an automatic log backup fallback.
Log Backup Fallback is also Recorded
When a log backup fallback is triggered, alert 143 is raised.
So, when the fallback is stopped, either automatically when log backups are being written again to the external storage system, or by disabling automatic log backup fallback, alert 143 is canceled.
Are fallback backups resent to backint after the connection is restored?
i.e. to protect against a disaster and the local file system is lost
Thanks for your question.
The fallback continues as long as the third-party storage is unavailable. As soon as the external storage system is available again, the fallback ends. From then on, log backups for all services are written to the third-party backup tool again. So, yes backint is restored.
Once the external storage is available all the logs written to FILE during the fallback will be written again to the third party storage automatically ? Or it is only about the new log segments that will be written to the third party storage and the old ones that were saved locally will stay the the local local storage ?
Those logs shall be transferred to backup server manually, in case your backup archive agent is not taking care of it.
Ideally it shall be treated in a similar fashion, like traditional file backups were used to move earlier with no backint methodology.
Thanks for your question.
Thanks Vivek for your reply.Appreciate it.