Checklist Document

High Availability and Disaster

Recovery Implementation for SAP
Systems

Checklist for Integration Validation

Dietmar-Hopp-Allee 16
D-69190 Walldorf
DATE
January.2012

© 2012 SAP AG
Checklist Document

High Availability and Disaster Recovery Implementation for SAP Systems – Checklist for
Integration Validation

1 Introduction

This document is a collection of aspects to be checked when validating the technical architecture of SAP
solutions running critical business processes. Those business processes typically require highly available
software, hardware and infrastructure components to protect against minor, often limited technical failures,
but also a disaster recovery strategy to protect against major failures.

The checklist consists of a series of questions which should highlight important aspects of highly available
and disaster aware technical architectures for SAP solutions. Due to the extent, variability and complexity of
the topic, the checklist cannot guarantee a functioning architecture, which meets all business requirements.

How to use this checklist?

The checklist is meant to be used in the integration validation phase, where the technical architecture of the
SAP solution is designed and probably implemented already. Each of the questions mentioned in the
checklist should be tracked by the customer and the embedded support. The questions will not directly point
to proposed technical solutions. However, they will point to important aspects, which should be covered
before entering the production phase with the SAP solution. If critical business processes need to be
supported by the solution and in addition some of the questions cannot be answered or are not covered yet,
or the architecture is very different to the best practices, then a detailed review respectively enhancement or
redesign of the solution should be planned with the help from SAP AGS services.

© 2012 SAP AG page 2/7

Checklist Document
High Availability and Disaster Recovery Implementation for SAP Systems – Checklist for
Integration Validation
2 Checklist
Prio Item
H Business Process Classification
 Are all core business processes and business
process steps with related technical
systems/components documented?
 Are classes of business criticality defined and
are related availability demands
documented?
 Are all core business processes assigned to
criticality classes and is this classification
signed-off with the business department?
M Business Continuity Workarounds
 Are workarounds available to support
business continuity of specific business
processes in case of system outages and are
they documented?
 Is it agreed with the business that these
workarounds are available and when they are
feasible?
H System Classification
 Is the SAP solution landscape documented?
 Is it documented, how critical business
processes are mapped to technical systems?
 Are availability-related non-functional
requirements (planned downtime, RTO, RPO)
documented for each system supporting
critical business processes?
 Do the availability-related non-functional
© 2012 SAP AG
Comment
Business processes should be classified into
classes according their criticality for the
business. Those 2-3 classes (e.g. mission
critical, business critical and business
foundation) should have different associated
availability requirements. Those availability
requirements are the foundation for the design
of the different technical high availability
solutions and for planning system operations.
The description of availability demands (also
called non-functional requirements) should cover
the following questions:
 What amount of planned downtimes is
available?
 What is the maximum accepted length of an
unplanned downtime (RTO, recovery time
objective)?
 What is the maximum accepted amount of
data loss, in terms of business activity time
(RPO, recovery point objective)?
RPO and RTO are typically distinguished for
different incident severities. A minor, more
frequent incident, like the failure of a technical
component, might have stronger availability
demands compared to a major incident, e.g. the
loss of a data center.
Workarounds to cover periods of system
outages are not always available or feasible.
However, if there are feasible workarounds for
specific business processes, they should be
documented and agreed by the business. They
could either be a safety net for mission critical
business processes in case of unplanned and
planned outages or might give reasons for less
stringent availability demands of the business
process in the SAP solution.
The availability demands of technical systems
result from and should be based on the criticality
of the business processes relying on the SAP
solution landscape. Technical systems
supporting critical business processes need to
implement technical measures to realize the
availability demands. Non-functional
requirements for the technical systems might be
stronger than those for the business processes,
since additional time might be required to
reestablish business operations after
page 3/7
Checklist Document
High Availability and Disaster Recovery Implementation for SAP Systems – Checklist for
Integration Validation
Prio Item
requirements of the technical systems match
the criticality class of the supported business
processes and their non-functional
requirements?
 Are the non-functional requirements of the
technical systems distinguished for different
failure types?
H High Availability Solution Implementation
 Is the high-level technical architecture to
ensure high availability of the solution
components documented?
 Is the implementation and configuration of the
technical high availability solution
documented?
 Is the set of technical hardware and software
components (SAP, database, OS, central
services like DNS, LDAP, file services, etc,
server hardware, storage hardware, network,
printers etc.) identified which carry the
potential of being a single point of failure
(SPOF) for the overall solution?
 Are all critical SPOFs documented and
protected by redundancy or failover
solutions?
 Is the data for critical business processes
stored in different locations (e.g. multiple
databases and file systems) and is
consistency of this data in case of technical
failures ensured?
© 2012 SAP AG
Comment
reestablishing the technical systems.
The distinguished failure types are typically:
 Failover
o Hardware or software failures, which are
usually mitigated with a failover solution.
o Data corruptions due to technical failures,
typically mitigated by data redundancy
solutions for the data, e.g. stand-by
databases.
 Major failures / disasters, leading to a
physical or logical loss of a data center.
Those failures are usually mitigated by data
redundancy in different locations,
accompanied with a strategy how to switch
over technically and from operations
perspective to a different data center.
 Failures requiring data restore and recovery
from backups.
 Optional: Logical handling or application
errors, e.g. wrong application code, wrong
transports, manual corruption or deletion of
data. They are usually mitigated by technical
measures to quickly rebuild a system with
valid data prior to the appearance of the
incident.
High-level technical architecture documentation
could considerably simplify the in-depth
validation of the high availability solution, while
the implementation and configuration
documentation is an important input for change
management and operations.
The complete identification of single points of
failures is essential to achieve a functioning high
availability solution without gaps. All critical
SPOFs should be protected by redundant
components or failover solutions. The
achievable RTO is determined by the details of
the chosen solution and its implementation. To
protect the most important asset of an IT
solution, measures to avoid data loss and
guarantee data integrity and data availability are
required. A vital prerequisite is an error-proof,
reliable backup and restore concept (see the
separate checklist). For environments where a
higher level of data availability and a smaller
RTO is needed, additional measures like local
data replication or standby databases are
possible. Since business critical data might be
stored in different locations (e.g. multiple
databases of connected SAP systems + files on
page 4/7
Checklist Document
High Availability and Disaster Recovery Implementation for SAP Systems – Checklist for
Integration Validation
Prio Item
 Does the architecture and implementation
comply with SAP and hardware partner best
practices?
 Is the high availability solution tested?
 Has it been verified that the non-functional
requirements can be met according to the
demands of the business (see RTO, RPO)?
 Is the functioning of the high availability
solution monitored?
 Is the staff trained in operating the high
availability solution?
 Are the operations procedures for the high
availability solution documented in detail
(“operations handbook”)?
H Disaster Recovery Solution Implementation
 Is all business data replicated to a secondary
location or is it possible to rebuild all data at a
secondary location?
 Depending on the implemented solution, is
the potential loss of data in case of a disaster
accepted by the business department (for
example in case of asynchronous data
replication)? (see definition of RPO)
 Are recent and complete data backups for the
SAP solution available at the secondary
location?
 Does the secondary location protect against
physical disasters in the primary location?
 Is there a plan how to utilize hardware in the
secondary location in a disaster case?
 Is all required software installed in the
secondary location?
 Is the high-level technical architecture for the
disaster case documented?
 Is the implementation and configuration of the
technical solution for the disaster case
documented?
 Is the procedure how to switch over to the
© 2012 SAP AG
Comment
file systems), measures to guarantee or achieve
consistency of these different data stores are
required. These measures influence both RTO
due to the potential time required to reestablish
consistency and RPO due to potential loss of
data.
Regular testing of the HA solutions is needed to
ensure operability of the solutions and to verify
achievability of the demanded non-functional
requirements.
Operating a solution with highly available
components requires procedures which take the
existence and the behavior of the solution into
account, e.g. because a cluster management
software has built-in rules how to react on
certain events, which might be accidentally
triggered by an operator. Typical relevant
procedures are:
 Starting and stopping of components
 Switchover and switchback procedures
 Maintenance of components
 Error analysis and resolution procedures
For a disaster recovery solution, a secondary
location which protects against physical
disasters is commonly required. Keeping
backups and logs in a safe, secondary location
is a typical minimum requirement. For tight RTO
and RPO demands in the disaster case,
additional data replication solutions to the
secondary site are required to achieve a quicker
restoration of the solution in case of a disaster at
the primary site. Synchronous and
asynchronous replication options are available.
Maintaining secondary copies of data with
asynchronous replication mechanisms may be
subject to data loss and the achievable RPO is
an important design criterion. Special attention
should be laid on measures to maintain or
reestablish data consistency between systems
in a distributed solution landscape. However,
asynchronous replication might be necessary to
achieve a decent performance when longer
distances have to be covered by the solution.
Since switchover and switchback procedures for
disaster recovery are rarely executed, they need
to be documented in detail and regularly tested
to ensure operability of the solution and provide
operational experience and training for the staff.
page 5/7
Checklist Document

High Availability and Disaster Recovery Implementation for SAP Systems – Checklist for
Integration Validation

Prio Item Comment

secondary location and how to switch back
described and tested in detail?
 Is the functioning of the data replication and
the availability of the disaster solution
monitored?
 Is the staff available in the secondary solution
and is it trained in the switchover and
switchback procedures?
H Tests Failures in the high availability and disaster
recovery solution can quickly disrupt operability
 Are test cases covering the verification of the of the whole solution, leading to prolonged
high availability and disaster recovery recovery times in case of contingencies.
solution documented and do they comply with Therefore intensive testing is required especially
SAP or partner best practices? for maintenance activities, e.g. changes in the
 Is a test environment besides the production technical infrastructure or changes applied to
systems available, where new technical technical components.
changes can be applied and where the test
cases can be executed?
 Are the test cases executed before and after
maintenance-related changes to the
production systems?
 Are documented backup and recovery
procedures frequently tested?
 Are documented operations procedures
frequently tested?

© 2012 SAP AG page 6/7

Checklist Document

High Availability and Disaster Recovery Implementation for SAP Systems – Checklist for
Integration Validation

© 2012 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, and other SAP products and
services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other
countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered
trademarks of Business Objects Software Ltd. Business Objects is an SAP company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks of Sybase, Inc. Sybase is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document
serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (“SAP
Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.

© 2012 SAP AG page 7/7