Azure Backup architecture for SAP HANA backup

Azure Backup service allows you to back up data from SAP HANA databases in an application in consistent manner. This article describes the Azure Backup architecture components and processes.

How does Azure Backup work with SAP HANA databases?

Azure Backup provides a streaming backup solution to back up SAP HANA databases running on an Azure VM. This backup offering requires zero-infrastructure setup, thereby eliminating the need to deploy and manage backup-infrastructure.

Azure Backup is Backint certified by SAP, provides native backup support by using SAP HANA’s native APIs. With this solution, you can seamlessly back up and restore SAP HANA databases running on Azure VMs and use the enterprise management capabilities that Azure Backup provides.

Learn more about the added values that Azure Backup provides for SAP HANA.

Where is the data backed up?

Azure Backup stores the backed-up data in Recovery Services vaults. A vault is an online-storage entity in Azure that's used to store data, such as backup copies, recovery points, and backup policies.

Learn more about Recovery Services vault.

Backup agents

To back up SAP HANA databases running on Azure VM, you need to allow the installation of the plugin (SAP HANA Backup agent) on the Azure VM. This plugin connects with HANA Backint and helps the Azure Backup service to move data to the vault. It also enables Azure Backup to perform restores.

Backup types

Learn about SAP HANA backup types.

About architecture

In the following sections you'll learn about the backup architecture of HANA databases in Azure Backup.

Backup architecture for database

See the high-level architecture of Azure Backup for SAP HANA databases. For a detailed understanding of the backup process, see the following process:

Diagram showing the backup process of SAP HANA database.

  1. To begin the backup process, create a Recovery Services vault in Azure. This vault will be used to store the backups and recovery points created over time.

  2. The Azure VM running an SAP HANA server is registered with the vault, and the databases to be backed up are discovered. To enable the Azure Backup service to discover databases, you must run this preregistration script on the HANA server as a root user.

    Note

    Ensure that the HANA instance is up and running during the discover of the databases in this instance.

  3. Also, ensure that the other pre-requisites are fulfilled.

    Important

    Ensure that the prerequisite to set up the right network connectivity is met. See the recommendation on how to set up Azure VMs running in SAP HANA with additional network components to use the backup offering.

  4. See the details about what the pre-registration script does. If you attempt to configure backup for SAP HANA databases without running this script, you might receive the error UserErrorHanaScriptNotRun.

  5. The Azure Backup service now installs the Azure Backup Plugin for HANA on the registered SAP HANA server. This plugin uses the Backup user created by the pre-registration script to perform all backup and restore operations.

  6. To configure backup on the discovered databases, choose the required backup policy and enable backups.

  7. Azure Backup for SAP HANA (a Backint certified solution) doesn't depend on the underlying disk or VM types. The backup is performed by streams generated by SAP HANA.

Backup flow

This section provides you with an understanding about the backup process of an HANA database running on an Azure VM.

  1. The scheduled backups are managed by crontab entries created on the HANA VM, while the on-demand backups are directly triggered by the Azure Backup service.

  2. Once SAP HANA Backup Engine/Backint receives the backup request, it prepares the SAP HANA database for a backup by creating a save point, and moving data to underlying storage volumes.

  3. Backint then executes the read operation from the underlying data volumes - the index server and XS engine for the Tenant database and name server for the SYSTEMDB. Premium SSD disks can provide optimal I/O throughput for the backup streaming operation. However, using uncached disks with M64Is can provide higher speeds.

  4. To stream the backup data, Backint creates up to three pipes, which directly write to Recovery Services vault of Azure Backup.

    If you aren’t using firewall/NVA in your setup, then the backup stream is transferred over the Azure network to the Recovery Services vault / Azure Storage. Also, you can set up Virtual Network Service Endpoint or Private Endpoint to allow SAP HANA to send backup traffic directly to Recovery Services Vault / Azure Storage, skipping NVA/Azure Firewall. Additionally, when you use firewall/NVA, the traffic to Microsoft Entra ID and Azure Backup Service will pass through the firewall/NVA and it doesn’t affect the overall backup performance.

  5. Azure Backup attempts to achieve speeds up to 420 MB/sec for non-log backups and up to 100 MB/sec for log backups. Learn more about backup and restore throughput performance.

  6. Detailed logs are written to the backup.log and backint.log files on the SAP HANA instance.

  7. Once the backup streaming is complete, the catalog is streamed to the Recovery Services vault. If both the backup (full/differential/incremental/log) and the catalog for this backup are successfully streamed and saved into the Recovery Services vault, Azure Backup considers the backup operation is successful.

In the following sections you'll learn about different SAP HANA setups and their process of executing backups.

SAP HANA setup scenario: Azure network - without any NVA/Azure Firewall

Diagram showing the SAP HANA setup if Azure network without any NVA/Azure Firewall.

SAP HANA setup scenario: Azure network - with UDR + NVA / Azure Firewall

Diagram showing the SAP HANA setup if Azure network with UDR + NVA / Azure Firewall.

Note

NVA/Azure Firewall may add an overhead when SAP HANA stream backup to Azure Storage/Recovery Services vault (data plane). See point 6 in the above diagram.

SAP HANA setup scenario: Azure network - with UDR + NVA / Azure Firewall + Private Endpoint or Service Endpoint

Diagram showing the SAP HANA setup if Azure network with UDR + NVA / Azure Firewall + Private Endpoint or Service Endpoint.

Backup architecture for database with HANA System Replication

The backup service resides in both the physical nodes of the HSR setup. Once you confirm that these nodes are in a replication group (using the pre-registration script), Azure Backup groups the nodes logically, and creates a single backup item during protection configuration.

After configuration, Azure Backup accepts backup requests from the primary node. On failover, when the new primary node starts generating log backup requests, Azure Backup compares the new log backups with the existing chain from the older primary node.

If the backups are sequential, Azure Backup accepts them and protects the new primary node. If there's any inconsistency/break in the log chain, Azure Backup triggers a remedial full backup, and log backups will be successful only after the remedial full backup completes.

Diagram showing the backup architecture of SAP HANA database with HANA system replication enabled.

Note

The Azure Backup service connects to HANA using hdbuserstore keys. As the keys aren't replicated, we recommend you create the same keys in all nodes, so that Azure Backup can connect automatically to any new primary node, without a manual intervention after failover/failback.

Backup flows

In the following sections, you'll learn about the backup flow for new/existing machines.

New machines

This section provides you with an understanding about the backup process of an HANA database with HANA System replication enabled running on a new Azure VM.

  1. Create a custom user and hdbuserstore key on all the nodes.
  2. Run the pre-registration script on both the nodes with the custom user as the backup user to implement an ID, which indicates that both the nodes belong to a unique/common group.
  3. During HANA protection configuration, select both the nodes for discovery. This helps to identify both nodes as a single database which you can associate with a policy and protect
Existing machines

This section provides you with an understanding about the backup process of an HANA database with HANA System replication enabled running on an existing Azure VM.

  1. Stop protection and retain data for both the nodes.

  2. Run the pre-registration script on both the nodes with the custom user as the backup user to mention an ID, which indicates that both the nodes belong to a unique/common group.

  3. Rediscover the databases in the primary node.

    Screenshot showing you about how to rediscover a database.

  4. Configure backup for the newly created replicated database from Step 2 of configure backup.

  5. Delete the backup data of the older standalone backup items for which protection was paused.

Note

For the HANA VMs that are already backed-up as individual machines, you can do the grouping only for future backups.

Backup architecture for database instance snapshot

Azure Backup integrates Azure-managed disk full or incremental snapshots with HANA snapshot commands to deliver instant backup and recovery capabilities for HANA.

SAP HANA database instance snapshot backup

The backup architecture explains the different permissions that are required for the Azure Backup service, which resides on a HANA virtual machine (VM), to take snapshots of the managed disks and place them in a user-specified resource group that's mentioned in the policy. To do so, you can use the system-assigned managed identity of the source VM.

Diagram shows the SAP HANA database instance snapshot backup architecture.

SAP HANA database instance snapshot restore

The restore architecture explains the different permissions required during the restore operation. Azure Backup uses the target VM’s managed identity to read disk snapshots from a user-specified resource group, create disks in a target resource group, and attach them to the target VM.

Diagram shows the SAP HANA database instance snapshot restore architecture.

Next steps