Introduction:
In this blog, we will learn in detail on how to back up SAP HANA databases with HSR enabled (for High Availability purpose) that are running on Azure virtual machines (VMs) to an Azure Backup Recovery Services vault by using Azure Backup.
Purpose
With the surge in customers using SAP S/4HANA as their critical business workload, underlying SAP HANA databases becomes even more critical that requires very low RPO (Recovery Point Objective) i.e., with minimal data loss and low RTO (Recovery Time Objective) i.e., with less turnaround time to restore systems using the backups. Also, customers are looking for ease of use i.e., to configure, monitor, maintain in terms of Backup/Restore.
This blog can be used as reference on how to configure backup of SAP HANA databases with HSR (HANA System Replication) enabled on Azure VMs to an Azure Recovery Services Vault.
Azure Backup is Backint certified by SAP, to provide native backup support by leveraging SAP HANA’s native APIs. This offering from Azure Backup aligns with Azure Backup’s model of zero-infrastructure backups, eliminating the need to deploy and manage backup infrastructure. SAP HANA databases can now seamlessly backup and restore running on Azure VMs and leverage enterprise management capabilities that Azure Backup provides.
Azure Backup Offerings
Using Azure Backup solution to backup and restore SAP HANA databases, have the following advantages:
- 15-minute Recovery Point Objective (RPO): Recovery of critical data of up to 15 minutes is possible.
- One-click, point-in-time restores: Restore of production data can be done on alternate HANA servers. Chaining of backups and catalogs to perform restores is all managed by Azure behind the scenes.
- Long-term retention: For rigorous compliance and audit needs. Backups can be retained for years, based on the retention duration, beyond which the recovery points will be pruned automatically by the built-in lifecycle management capability.
- Backup Management from Azure: Use Azure Backup’s management and monitoring capabilities for improved management experience. Azure CLI is also supported.
SAP HANA backup support matrix
Before deciding on choosing Azure Backup for SAP HANA database ensure that your current SAP HANA setup/configuration falls under SAP HANA backup supported matrix.
System Architecture & Flow
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.
Refer to below table for the details of the reference setup:
| Hostname | IP Address | Role | OS Version | DB Version |
| s4adbvm0 | 10.16.5.6 | HANA DB (Primary) | SLES 15 SP3 | HANA 2.0 Rev64 |
| s4adbvm1 | 10.16.5.5 | HANA DB (Secondary) | ||
| s4as4adb00cl | 10.16.5.4 | Virtual Hostname (ILB) |
Prerequisites
Create Recovery Services Vault
- Create a Recovery Services vault in the same region and subscription as the two VMs/nodes of the HANA System Replication (HSR) database.
- Recovery Services Vault is the one that stores all the recovery points that are created over time, and it also provides an easy interface to perform backup/restore related operations.
- Login into Azure Portal and search for backup Center and navigate to the dashboard.
- Select Vault as highlighted below.
- Choose Recovery Services Vault and proceed.
- Choose the subscription under which the Recovery Services Vault must be created. In this case, same subscription where the SAP HANA databases reside.
- Choose existing resource group or create new one based on the requirement.
- Provide a unique name for your backup vault where all the backups would be stored.
- Select the region where your backup vault would reside. In this case, it’s the same region where your SAP and HANA workloads are running.
- Review the input parameters and proceed.
- Monitor for the deployment to be completed successfully.
Create/Define a Backup Policy
- A backup policy defines the backup schedules and the backup retention duration.
- Every Policy is created at vault level.
- Same backup policy can be used by multiple Vaults by apply the same to intended vaults.
- By default, Vault comes with few predefined policies that can be used for Azure VMs.
- To create a policy as per your requirement, navigate to backup policies under manage tab in the Recovery services Vault as shown below and click on Add.
- Select the policy type as SAP HANA in Azure VM (Database via Backint) as shown below.
- Provide a name for the policy, in this case it is HANABKPPOLICY-TEST. For the purpose of this blog, I have enabled only Full backup (to run daily).
- There is a new field (HANA Backup Compression) added part of backup policy. Enabling this would make the Azure Backup use HANA native backup compression technique resulting in size reduction of every data backup triggered via Azure Backup.
NOTE: Azure Backup doesn’t automatically adjust for daylight saving time changes when you're backing up an SAP HANA database that's running in an Azure VM. Modify the policy manually as needed.
Network Connectivity
- Allow connectivity from each of the VMs/nodes to the internet for communication with Azure. For all the operations, SAP HANA DB running in Azure VM requires access to connectivity to the Azure Backup service, Azure Storage, and Azure Active Directory. Follow the MS docs section on the various ways to establishing network connectivity in VMs with Azure services.
- Failure to provide required connectivity to access Azure Services may result in failure of basic operations like DB discovery, Backup configuration and DB backup/restore.
Run preregistration script on HANA VMs
- Create a key named SYSTEM for the existing HANA SYSTSEM user in hdbuserstore of both HANA DB VM/nodes. Use SIDADM user for performing below operation.
Syntax: hdbuserstore set <<KEY of hdbuserstore>> <<hostname>>:<<3instno13>> SYSTEM <<system user password>>ex: hdbuserstore set SYSTEM s4adbvm0:30013 SYSTEM <<xxxxxx>>- Similarly, run the same on secondary node.
- Create a custom backup user named AZUREWLBACKUPHANAUSER in the HANA system with the following roles and permissions.
- DATABASE ADMIN
- BACKUP ADMIN
- INIFILE ADMIN
- CATALOG READ
- SAP_INTERNAL_HANA_SUPPORT (for SAP HANA 2.0 REV45 & below)
NOTE: Create the user on the SYSTEMDB rather than the tenant DB of HANA database
- Ensure the custom backup user AZUREWLBACKUPHANAUSER created is set as technical user and exempt from password expiration policies. Run the below SQL query for the same.
ALTER USER AZUREWLBACKUPHANAUSER DISABLE PASSWORD LIFETIME- Add the custom backup user created in the above step to hdbuserstore with a key name as AZUREWLBACKUPHANAUSER which enables the HANA backup plug-in to manage all operations (database queries, restore operations, configuring, and running backup).
- Run the below mentioned commands using SIDADM user on both the HANA DB VM nodes (primary and secondary).
hdbuserstore set AZUREWLBACKUPHANAUSER s4adbvm0:30013 AZUREWLBACKUPHANAUSER <<xxxxxx>>
hdbuserstore set AZUREWLBACKUPHANAUSER s4adbvm1:30013 AZUREWLBACKUPHANAUSER <<xxxxxx>>NOTE: You can create a custom backup key using the load balancer host/IP instead of local host to use Virtual IP (VIP) in hdbuserstore.
- In case the custom backup user or Key is not created, then the Pre-registration script uses the SYSTEM Key created in hdbuserstore earlier and creates custom backup user AZUREWLBACKUPHANAUSER with necessary roles and creates a KEY on hdbuserstore for the same.
- However, it is recommended to create a custom user before we run the script especially for HSR enabled HANA DB as the users would be replicated from Primary à Secondary, while the hdbuserstore keys are not replicated. This could result in backup failures in case of DB failovers.
- Download the Pre-registration script from here and run the same as root user on the primary node i.e., which is acting as the Primary HANA DB.
- If your HANA setup uses private endpoints, run the preregistration script with the -sn or --skip-network-checks
- In case your SIDADM user is part of AD group then it’s recommended to create a group named msawb in your AD and add your SIDADM user part of this group before running the pre-registration script and also mention that your SIDADM user is an AD user while running the script using parameter -ad <SID>_ADM_USER or --ad-user <SID>_ADM_USER.
- Provide a unique HSR ID as input to the script:
-hn HSR_UNIQUE_VALUE or --hsr-unique-value HSR_Unique_Value- You must provide the same HSR ID on both VMs/nodes. This ID must be unique within a vault. It should be an alphanumeric value containing at least one digit, one lowercase letter, and one uppercase character, and it should contain from 6 to 35 characters.
Pre-registration command (Primary):
./msawb-plugin-config-com-sap-hana.sh -hn S4AHsR -bk AZUREWLBACKUPHANAUSER- After the preregistration script has run successfully, proceed to the next steps.
- Once the pre-registration scripts completes successfully on the primary node, run the script on the secondary node (s4adbvm1 in our case) using the below command:
Pre-registration command (Secondary):
./msawb-plugin-config-com-sap-hana.sh -hn S4AHsR -bk AZUREWLBACKUPHANAUSER -p 30013- While you're running the preregistration script on the secondary node, you must specify the MDC port as input. This is for SQL commands to identify that the MDC setup can't be run on the secondary node. Syntax (-p 3<<instno>>13 or -port_number 3<<instno>>13) used above refers to MDC port of the secondary HANA database.
Running the pre-registration script as mentioned above performs the following operations on the respective Azure VM:
- Based on your Linux distribution, the script installs or updates any necessary packages (for Linux OS such as libodbc, unixodbc, sqlodbc) required by the Azure Backup agent.
- It performs outbound network connectivity checks with Azure Backup servers and dependent services like Azure Active Directory and Azure Storage.
- It logs into your HANA system using the custom user key or SYSTEM user key mentioned as part of the prerequisites. This is used to create a backup user (AZUREWLBACKUPHANAUSER) in the HANA system (if this is not created manually) and the user key can be deleted after the pre-registration script runs successfully.
- It checks for sufficient space on /var/log, /opt, /var/lib/waagent folders. Insufficient space on these mount points could lead to partition getting full and causing backups to fail.
- In case of SIDADM user being local user, script adds the sidadm user to group msawb.
HANA Parameter settings
- Ensure the parameter in global.ini [inifile_checker]/replicate is set to TRUE on the primary node before configuring the HANA backup using Azure. Setting this parameter will ensure that HANA backup parameters added part of Azure backup configuration are replicated from primary to secondary node.
- Once you have configured the backup, the Azure Backup service sets up the following Backint parameters at the database level on the protected SAP HANA server:
global.ini --> Backup Section
- catalog_backup_using_backint - true
- enable_accumulated_catalog_backup - false
- parallel_data_backup_backint_channels - 1
- backint_response_timeout - 7200
- log_backup_using_backint - true
global.ini --> persistence section
- log_backup_timeout_s - 900
Database discovery
Now, that pre-registration script has been run successfully on both VM’s, it’s time to perform discovery of HANA databases running on the Azure VM. Follow the below steps:
- Go to Recovery Services Vault created above and click on Backup as shown below.
- Select SAP HANA in Azure VM as the input, and then select Start Discovery.
- Selecting Start Discovery would initiate the discovery of unprotected Linux VMs in the vault region.
- After discovery, unprotected VMs appear in the portal, listed by name and resource group.
- Select the VMs running the SAP HANA workloads and part of HANA SYSTEM REPLICATION (HSR).
- Once the VMs are selected, click on Discover DBs.
- An Azure deployment will get started which will register host to protected Container.
- Azure Backup discovers all SAP HANA databases on the VM. During this phase, Azure Backup registers the VM with the vault and installs an extension (AzureBackupLinuxWorkload) on the VM. It doesn't install any agent on the database.
- On successful deployment, you will be able to see below message on the notification icon.
Backup Configuration
- Clicking on view details highlighted below will show you the details of all the databases of each discovered VM.
- Clicking on view details will list the VMs that you choose earlier, and status should reflect as registered. You can also view the list of databases discovered in details section.
NOTE: During discovery or configuration of backup on the secondary node, ignore the status if the Backup Readiness state appears Not Ready as this is an expected state for the secondary node on HSR.
- Once the VMs are discovered, click on configure backup as shown in previous screenshot.
- In Backup Policy à Choose backup policy HANABKPPOLICY-TEST created under create/define backup policy.
- Then click on add button to add all the databases that are to be backed up.
- In Select items to back up, select all the databases you want to protect --> OK.
- Now click on enable backup as shown below and proceed.
- Once the backup is enabled, navigate to Backup items from Recovery Services Vault to view the Backup status of the HANA database in HSR.
NOTE: Once the backup is enabled, the backup status would be in Amber status with Warning (initial backup pending) until one full backup is completed.
- To check the current backup status and the available list of backups, click on view details under details tab in the above picture. It will take you to the page as shown below.
- This is the dashboard which is used to take adhoc backup (using backup now button), perform Point in Time (PIT) restoration (using restore button) or to stop the backup running for this tenant.
- Before any planned/unplanned failover occurs, ensure that both VMs/Nodes are registered to the vault (physical and logical registration). Otherwise, backups would fail upon failover of HANA database that is part of Hana System Replication (HSR).
- To verify the physical registration, go to the Recovery Services vault ---> Manage --> Backup Infrastructure ---> Workload in Azure VM.
- To verify logical registration, go to Recovery services vault --> Backup Items --> SAP HANA in Azure VM.
- Under HANA system, choose the name of the HANA instance.
Backup configuration Check
- Test the backup configuration of the HANA database with HSR by performing failover of the db.
- Currently s4adbvm0 serves as master (Primary) while s4adbvm1 serves as slave (Secondary).
- Check the status of backup jobs running on current Primary Node (s4adbvm0). go to Recovery services vault ---> Backup Jobs.
- All the jobs completed where running on the primary node s4adbvm0.
- Perform failover of HANA database using the SUSE Linux HA pacemaker cluster. On successful failover, s4adbvm1 becomes master (Primary) while the s4adbvm0 becomes slave (Secondary).
- Post successful failover, monitor the status of backup jobs running on current Primary Node (s4adbvm1). go to Recovery services vault ---> Backup Jobs.
- We can observe that all the jobs completed where running on the primary node s4adbvm1.
References
Backup Flow - Azure Backup Architecture for SAP HANA Backup - Azure Backup | Microsoft Learn
SAP NOTES
2756788 – Support Process Microsoft Azure Backup BackInt
1730932 – Using backup tools with Backint for HANA
- SAP Managed Tags:
2 Comments
