Backup for SAP Application Servers
Configure Azure VM backup for SAP application servers with crash-consistent and application-consistent snapshots, back up transport directories and ASCS shared storage, and manage restore testing with Backup Center.
Beyond the database
🔧 Aisha reviews her backup plan. “HANA backup is sorted. But the SAP system is more than just the database. We have application server VMs, the transport directory, ASCS shared storage, and SAP configuration files. All of these need protection too.”
Carlos asks. “Can we use the same Azure Backup approach for the VMs?”
🔧 Aisha nods. “Yes, but with an important caveat — VM backup works differently from HANA Backint. Let me explain the differences.”
Think of VM backup like photographing an entire room vs. a single painting.
HANA Backint is like carefully photographing a painting (the database) with perfect lighting — every detail captured precisely. VM backup is like taking a photo of the entire room (OS, apps, files, everything). The room photo is good enough for most purposes, but if the painting has wet paint (active writes), the photo might show a smear. That is the difference between crash-consistent (room photo) and application-consistent (careful painting photo with paint dried).
Azure VM backup for SAP
Crash-consistent vs application-consistent
| Feature | Crash-consistent | Application-consistent |
|---|---|---|
| How it works | Snapshots all disks simultaneously — captures whatever is on disk | Quiesces applications (VSS/scripts) before snapshot |
| In-flight writes | May have incomplete I/O — same as power failure | All writes flushed and completed before snapshot |
| SAP application servers | Sufficient — app state recovers from the database on restart | Better but not required for most SAP app servers |
| Windows | Default if VSS fails | Default with VSS integration |
| Linux | Default if no pre/post scripts | Requires custom pre/post scripts |
| Restore behavior | VM boots in a crash-recovery state | VM boots cleanly with consistent application state |
For SAP application servers, crash-consistent backup is acceptable because:
- SAP application servers are stateless — all persistent data is in the HANA database
- On restart, SAP reconnects to the database and resumes operations
- Work processes recover automatically from the message server
- The only risk is losing in-flight batch jobs, which can be restarted
SAP quiesce consideration
If you need application-consistent backup for SAP application servers on Linux, you must create custom pre-backup and post-backup scripts that stop SAP services before the snapshot and restart them after. This adds complexity and brief downtime during backup. For most SAP deployments, crash-consistent backup of application servers is the pragmatic choice.
Transport directory backup
The SAP transport directory (/usr/sap/trans) contains transport requests — packages of changes moving between SAP systems (dev to QA to production). Losing the transport directory can derail an entire release cycle.
Backup approaches:
- If transport directory is on ANF: use ANF snapshots for fast backup
- If transport directory is on NFS Azure Files: Azure Backup supports Azure Files shares directly
- Include the transport directory mount in your backup policy
- Retain transport backups long enough to cover your release cycle
ASCS shared storage backup
ASCS shared storage contains SAP instance profiles, global directory, and cluster configuration:
- ANF volumes: Back up with ANF snapshots
- Azure Shared Disk: Backed up as part of the VM backup (the shared disk is included)
- NFS Azure Files: Azure Backup for Azure Files
🔧 Aisha checks her list. “The key principle is that every piece of SAP-related storage has a backup path. Nothing falls through the cracks.”
Restore testing
Backup without tested restore is false confidence. Implement regular restore testing:
- Quarterly VM restore test: Restore an application server VM to an isolated VNet and verify it boots and connects to SAP
- Monthly HANA restore test: Restore HANA to a non-production VM using PITR and verify data consistency
- Annual full DR restore: Restore the complete SAP landscape in the DR region using GRS backup
- Document results: Actual restore time, data consistency verification, issues found
Backup Center monitoring
Azure Backup Center provides a single-pane-of-glass view across all backups:
- Dashboard showing backup health across all vaults
- Failed backup alerts and remediation guidance
- Compliance reports for auditors
- Policy management across multiple vaults
- Export backup reports for Carlos’s weekly executive summary
Exam tip: Backup Center vs individual vaults
If the exam asks about centralized backup monitoring across multiple SAP systems or vaults, the answer is Azure Backup Center. It aggregates all vaults into a single view. Individual vault monitoring works for single systems, but enterprise SAP landscapes need the centralized approach.
Knowledge check
Aisha needs to back up SAP application servers on Linux. Which backup consistency level is sufficient?
Carlos asks Aisha to monitor backup health across all 15 SAP systems in a single dashboard. What should she use?
Summary
You now know how to back up the complete SAP landscape: HANA with Backint (previous module), application servers with crash-consistent VM backup, transport directories with ANF snapshots or Azure Files backup, ASCS shared storage included in the storage-level backup strategy, and centralized monitoring with Backup Center. Regular restore testing validates the entire backup chain.
Next, we move to security — protecting SAP from threats, encrypting data, and managing identity.