Skip to Content
Technical Articles
Author's profile photo Vivek Sahu

SAP Hana Automatic filesystem fallback for backint-based log backups : SPS06 and above

Problem

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.

Solution

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.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Mike Eacrett
      Mike Eacrett

      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

      Author's profile photo Vivek Sahu
      Vivek Sahu
      Blog Post Author

      Hello Mike,

      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.

      Best Regards,
      Vivek Sahu