SAP · Infrastruttura · YoctoIT tech page

HA & DR

Real RTO and RPO for the company's most critical system: clusters, replicas and disaster recovery plans actually tested.

FOCUS · ERP CONTINUITYHSR, Pacemaker clusters and geographic DR: continuity is designed and rehearsed
YoctoIT material for clients and partners · SAP, S/4HANA, HANA, BTP and the other products mentioned are trademarks of SAP SE o di sue affiliate.
01 · What it is

Alta affidabilità & DR SAP, made clear.

If SAP stops, the company stops: orders, shipments, invoices. ERP continuity is built in layers — a local cluster for the single failure, geographic replication for the disaster, and periodic rehearsals, because an untested DR is a hope, not a plan.

RPO 0
with synchronous HANA System Replication in the campus
RTO <1h
the typical target of our plans, measured in tests
2 tests/year
the minimum to call a disaster recovery a 'plan'
Alta affidabilità & DR SAP
OFFICIAL SAP BRANDING · HA & DR
SCHEMA UFFICIALE · CLUSTER HA SAP HANA · FONTE: RED HAT DOCS
OFFICIAL DIAGRAM · SAP HANA HA CLUSTER · SOURCE: RED HAT DOCS
02 · How to use it well

The things that make the difference.

The three layers

SAP applicationASCS/ERS protected by the cluster
Local HA cluster
Synchronous HSR
Asynchronous DR replication
failure · campus · geography
Failover runbookwho does what, written and rehearsed
Documented periodic teststhe evidence for audits and insurers
From node failure to site disaster

Cluster ASCS/ERS

The application single point of failure protected with Pacemaker: the lock server that doesn't die.

Multitier HSR

Synchronous + asynchronous replication chained: HA and DR with a single native technology.

DR to the cloud

The secondary site in the cloud when there's no second data center: the pragmatic hybrid shore.

Failback included

Coming back is half the plan: we write it and rehearse it like the way out.

03 · In depth

Anatomy of the SAP cluster

The HA chain of an SAP system has three links: ASCS/ERS protected by Pacemaker with SAPInstance resources and anti-collocation rules (ENSA2), the database in native replication (HSR for HANA) orchestrated by SAPHanaSR/angi with automatic takeover, and the highly available shared filesystem (/sapmnt). DR adds the third site or the asynchronous tier: continuous log replay, RPO in seconds, and the geographic failover runbook with the DNS/virtual IP sequence.

  • ENSA2 — Standalone Enqueue Server 2: the lock server reborn on another node without losing locks
  • SAPHanaSR-angi — the modern resource agent for HSR: automatic takeover with verified fencing
  • Fencing/SBD — STONITH always on: a cluster without fencing is an incident waiting to happen
  • Multitier HSR — sync in campus + async geographic chained: HA and DR with one technology
  • Log replay — the standby applies logs continuously: takeover in minutes, not hours
  • Twice-yearly rehearsals — switchover and failover documented with minutes: NIS2 and insurers served
04 · Numbers and lifecycle

The numbers that matter.

RPO 0
synchronous in the campus (up to ~100 km of fiber)
RTO <15'
the typical HANA takeover with SR and well-tuned agents
2
the failover tests per year we consider the professional minimum
3
the protected links: enqueue, database, filesystem
SAP high availability is a chain: it breaks at the link nobody rehearsed — we rehearse them all, twice a year.
05 · Use cases

Where it really pays off.

NIS2 compliance

ERP continuity among the requirements: documented evidence and tests.

Mergers and carve-outs

Continuity through corporate transformations.

Critical seasonality

The peak that cannot fall: the campaign, the harvest, Black Friday.

SAP DR is our favorite final exam: we pass it twice a year, with your data.