Operating an SAP System After Go-Live: Backup, Patching, and Monitoring
Six months after go-live, an SAP S/4HANA system on Azure HANA Large Instance-class VMs shows three operational problems. First, the nightly backup job, which uses a third-party agent writing to a storage account, now takes 9 hours against a 6-hour window and occasionally fails. Second, the customer applied an SAP kernel patch without testing and the application servers failed to start, requiring a four-hour rollback. Third, the monitoring team reports that they only learn about problems when users call, and that Azure platform maintenance events have twice caused unplanned application server restarts. The customer asks for a list of fixes.
1. Diagnose the backup window overrun and recommend a backup architecture for the HANA database and the application servers.
Read the worked answer
The overrun is most likely caused by an agent-based file-level backup reading the entire database through the VM's network stack, which competes with application traffic and scales poorly as the database grows. A 9-hour runtime against a 6-hour window with intermittent failures suggests throughput saturation and possibly snapshot or VSS contention, not a single fixable setting.
Recommended architecture:
- HANA database: use SAP HANA native backup to a Backint-compatible interface, or take storage-level snapshots where the platform supports them, and copy the resulting backup to a storage account or Azure Backup vault. Native HANA backup uses HANA's own parallel channels and is the supported mechanism; it also produces a backup catalog that HANA recognizes for recovery.
- Application servers: these are largely stateless and can be protected with Azure Backup at the VM level, with a schedule that does not overlap the database backup.
- Separate the backup traffic from the application subnet, and size the storage account or vault throughput so that the backup can complete within the window with headroom.
- Validate restores on a schedule; an untested backup is not a backup.
The fix is architectural: move the database to a HANA-native or snapshot-based path, keep VM-level backup for the application tier, and re-measure the window after the change rather than tuning the existing agent.
2. Address the failed kernel patch and the monitoring gap, including how Azure platform maintenance should be handled.
Read the worked answer
Kernel patch failure: the root cause is process, not technology. SAP kernel patches must go through the same path as any transport: apply in a development or sandbox system, run a smoke test that includes starting the application servers and a dialog transaction, then promote to quality and production. Maintain a documented rollback that preserves the previous kernel binaries and the corresponding profile backup. A four-hour rollback is a symptom of an undocumented change; with the prior kernel retained, rollback is a file restore and restart.
Monitoring gap: the customer needs alerting that does not depend on user reports. At minimum:
- SAP-level monitoring through SAP Solution Manager or SAP Focused Run, or an equivalent, for dialog response time, work process availability, and update failures.
- Azure Monitor alerts on VM availability, CPU, memory pressure, disk latency, and backup job completion.
- A synthetic or scripted check that logs on and runs a transaction at intervals, so a hung system is detected before users notice.
Azure platform maintenance: use scheduled events to receive advance notice of host maintenance, and configure the application servers so that maintenance does not cause an outage. That means placing application servers in an availability set or across availability zones, and putting them behind a load balancer so that a restart of one instance does not interrupt users. For the database, maintenance handling depends on the HA configuration; a single-node database VM will always incur an outage during host maintenance, which is the argument for a standby node. Finally, subscribe to Azure service health alerts so maintenance and incidents reach the operations team directly.