Best Practice 10.3 – Define an approach to help ensure the availability of critical SAP data

The business data for an SAP application is primarily stored within the database, but may also include file-based data or binaries (for example, executables, libraries, scripts, configuration, and interface files).

Suggestion 10.3.1 – Evaluate MTTR requirements and identify how they can be met

In [Reliability] Suggestion 10.1.5 – Define minimum acceptable percentage uptime, you will have defined the MTTR requirements for each of your applications. Having assessed the risk of failures and the mechanisms for protecting system availability, confirm your requirements can be met, and document the expectations for MTTR against each failure scenario. If compromises need to be made for cost, complexity, or consistency, consult with the business owners to reach an agreement.

Suggestion 10.3.2 – Determine in which failure scenarios a recovery from backup would be necessary

Backup is often a secondary mechanism for ensuring or recovering availability, but most architectures will have some reliance on backups. The following are examples of failure scenarios that could be used to guide your analysis. The granularity of the scenarios, classification, and impact will vary depending on your requirements and architecture.

Suggestion 10.3.3 – Determine where data replication is required

Data replication is used to improve reliability by having copies of the same data in multiple locations and is often a requirement for systems with a low RPO. When determining whether replication is required for availability or recovery, consider whether the service is Zonal (for example, Amazon EC2 and Amazon EBS and the databases they support) or Regional (for example, shared storage and Amazon S3).

Suggestion 10.3.4 – Build a strategy to ensure consistent configuration data and binaries

It is important to have consistent configuration data and binaries to help ensure predictable behavior and a tested setup following a failure. This can include operating system packages, application parameters, and cluster configuration. Determine how you could ensure alignment across all instances for an application, including those which are there for resilience (for example, additional application servers, secondary database nodes).

Amazon EFS, Amazon FSx, and Amazon S3 provide a durable location for shared binaries or configuration that can be managed centrally.

Refer to [Operational Excellence] Best Practice 2.1 - Use version control and configuration management pillar for mechanisms to control versions and manage configuration.

Suggestion 10.3.5 – Have a holistic approach to data consistency

The approach to ensuring the consistency of critical SAP data should not only focus on a single set of data but also should consider the dependencies within and between datasets and systems. For example, if you need to recover an SAP BW system, but not the source systems it pulls from, what would be the impact on change pointers and what mechanisms are in place to ensure a consistent recovery?

Suggestion 10.3.6 – Build a strategy for interfaces that permits data to be replayed or re-sent

For data exchange between systems, determine whether the integration is loosely coupled and if data can be replayed or re-sent, either at the source or target. Review if there are queuing capabilities to allow the scenario to be suspended or cached during an outage.

Suggestion 10.3.7 – Evaluate the use of a data bunker

Failure scenarios that result in the online data becoming unusable or unavailable due to situations such as accidental deletion or a malicious act might require a different approach to help ensure that data is protected or recoverable.

Although prevention is the best defense through a security framework covering network isolation and access control, the impact should be considered in the context of recovery and resilience.

Using a write only backup account with a reduced retention period is a common approach for this rare but potentially high impact scenario.