Tutorial · 2026

SAP HANA Backup and Disaster Recovery on Azure: Field Guide

Back up SAP HANA on Azure VMs with Azure Backup Backint streaming, disk snapshots, or native files; compare cross-region DR, RPO/RTO numbers, and costs.

intermediate 14 min read Updated Nov 8, 2026

30-second summary

  • Log frequency sets RPO: Azure Backup documents a 15-minute minimum for SAP HANA streaming.
  • Snapshots speed recovery, but weekly full plus log backups remain mandatory per SAP advisory.
  • Secondary-region RPO via Cross Region Restore is 12 hours plus log frequency; plan accordingly.
  • Documented RTOs are relative; Microsoft publishes no absolute restore-time guarantee for HANA.
Contents

HANA is running on Azure VMs, System Replication is clustered, and the landing-zone review is done. The next question every basis team gets is boring and brutal at once: when this database dies, what do we restore from, from where, and how long does the business wait? We spent recent weeks rebuilding our SAP HANA backup and disaster-recovery story on Azure, and this is the map we wish we had started with. Every number below comes from official Microsoft or SAP documentation checked on 2026-11-08; where no documented answer exists, we say so instead of inventing one. Start with deploying SAP HANA on Azure if you have not — this guide assumes a supported VM, a sized database, and ideally an HSR pair.

What Azure Backup for SAP HANA Actually Supports

Azure Backup protects SAP HANA on Azure VMs through an SAP-certified Backint agent: zero-infrastructure, streams into a Recovery Services vault, supports M-series VMs. Being on SAP’s certified Backint list is what keeps supportability conversations with SAP short. The same service also protects VM-level disks; the docs recommend running that once a day to cover OS and non-database disks, with selective-disk restore for file-level pulls.

The support matrix (updated 2026-10-09) is narrower than people expect:

  • Topology: Azure VMs only; HANA Large Instance (HLI) is not supported by this workload.
  • Operating systems: SLES for SAP 12 SP2–SP5, 15 SP0–SP7, 16.0; RHEL at listed 8.1–10.0 service-pack levels. Ubuntu appears nowhere in the supported list, and any distribution past vendor end-of-support is out.
  • Database versions: HANA 1.x single-tenant (SDC) and HANA 2.x multitenant (MDC) from SPS 04 to SPS 08 (SPS 05 qualified up to revision 59, SPS 06 validated with encryption enabled).
  • Scale: databases up to 40 TB — a size limit, not a memory limit. One HANA instance per VM is protected at a time; MCOS combinations work with caveats, but HSR + HSR on one host does not.
  • Backup types: full, differential, incremental, log, instance snapshots. Scheduled fulls: one per day; on-demand fulls: three per day recommended, nine hard. Cross-subscription restore is supported (portal, CLI); cross-tenant restore is preview, vaulted restore points only.
  • Scale-out systems: preview; streaming only (no instance snapshots); up to 32 nodes, all in the vault’s region, matching software update versions.

Exclusions that burned planning time: HSR combined with the DR scenario is unsupported, asynchronous HSR is unsupported, you cannot restore into an HSR instance (restore standalone, re-establish replication), and log shipping/OLR does not cover HSR pairs.

Three Backup Paths, and Which One You Actually Want

Path 1: Streaming Backint backups to a Recovery Services vault

This is the default production path. The Azure Backup extension installs an agent under /opt/msawb, registers the database, and drives full and differential backups through Backint; the HANA engine itself triggers log backups at the configured frequency (15-minute minimum). Catalog and data stream into vault storage — internally an Azure Storage account — so disk throughput, VM network, and any firewall or NVA in the path set the ceiling. The service targets roughly 420 MB/s for non-log backups and 100 MB/s for logs; multi-streaming (up to 32 channels via parallel_data_backup_backint_channels) raises documented throughput to about 1.5 GB/s, but only on VMs with at least 16 vCPUs and 128 GB RAM, and only for data backups above 128 GB.

Before registration passes, preregistration has to: vault in the same region and subscription as the VM; combined VM-name-plus-resource-group length under 84 characters; and an hdbuserstore key aimed at the right SQL port — nameserver for MDC, indexserver for single-tenant. That asymmetry caused our first failed preregistration. In a terminal as <sid>adm:

hdbuserstore Set SYSTEM <hostname>:3<InstanceNumber>13 SYSTEM <password>
cd /opt/msawb/bin
./msawb-plugin-config-com-sap-hana.sh -a --sid HDB -n 00 --system-key SYSTEM
hdbuserstore list

The script creates AZUREWLBACKUPHANAUSER and needs DATABASE ADMIN plus BACKUP ADMIN roles on MDC (2.0 SPS 05 and later). If your root partition is small, note the warning the docs carry: /opt/msawb needs about 4 GB and the check fails on 2 GB root filesystems. To keep a large backup from saturating the VM’s network, you can throttle the agent by dropping a ExtensionSettingsOverrides.json file with {"MaxUsableVMThroughputInMBPS": 120} into /opt/msawb/bin, owned root:msawb, mode 750 — no restart needed.

Path 2: Native HANA backups to disk

Not everything should go through an agent. SAP’s own BACKUP DATA USING FILE mechanism writes complete database and log files to the VM filesystem or an NFS-mounted share, and Azure’s docs acknowledge the pattern: on-demand backups from the HANA native client can target the local file system, and catalog pruning (BACKUP CATALOG DELETE) is your job. We keep a nightly native file backup as a belt-and-braces copy independent of Azure Backup, and it doubles as the input for the restore-as-files drill below. Caveat: your own recovery catalog stays authoritative when you maintain native backups, and mixing it blindly with the service’s catalog is where restore confusion starts.

Path 3: Instance snapshot backups

Snapshot-based backup takes managed-disk snapshots (first full, then incremental changed blocks) coordinated through SAP HANA’s native snapshot APIs, which quiesce database I/O while the snapshot is taken. Recovery is nearly instant for the baseline because you restore disks, not data — but the logs are not inside the snapshot. Log backups keep streaming through Backint, and SAP’s advisory is blunt: the database must already be configured for weekly full plus log backups through Backint before you enable snapshot protection, and only differential-or-incremental, never both. Snapshots land in a resource group you own and are billed as Standard-HDD managed-disk snapshots on top of your streaming costs; a Standard policy (GA) or an Enhanced policy (preview) that pulls the snapshots into the vault — gaining immutability, soft delete, and cross-region restore — are the two flavors, and HSR systems need the Enhanced preview flavor. Snapshot policies run daily only (default 22:30 UTC), and instant-restore retention is configurable from 1 to 35 days. The RBAC setup is easy to miss: the source VM’s system-assigned identity needs Disk Snapshot Contributor on the snapshot resource group, and the Backup Management Service must be granted the same role manually.

Cross-Region Backup and Regional Disaster Recovery

Azure Backup replicates backup data only between paired regions — the DR overview guide says it explicitly, and it is the single most load-bearing sentence for regional DR design. Concretely you have four levers, and you pick by RPO, not by preference:

  1. Vault redundancy. Choosing GeoReplicated (GRS) or RA-GRS storage for the vault keeps a replica in the paired region; the backup pricing docs note GRS suits the highest availability and compliance needs, while RAGRS is what Cross Region Restore costs are tied to. Local-redundancy vaults give you nothing regionally.
  2. Cross Region Restore (CRR). Enabled at vault level, CRR lets you restore HANA databases into the secondary paired region during a primary-region outage. Documented catch that reframes the whole feature: the secondary-region copy’s RPO is 12 hours plus your log-backup frequency (minimum 15 minutes). CRR restores are secondary-to-secondary only, the vault and a registered HANA server must already exist in the secondary region, and a running restore job cannot be canceled once the data-transfer phase begins. CRR and cross-subscription restore are not supported together.
  3. HANA System Replication. For anything tighter than hours, the DR guidance points at native database replication — for HANA that is sync-mode HSR into another region, accepting that region distance raises latency and can push sync replication to its limits. Remember the backup-service caveats: HSR combined with the Azure Backup DR scenario is unsupported, so HSR is your DR mechanism and backups stay a separate, single-chain concern (Azure Backup does model both HSR nodes as one logical container).
  4. Azure Center for SAP Solutions (ACSS). If your systems are managed through ACSS, the CEDR (customer-enabled disaster recovery) documentation describes re-registering virtual instances after a region outage, with New-AzWorkloadsSapVirtualInstance covering the service-region-down case. The documented guidance chains back to the same DR overview guide for the workload side.

One gap worth stating out loud: the Azure Site Recovery Azure-to-Azure support matrix carries no SAP HANA-specific guidance as of 2026-11, and we found no official Microsoft-backed path to point native HANA backups directly at your own storage account via Backint — vault storage is the documented target. Anything else you see about ASR-for-HANA comes from third-party agents, which is outside this guide’s evidence bar.

RPO and RTO: The Official Numbers, As of 2026-11-08

What is actually documented:

  • Minimum RPO for HANA streaming backup is set by log-backup frequency: 15 minutes is the documented floor. Logs only start flowing after the first successful full backup.
  • Secondary-region RPO for CRR is 12 hours plus that log frequency.
  • No absolute RTO is published for HANA restore via Azure Backup. What Microsoft publishes is a relative policy trade-off in the FAQ: daily full plus logs gives the fastest recovery and the highest storage cost; weekly full plus daily differentials is slower but cheaper; weekly full plus daily incrementals is the slowest chain to replay (one full, plus n incrementals, plus logs) and the cheapest. Snapshots move the baseline portion to near-instant disk restore, with log replay on top.
  • Restore throughput is documented as slower than backup throughput, capped around 420 MB/s per stream by default, so size your realistic recovery window from database size divided by throughput, then add log replay.
  • Hard operational limits: a maximum of 10 restores per HANA instance per day (failed and canceled jobs count), instant tier retention 1–35 days, minimum retention 7 days for any backup type, incremental retention capped at 180 days, and log retention commonly set between 7 and 35 days.

Anything promising “HANA restore RTO under X hours” as a Microsoft guarantee is, as of this date, not documented. Treat published throughput ceilings as planning inputs, and measure your own RTO in a drill.

What Tripped Us Up

Four documented surprises that cost us real time, all straight from Microsoft’s own pages:

  • The HSR secondary-node user lock. Azure Backup periodically pings every registered instance. A secondary node in an HSR pair accepts no connections, so those pings fail; failures can accumulate and lock the backup user, and then backups on the primary start failing with an ODBCConnectionError. The FAQ recommends stopping protection on a node while it is secondary and resuming when it flips back. Our alert fatigue on a test pair decoded once we understood this loop.
  • NAMESERVER versus INDEXSERVER in the key. Preregistration validates the hdbuserstore key’s target port: nameserver SQL port for multitenant databases, indexserver port for single-tenant. Pointing an MDC key at the wrong service fails prereg with an unhelpful message.
  • /opt/msawb on a small root partition. The 4 GB requirement versus a 2 GB root filesystem is a documented warning that arrived too late for our first VM image.
  • No daylight-saving auto-adjust. Backup schedule times do not follow DST; the policy needs a manual edit, or your 02:00 full quietly becomes a 03:00 full for half the year.

Failover Drill Checklist

We run this annually, timed, with a stopwatch on business-critical queries. Microsoft’s own DR guidance insists DR plans be tested, documented, and tuned regularly — the compliance docs even frame an annual exercise as the baseline expectation.

  1. Confirm protection health: Backup readiness in Configure protection shows green, the last full succeeded, logs are flowing within your 15-minute window, and vault infra-encryption and soft-delete posture are as designed.
  2. Validate alternate-location restore: restore a tenant database to a scratch VM registered to the same vault in the same region, then run the application smoke suite against it.
  3. Drill restore-as-files: run a native BACKUP DATA USING FILE full plus logs, stage them on NFS (not CIFS), regenerate the catalog with hdbbackupdiag --generate --dataDir <dir> --logDirs <dirs>, fix ownership with chown -R <SID>adm:sapsys, then recover to a point:
RECOVER DATABASE FOR DHI UNTIL TIMESTAMP '2022-01-12T08:51:54.023'
USING CATALOG PATH ('/restore/catalo_gen') USING LOG PATH ('/restore/Log/')
USING DATA PATH ('/restore/Data_2022-01-12_08-51-54/')
USING BACKUP_ID 1641977514020 CHECK ACCESS USING FILE
  1. Exercise CRR: keep a vault and a registered HANA server in the paired region, restore a non-critical database secondary-to-secondary, and remember the job is uncancelable during data transfer — do it on a test instance.
  2. Test HSR takeover separately from restore: with cluster automation, set AUTOMATED_REGISTER=false only during failover tests (so a failed primary cannot sneak back as secondary), force takeover, verify connections through the virtual IP, then set it back to true as the HA guide directs.
  3. For MDC systems, re-run the preregistration script after restoring the system database before restoring tenant databases.
  4. Measure everything: log the time from “declare incident” to “application accepts users” as your empirical RTO, and the newest restored transaction versus the failure moment as your achieved RPO.
  5. Clean up: stop protection on test instances deliberately (Stop Backup with retain or delete data as fits), never leave abandoned protection that keeps failing on dropped databases, and watch the 10-restores-per-instance-per-day budget when rehearsals multiply.

The Cost Line Items, Mapped to Reality

The pricing documentation decomposes into the same buckets we ended up budgeting against; per-GB and per-instance rates change by region and over time, so we deliberately quote no dollar figures here — use the downloadable pricing estimator, which supports SAP HANA in Azure VMs, for current rates:

  • Protected-instance charges: per protected database instance, which is why HANA instances per VM and MDC layouts change the bill.
  • Backup storage charges for vaulted (streaming) data, with the documented inputs being full size per database, daily log size as a percentage of database size, daily churn, retention settings, and log retention between 7 and 35 days. Weekly-full plus daily-differential policies are called out as the effective balance of cost versus recovery speed.
  • Snapshot storage: charged as managed-disk snapshots (Standard HDD tier regardless of source disk type, incremental after the first full) in your own subscription — money on top of vault charges, not instead of it.
  • Redundancy premium: GRS/RA-GRS vault replication and CRR restore capacity are regional-availability line items.
  • Compression: enabling HANA native compression in the backup policy directly reduces vaulted GB.
  • VM backup: the once-daily VM-level protection of OS and non-database disks is billed separately from the HANA workload.

What This Guide Does Not Cover

Honest boundaries, in case you are sizing this against a compliance requirement. No HANA Large Instance (HLI) or third-party Backint agent content — neither is in Azure Backup’s support matrix for this workload, and vendor agents are their own documentation world. No NetWeaver application-tier or ASCS/ERS backup, no RISE with SAP provider-managed backup detail — see our RISE with SAP on Azure guide for that operating model — and no cross-cloud comparison of backup economics, which lives in SAP on Azure versus AWS. No actual prices (region- and time-dependent), no SAP Note text (SAP note 1642148 governs cross-platform restores and sits behind the SAP paywall), and no absolute RTO guarantees, because none are published.

FAQ

Can snapshot backups replace the weekly full backup through Backint?

No. The documentation is explicit that snapshot-based protection requires the database to already be configured for weekly full plus log backups via Backint — otherwise snapshot configuration fails. Snapshots accelerate the baseline restore; the streaming chain remains the consistency backbone, and logs are never embedded in the snapshot.

What is the best RPO Azure Backup can give a SAP HANA database on an Azure VM?

The documented floor is a 15-minute log-backup frequency, so plan on 15 minutes as best case for same-region recovery, with logs starting only after the first successful full. Anything tighter than that is a job for synchronous HANA System Replication, not for backup.

Can I restore a database into a different subscription or a different region?

Different subscription: yes — cross-subscription restore is supported for streaming (Backint) backups, enabled by default, portal or CLI. Different region: Cross Region Restore into the paired secondary requires a vault and registered server there, and its secondary copy is documented at 12 hours plus log frequency. CRR and cross-subscription restore cannot be combined, and snapshot-based restore points do not support CSR.

Does Azure Site Recovery protect my SAP HANA database instead of Azure Backup?

We found no SAP HANA-specific guidance in the Site Recovery support matrices as of 2026-11. The documented regional-DR mechanisms for the database are Azure Backup replication between paired regions and native HANA System Replication; the DR overview guide treats those as complementary, not interchangeable.

References

All pages reachable and checked on 2026-11-08. Where the page shows a last-updated stamp, it is noted.

Next steps

Backup strategy is architecture, so it belongs in your Azure landing zone for SAP review alongside network and identity decisions. More SAP-on-Azure operations write-ups live in the cloud category and across /tutorials/ — and when you are weighing regional pairs and DR economics against another hyperscaler, our Azure-versus-AWS comparison is the companion read.