Lesson 4 of 5
Testing failover and restore
9 min
Listen to this lesson
A recovery design that has never been tested is an assumption. Testing is where the quality mindset of this Academy matters most for Basis: define what success means before the test, run it under realistic conditions, measure what actually happened, and record the evidence. A failover that 'worked' because the database came up, while three interfaces silently failed for a day, did not work.
Kinds of recovery tests
| Test | What it proves | Notes |
|---|---|---|
| Planned HA takeover | Cluster and procedure move production to the standby within the HA RTO | Run in a maintenance window; under RISE via SAP ECS |
| Unplanned HA failure simulation | Automatic detection and takeover work without people | Usually in a non-production pair built like production |
| DR failover test | The secondary site can run the business within the DR RTO | SAP's R&R: on request, production only, at most one per calendar year included; changes made during the test are lost; the customer creates and executes the functional tests |
| Online DR test (fencing) | The DR copy can be started and checked while the primary keeps running | Listed in SAP's R&R as an additional service; not available for every DR offering |
| Restore test | Backups can be restored to a point in time and the data is consistent | SAP restores on request (the R&R includes up to six restores per SID per contract year); validating the restored data is the customer's task |
Recovery tests and what each one proves. Check your own contract for entitlements and lead times.
- PlanScope, success criteria, roles, window, communication, rollback plan
- PrepareService request to SAP ECS; test cases for key processes; interface partners informed
- ExecuteFailover performed; timestamps recorded for every step
- VerifyTechnical checks, then business test cases on the DR site
- Fail backReturn to the primary; verify again
- ReportAchieved RPO and RTO, issues, remediation, sign-off
Success criteria that mean something
- Time: service available to users within the RTO, measured from declaring the disaster to releasing users.
- Data: the last committed transaction on the DR side is within the RPO; check a known transaction posted just before the cut.
- Processes: agreed test cases run end to end: Maria's sales order to delivery to billing in sales area 1710 / 10 / 00, Dan's journal entry and a payment run in company code 1710.
- Connections: each critical interface sends and receives; printers and output work; SAP Fiori launchpad reachable.
- Jobs: background jobs run on the DR side and do not run twice after failback.
Plan the year rather than one heroic test. Contoso schedules a restore test into a sandbox each quarter, a planned HA takeover in the regular maintenance window twice a year, and one full DR failover per year in a quiet weekend outside the month-end close. Each test has its own success criteria and report, and the findings of one feed the plan for the next.
What would you do?
Contoso's first DR failover test is scheduled. SAP ECS will perform the technical failover of CMP. Priya asks what her team should prepare. What is the best answer?
- Test HA takeovers, DR failovers and restores; each proves something different.
- Under RISE, SAP executes the technical failover on request; the customer creates and runs the functional tests.
- Success criteria cover time, data, processes, connections and jobs, measured with timestamps.
- DR test postings are lost; plan interfaces and duplicate prevention before the test.
Check your understanding · not graded
Lesson check
1. According to SAP's RISE R&R, who creates and executes the functional tests in a DR failover test?
2. What happens to data posted during a DR failover test, according to SAP's R&R?
3. How can a DR test verify that the RPO was met?
4. Who validates the logical consistency of restored data after a restore under RISE?