Passive Disaster Recovery for SAP applications using AWS Backup and AWS Backint Agent

Introduction

A Disaster Recovery (DR) solution is an important aspect of SAP system design. For customers running their SAP workloads on AWS, some of the key considerations for the design of the DR solution are single or multiple AWS Region or Availability Zones, Service Level Agreements such as Recovery Point Objective (RPO) and Recovery Time Objective (RTO), and cost. To make it easy for you, SAP Specialist Solutions Architects have come up with Architecture Guidance for Availability and Reliability of SAP on AWS. This guide provides a set of architecture guidelines, strategies, and decisions for SAP customers and partners who have a requirement for deploying SAP NetWeaver-based systems with a highly available and reliable configuration on AWS

The document High Availability and Disaster Recovery Options for SAP HANA on AWS describes all options for DR setup for SAP HANA databases on AWS, such as HANA System Replication (HSR) with data preload on or off, and backup and restore with Amazon Simple Storage Service (S3) Cross-Region Replication (CRR).

Customers can also use CloudEndure Disaster Recovery the block-level replication tool from AWS, , for the DR setup.

With AWS, the on-demand capabilities of Amazon Elastic Compute Cloud (EC2) provides customers with more options for their DR solution compared with a traditional on-premises setup.

In this blog, we are going to show how to build a low-cost DR solution using a passive DR approach for SAP HANA based applications. This solution is suitable for customers who wish to lower the cost of their DR solution and are able to accept higher RTO and RPO SLAs, when compared to data replication based solutions.

Solution Overview: Passive DR for SAP Applications in AWS

In this solution, the disaster recovery setup uses the backups of the primary SAP systems to build the DR environment. Setup is simplified using AWS services and features including AWS Backup, AWS CloudFormation and Amazon S3 CRR.

For this option, there are no Amazon Elastic Compute Cloud (EC2) instances or Amazon Elastic Block Storage (EBS) volumes provisioned in the DR AWS region during normal operations. Data is not replicated directly from databases. The following approach is used to backup and copy the production system to the selected AWS region for DR:

• Use AWS Backint agent for SAP HANA or other database native tools, to take the DB backup and store it in Amazon S3
• The Production system backups (data and log) are replicated to the DR region using Amazon S3 CRR.
• AMIs (Amazon Machine image) of application servers and databases are created and replicated to DR AWS region using AWS Backup.
• File system data (like transport directory and sap mount directory) is created and replicated using AWS Backup.

In the DR region, for testing or real DR events, SAP systems can be built on-demand using the AMIs copied from the primary region. To bring in the latest data into the databases, backups can be restored with point-in-time recovery. The data and log backup for SAP HANA database in AWS can be performed using native database tools and the AWS Backint Agent, or 3rd party tools. In this blog, we will describe the scenario using AWS Backint agent. The RPO in this solution depends on source system log backup frequency, change rate and amount of time taken to copy the backed up objects to the DR region. The RTO depends on the database size and change rate. The RTO/RPO are typically higher than with other DR option in which data is replicated directly from the database (like using HANA System Replication or CloudEndure).

The following figure shows an example architecture for the DR solution based on backup/restore:

By using an automation service such as AWS CloudFormation, customers can build their DR systems quickly and with minimum manual effort using the backups copied from the primary region.

The DR solution for an SAP System should consider other supporting services such as Active Directory, and DNS, which is not covered in this blog.

Steps to configure Disaster Recovery

In this blog, we will show the disaster recovery setup using backup/restore for a SAP NetWeaver system with a SAP HANA database. This workload is distributed across four Amazon EC2 instances: one SAP HANA database instance, one ABAP SAP Central Services (ASCS), one Primary Application Server (PAS) instance and two additional application server instances.

It is assumed that the SAP application and database servers are already installed on these instances. If customers want to perform installation of primary systems as well, they can use AWS Launch Wizard for SAP.

In this blog it is assumed that the setup is cross region DR within the same AWS account. However for customers who have strict data residency requirement and can’t have data leave their primary region or for customers who are sensitive to network performance for end user access to the DR region, they can alternatively use this solution across multiple availability zones (AZ) within the same region, instead of multiple regions.

The following steps are designed for a cross Region configuration, and will need to be adapted if a cross Availability Zone design is used instead.  This includes changes such as removing the need to make an additional copy of backups and AMI’s. If DR will be is hosted in a separate AWS account, then additional steps are needed, such as permissions properly assigned, and encryption keys shared (if necessary) to allow access to the database backups and AMIs in the DR account.

Step 1: Create Tags to SAP EC2 Instances

On the source Amazon EC2 instances, create and assign tags to the SAP EC2 instances so that they can be uniquely identified by other AWS services in your AWS account.

Also, create similar tag(s) for Amazon EFS file system that you want to backup and copy in the DR region. The file systems could be used for sap mount directory or transport directory of an SAP system.

In case you are using Amazon EFS for SAP file system on source servers, ensure to have ‘nofail’ parameter set in the /etc/fstab. Please refer to the document Mounting your Amazon EFS file system automatically for details. This is to allow the DR instance to be launched from the AMI without any issues. When the server is available in the DR region, Amazon EFS file system is mounted again.

These tags are used in AWS Backup to configure a backup plan which creates AMIs of EC2 instances and backups of EFS File Systems.

Step 2: Configure AWS Backup to create AMIs and EFS File System backups

In AWS Backup service, go to ‘Create Backup Plan’ for copying the AMIs to the DR region and ‘Build a new plan’.

In the backup rule configuration, choose an option to manage the lifecycle, such as transitioning it to cold storage or expiring the backup after a defined period of time. Also, you can choose a specific backup vault, or choose the default vault to store the backups.

Next, since you are using another region for DR, choose that as the destination region to copy the backups or AMIs. The destination region can be in a different AWS account, with a different backup vault for the DR side backups. The frequency can be aligned with your maintenance window so that any changes made to the source during maintenance can be replicated to the DR region with AMI copy.

To assign resources to the plan, you can use Tags or Resource IDs. In this blog, we are using the tags we created in Step 1. Also, choose an IAM role with sufficient permissions for AWS Backup to create and manage recovery points.

Assign tags to the backup, this will help you identify the backups in the DR region for restore process.

If you want different frequencies for Amazon EC2 AMIs and Amazon EFS backups, you can create separate backup plans for these two resource types. To understand how AWS Backup encrypts the backups, refer to the guidelines Encryption for Backups. If this does not meet your requirements, you can also create AMIs or snapshots using other services like Amazon Data Lifecycle Manager or automate this process using tools like AWS CLI. You can automate copies to the DR region using these same automation tools.

Step 3: Configure Backup for the Database

Configure the backup of your SAP HANA database. You can configure the backup using AWS Backint Agent for SAP HANA. The default configuration will schedule the log backup at a frequency of every 15 minutes. The RPO for DR in this solution depends on this frequency and therefore it should be tuned based on your requirements. Once the configuration is complete and data and log backups are scheduled, the backups are stored in Amazon S3 bucket in the primary region. SAP has listed a few options to schedule the database backups in SAP Note 2782059 – How to schedule Backups for HANA database (SAP S-User ID logon required):

• hdbsql with the BACKUP DATA SQL query, using a shell script and cron jobs.
• Backup schedule features in SAP HANA Cockpit (not in HANA Studio).
• Schedule DB13 jobs using the DBA Cockpit.
• Using XSEngine (Classic) Job Scheduler.

You can also use AWS Systems Manager Maintenance Windows for scheduling the databases backups centrally in AWS based on AWS resource tagging.

Step 4: Configure Amazon S3 CRR

Configure CRR from primary region to DR region for Amazon S3 bucket where the database backups are stored. You can find the steps for this configuration under Amazon S3 documentation for Replication.

With this setup, any backup file saved in the Amazon S3 bucket in primary region will be replicated to the DR region automatically. After completion of this step, you have the data required to build the SAP system in the DR region.

Step 5: Build the SAP EC2 Instances in DR region

You can now see that the AMIs of EC2 instances are created and copied into the DR region by AWS Backup. Go to AWS Console in the DR region and then click on the AMI section, you can find all the latest AMIs including those copied by AWS Backup. You can filter the resources based on tags assigned in the backup plan and pick the latest AMIs to build the DR system. You can either just select the AMIs one by one from AWS console and launch them in the DR region or use other tools such as the AWS CLI to launch these AMIs. You can also automate the launch using AWS CloudFormation to launch these AMIs faster and less manual effort.

Also, check that Amazon EFS file system is copied to the DR region in AWS Backup from the AWS Console in DR region. Go to the Backup Vault that you chose to store the EFS backups in target region and check the latest backup that you want to restore. The resource ID is the same as the file system ID of the source file system.

Check the right recovery point from the backup vault and start the restore process to a new file system.

Once the restore job is complete, a new file system will be created. Use this new file system ID in file /etc/fstab on Amazon EC2 instances and mount the file systems. If restore takes a long time due to file system size and you want to use another tool which performs delta replication at a defined frequency, you can alternatively use AWS Data Sync for replicating to the Amazon EFS file system. Additional cost will apply for using AWS Data Sync for replication, refer to AWS DataSync pricing for calculating this cost.

Step 6: Perform the recovery of the Database

The AWS Backint Agent configuration parameters are maintained in a YAML file in the /<installation directory>/aws-backint-agent/ directory. The name of the configuration file is aws-backint-agent-config.yaml. To change the backup configuration on the DR database server, login to the database EC2 instance at operating system level. Next, update the entries in the backint configuration file such as the backup bucket name, AWS region, account ID and other settings as needed. After this, you can access the backups from SAP HANA database in the DR region through the backint agent installed on this server. Perform the restore and recovery following the procedure provided in the SAP HANA administrator guide.

Conclusion

When you run your SAP workloads in AWS, you have multiple options to, to design and deploy DR environments that take advantage of the unmatched reliability and flexibility of the AWS Global Infrastructure. Customers do not necessarily have to provision EC2 instances and EBS volumes for DR unless required to meet their RTO and RPO SLAs. As shown in this blog, a customer can just replicate the backup data and build their SAP DR servers on-demand, reducing the cost to deploy DR and therefore lowering the TCO of their SAP environment.  To simplify the deployment and operations of such a model, AWS provides services like AWS Backup and AWS Backint agent for SAP HANA. Also, AWS provides services like AWS CloudFormation to automate the DR testing and failover events.

To learn more about why 5000+ customer choose AWS, visit thinkwithwp.com