Frequently asked questions – Back up SAP HANA databases on Azure VMs

You can have one schedule full backup and multiple on-demand backups in a day.

Today, successful backup jobs don’t generate alerts. Alerts are generated only for backup jobs that fail. Learn how to use the Azure portal to view Backup alerts.

You can check the status of your backups (scheduled/on-demand) from any of the following locations:

1. Backup jobs: Azure Backup shows all manually triggered jobs in the Backup jobs section in the Azure portal.
   
   The jobs you see in the Azure portal includes database discovery and registering operations, and backup and restore operations. Scheduled jobs, including log backups aren't shown in this section. Manually triggered backups from the SAP HANA native clients (Studio/Cockpit/DBA Cockpit), are also not shown here.

   

   

2. Backup alerts: Alerts help you monitor backups of SAP HANA databases. These help you to focus on the required events, thus eliminating the effort to frequently check multitude of events that a backup generates. For more details, see View backup alerts.

3. Backup Reports: Reports are another way to view the status of your backup jobs. Your reports will be as follows:

   

   

   Learn about how to configure Azure Backup reports.

4. SAP HANA Native clients: If you're an SAP HANA customer, you can also use HANA Studio, one of the most common HANA clients. In this client, navigate to Backup Console -> Backup Catalog to see the Backup status.

   

The Backup Job menu will only show on-demand backup jobs that are either in progress, have succeeded or failed. For scheduled jobs, use Azure Monitor.

Azure Backup doesn’t set an explicit retention period on the Auto-heal full backups. This backup is retained until the time you retain the dependent Delta (differential or incremental) and Log backups. Once you delete the last dependent backup on this Auto-heal backup, the Auto-heal backup is also deleted.

Yes, a full backup and a log backup can run simultaneously. This instance occurs in one of the following ways:

• Full backup is in progress and a log backup is triggered: The log backup should succeed irrespective of an ongoing full backup. Unless the full backup that's triggered was a remedial full to handle any LSN chain-break.
• Log backup is in progress, and a full backup is triggered: Both backups should run simultaneously and succeed.

No, this isn't currently supported.

If a database is dropped from an SAP HANA instance, the database backups are still attempted. This implies that the deleted database begins to show up as unhealthy under Backup Items and is still protected. The correct way to stop protecting this database is to perform Stop Backup with delete data on this database.

A renamed database is treated as a new database. Therefore, the service will treat this situation as if the database weren't found and will fail the backups. The renamed database will appear as a new database and must be configured for protection.

Refer to the tutorial for a step-by-step guide to get started with Azure Backup for SAP HANA databases. You can also use CLI to configure and manage backups.

Refer to the prerequisites for using Azure Backup with SAP HANA.

Refer to this section of the troubleshooting guide.

Refer to this section in the troubleshooting guide.

Currently we don't have the capability to set up the solution against a virtual IP or Proxy. We need a virtual machine to execute the solution.

You can trigger an on-demand backup using SAP HANA native clients to local file-system instead of Backint. Learn more how to manage operations using SAP native clients.

You can prune the HANA catalog using SAP recommended methods, such as BACKUP CATALOG DELETE statements or HANA Studio/Cockpit. Learn more how to manage operations using SAP native clients.

1. For HANA system replication (HSR), the secondary node doesn’t accept any connections at all. Once the backup is configured, the Azure Backup service pings periodically and fails. Sometimes, these failed attempts reflect on the primary node. After multiple failures, the user is locked, and then the primary node starts to fail with ODBCConnectionError.
   
   We’ve observed that all users don’t experience this issue. We recommend you/SAP to investigate the cause of users getting locked in the primary node when user connection fails on the secondary node.

2. Once you run the pre-registration script, the user information is updated with new password on the primary node. Then the connection to attempt backup will be re-established. But, you might again experience the same scenario.

3. Also, the backups (full backups) that fail on the secondary node create alerts.

To avoid the above issues, we recommend you to stop protection for a node after it becomes secondary (so that connections aren’t attempted and user is not locked) and resume protection on it, once it becomes primary. If you don’t face this locking situation on their HSR setups and are comfortable with alerts being raised, you can configure backups on both the nodes so that the service handles the take-over and fail-back.

Refer to the backup and restore throughput performance that Azure Backup provides for HANA workloads.

To set up your HANA system to leverage the improved performance, use the following resources:

• Select a disk type for Azure IaaS VMs - managed disks
• Performance tiers for Azure managed disks
• M-series
• SAP HANA Azure virtual machine storage configurations

Currently, Azure Backup for SAP HANA accepts 1 as the value of the parallel_backup_using_backint property. However, Azure Backup splits that single stream in multiple streams for better performance.

Currently, only Backint-based backups are supported for HSR. Snapshots aren't yet.

You need to run the instance re-detection on the server that is marked "Not Ready" to update its status.

You can perform a maximum of 10 restores per HANA system or instance in a day. Note that if a restore is canceled or fails, it's also considered as a restore attempt.

Check if all the prerequisites for the restore to target SAP HANA instance are met. For more information, see Prerequisites - Restore SAP HANA databases in Azure VM.

Ensure that the Force Overwrite option is selected while restoring.

Refer to the SAP HANA Note 1642148 to see what restore types are currently supported.

Yes, you can use streaming backups triggered on a HANA database running on SLES to restore it to an RHEL HANA system and vice versa. That is, cross OS restore is possible using streaming backups. However, you'll have to ensure that the HANA system you want to restore to, and the HANA system used for restore, are both compatible for restore according to SAP. Refer to SAP HANA Note 1642148 to see which restore types are compatible.

Yes, you can download files partially as documented here.

Yes, you need to disable the HANA System Replication (HSR) on target system, and then perform restore. You can't restore an HSR-enabled system, as per SAP.

Before creating a policy, you should be clear on the requirements of RPO and RTO and its relevant cost implications.

RPO (Recovery-point-objective) indicates how much data loss is acceptable for the user/customer. This is determined by the log backup frequency. More frequent log backups indicate lower RPO and the minimum value supported by Azure Backup service is 15 minutes. So log backup frequency can be 15 minutes or higher.

RTO (Recovery-time-objective) indicates how fast the data should be restored to the last available point-in-time after a data loss scenario. This depends on the recovery strategy employed by HANA, which is usually dependent on how many files are required for restore. This has cost implications as well, and the following table should help in understanding all scenarios and their implications.

Therefore, you can select the policy variant based on RPO and RTO objectives and cost considerations.

A few principles should be kept in mind when determining the impact of switching a backup item's policy from Policy 1 (P1) to Policy 2 (P2) or of editing Policy 1 (P1).

• All changes are also applied retroactively. The latest backup policy is applied on the recovery points taken earlier as well. For example, assume that the daily full retention is 30 days and 10 recovery points were taken according to the currently active policy. If the daily full's retention is changed to 10 days, then the previous point's expiry time is also recalculated as start time + 10 days and deleted if they're expired.
• The scope of change also includes day of backup, type of backup along with retention. For example: If a policy is changed from daily full to weekly full on Sundays, all earlier fulls that aren't on Sundays will be marked for deletion.
• A parent isn't deleted until the child is active/not-expired. Every backup type has an expiration time according to the currently active policy. But a full backup type is considered as parent to subsequent 'differentials', 'incrementals' and 'logs'. A 'differential' and a 'log' aren't parents to anyone else. An 'incremental' can be a parent to subsequent 'incremental'. Even if a 'parent' is marked for deletion, it's not actually deleted if the child 'differentials' or 'logs' aren't expired. For example, if a policy is changed from daily full to weekly full on Sundays, all earlier fulls that aren't on Sundays will be marked for deletion. But they aren't actually deleted until the logs that were taken daily earlier are expired. In other words, they're retained according to the latest log duration. Once the logs expire, both the logs and these fulls will be deleted.

With these principles, you can read the following table to understand the implications of a policy change.

You could manage the space in the root folder using one of the following options:

• Create an own LV for /opt/msawb.
• Create a soft link/symlink to another location/folder on the same/different disk.
• Increase the space on the root partition.

Next steps

• Learn how to back up SAP HANA databases running on Azure VMs.
• Learn how to troubleshoot SAP HANA database backup.