AWS for SAP
Simplify SAP Backups with AWS Services
For customers running SAP on AWS, having a solid backup strategy is crucial for safeguarding their database and SAP application non-database file systems. Backups play a critical role in running SAP workloads by allowing for the recovery of systems in the event of data loss. With numerous third-party, database-native, and AWS-native options available, choosing the right backup tool and strategy can be a complex process. It is essential to carefully evaluate each option and select the one that best fits your business needs, budget, and overall IT infrastructure. Proper planning, implementation, and testing of backup and recovery procedures can help ensure business continuity and minimize downtime in the event of an outage or disaster.
In this blog, we offer a comprehensive overview of the various backup options available for SAP workloads running on AWS, including SAP HANA, Oracle, Microsoft SQL Server, and SAP ASE databases. We’ll also delve into the specifics of backing up SAP application-specific non-database file systems. Our aim is to provide readers with a clear understanding of the different backup solutions available using native AWS services and help them determine which option is best suited for their SAP workload. By the end of this blog, you will have a better understanding of how to configure backups in AWS to protect your SAP workload and ensure business continuity in the event of an unexpected outage or data loss.
Architecture design
The following architecture design provides a brief overview of backup approach for SAP workloads on AWS:
Let’s start with Database backup
Let’s start with database backups. Backing up a database, with the ability to restore it to any point in time enables restoration to a state that’s as close as possible to the way it was before the disruption. Two types of backups must be performed to achieve the capability to restore:
- Database backups: Full, incremental, or differential backups
- Transaction log backups
In addition to full-database backups performed at an application level, transaction log backups are important to restore the database to a certain point in time or to empty the logs from the directory after committed transactions are saved at the persistent level.
Amazon S3 offers an ideal storage solution to save database backups, as it allows customers of all sizes and industries to store and protect any amount of data. We will focus on protecting databases with their backup storage in Amazon S3 and automation for how you can backup/restore databases directly on Amazon S3 so there is no cost for interim Amazon Elastic Block Storage(EBS) and Amazon Elastic File system (EFS) storage. Also, backups can be moved to Amazon S3-IA and Amazon Glacier storage to save cost with automated Amazon S3 lifecycle policies which is discussed in later sections of this blog. Backups can also be replicated with Amazon S3 bucket replication in the DR region to recover in case of any disaster. Data protection is provided for in-transit data as well as data at rest. In-transit protection is provided via SSL, while at-rest data protection is provided via 256-bit Advance Encryption Standard (AES-256).
SAP HANA Database
- AWS team developed AWS Backint Agent for SAP HANA, which is an SAP-certified solution that enables database backup/restore operations. AWS Backint Agent backs up your SAP HANA database to Amazon S3 and restores it using SAP management tools, such as SAP HANA Cockpit, SAP HANA Studio, or SQL commands. AWS Backint Agent supports taking backups to Amazon S3 Standard, S3 – Infrequent Access (IA), and S3 One-Zone – Infrequent Access (IA). There is no cost to use AWS Backint Agent. You only pay for the underlying AWS services you use.
- AWS Backup is also integrated with AWS Backint Agent to perform SAP HANA backups and restores. AWS Backup offers a simple, cost-effective, and application-consistent backup and restore solution for SAP HANA databases running on Amazon EC2. AWS Backup for SAP HANA provides centralized, console-based backup management with a consistent experience across all supported AWS resources. Features include improved security using IAM policies, dedicated backup vaults, access to standardized AWS monitoring and reporting features, and intelligence for optimizing continuous backups for a point-in-time restore. Using AWS Backup’s seamless integration with AWS Organizations, you can create and manage immutable backups of SAP HANA databases across all your accounts, help protect your data from inadvertent or malicious actions, and restore the data. For more details, please refer to the AWS documentation here.
Oracle Database
- Several customers who are running SAP with Oracle DB on AWS and want to leverage native AWS services for backup approach of the Oracle database. Starting with Oracle Database 9i Release 2, Oracle included the Secure Backup Cloud Module, which extends the Amazon S3 functionality as a backup medium for Oracle databases. With the Oracle Secure Backup (OSB) module installed on your server, you can perform database backup and restore operations directly from the Amazon S3 bucket. OSB enables RMAN to backup Oracle databases to Amazon S3 with just a few simple changes to the RMAN commands used for backup configuration. The RMAN commands used for backups execution remain unchanged, except for the “destination” parameter, which must point to Amazon S3 instead of tape. By using RMAN, you can specify multiple backup channels to increase parallelism and speed up your backups. However, this may utilize more network bandwidth. Using this approach, we were able to configure the Oracle DB backup within 30 minutes and perform the backup of a 5.5 TB size database within 1 hour and 45 minutes.
- Customers who run SAP workloads with Oracle can take advantage of AWS Native EBS multi-volume crash-consistent snapshots for backup and recovery of their Oracle databases. This procedure can help save on storage costs since the snapshot retains only one full backup and the remaining ones are delta snapshots. Additionally, if immediate backup restoration is needed, Amazon EBS Fast Snapshot Restore can be applied to enhance restore speed. Please look at Kellogg’s customer story for the benefits of this approach.
Microsoft SQL Server Database
- Microsoft SQL server on Microsoft Windows also offers the option to perform backup/restore operations directly on Amazon S3. To utilize this feature, simply use the Amazon S3 bucket URL in your backup script as the backup target. Update backup script with following content and refer to this document for detailed instructions –
Set @FullName = ‘s3://<bucketname>.s3.<region-name>.amazonaws.com/<FolderName>/
BACKUP DATABASE <SID> to URL = @FullName - Microsoft SQL Server running on Microsoft Windows can also use VSS (Volume Shadow Copy Service) feature to perform consistent DB backup. VSS is also integrated with AWS Backup which make administration easy for backup/restore operations. Please refer to the blog for detailed configuration and testing steps.
SAP ASE Database
- Customers who are running SAP workloads with SAP ASE (Adaptive Server Enterprise) database can also utilize Amazon S3 as their backup storage. This solution requires AWS File Gateway to asynchronously transfer data to Amazon S3 over an HTTPS connection. Furthermore, SAP has conducted a detailed analysis and shared a solution with configuration steps for this method.
- Similarly to other databases, the SAP ASE database also allows the option to utilize Amazon EBS snapshots for backup and restore operations. For detailed steps on performing and automating backup/restore operations on the SAP ASE database using Amazon EBS Snapshots, please refer to this blog.
Manage compliance with right S3 storage tier
Organizations have different compliance requirements when it comes to backup storage retention duration. These compliance requirements can be guided by an organization wide policy, the criticality of the SAP system or the auditory requirements. Compliance requirements will drive the type of backup(full/incremental), the amount of time backups need to be retained and the acceptable time for restoration.
Amazon S3 service is the ideal storage for storing the database backups. S3 as a service provides different storage classes which allows the user the choice to choose the storage class based on the priority of data access speed, storage costs , and retrieval costs. There are three main drivers which determine the right S3 storage class to be used to store the SAP database backups:
- The maximum time allowed to access and restore the backups
- The costs to be paid for backups
- Adherence to company/industry regulatory requirements that stipulate how long the backups need to be retained.
Storage Class | Speed of access/Retrieval | Minimum Storage Duration | Cost Factors |
S3 Standard | millisecond | None | Storage |
S3 Standard-IA | millisecond | 30 days | Storage+per-GB retrieval costs |
S3 One Zone-IA | millisecond | 30 days | Storage+per-GB retrieval costs |
S3 Glacier Instant Retrieval | millisecond | 90 days | Storage+per-GB retrieval costs |
S3 Glacier Flexible Retrieval | minutes to hours | 90 days | Storage+per-GB retrieval costs |
S3 Glacier Deep Archive | hours | 180 days | Storage+per-GB retrieval costs |
While determining the optimum cost for the backup storage, consideration should also be given to the ‘Minimum Storage Duration’ factor which will have an impact on the overall costs for the SAP database backups. While the S3 Standard has higher storage costs compared to other classes, there is no minimum storage duration. S3 standard could be the most cost-effective backup storage class for customers who do not have any backup retention requirements and who are comfortable with any restoration point of not more than a week.
Customers with compliance requirements of weeks
Customers who have regulatory requirements which mandate that they need to maintain data backups for weeks (not exceeding 30 days), can use a combination of S3 Standard and S3-Standard IA to store the backups:
- Most recent backups which are more relevant in case of a primary database failure/corruption can be stored in S3-Standard (Ex: Last 7 days backup). This will ensure that restoration from backup is the shortest possible time without any overhead on storage costs due to ‘Minimum Storage Duration’ requirements
- Older backups can be stored either in S3 Standard-IA or S3 One Zone-IA based on the Availability requirements to minimize the overall storage cost for older backups without impact on the restoration time
Customer with compliance requirements of months
Customers who have compliance requirements which mandates that they need to maintain data backups of months (Not exceeding 3 months), can use a combination of S3 Standard and S3-Standard Glacier to store the backups:
- Latest backups which are more relevant in case of a primary database failure/corruption can be stored in S3-Standard (Ex: Last 7 days backup). This will ensure that restoration from backup is the shortest possible time without any overhead on storage costs due to ‘Minimum Storage Duration’ requirements
- Older backups can be stored either in S3 Glacier Instant Retrieval or S3 Glacier Flexible Retrieval based on the flexibility of restoration time requirements
Customer with no defined compliance requirements
Customers who have no well-defined compliance requirements or unclear compliance requirements can choose to use S3 Intelligent-Tiering. S3 Intelligent-Tiering optimizes storage costs by deciding to store the objects across the right S3 storage tier based on the access patterns. S3 Intelligent-Tiering monitors access patterns of the objects and automatically moves data to Infrequent access tier after 30 consecutive days of no access. After 90 consecutive days objects are moved to Archive Instant access tier.
File systems backups
After discussing database backup options in the previous section, it’s time to focus on non-database file systems backup options. Typically, Amazon EC2 instances for SAP workloads have two types of attached volumes: Amazon EBS and Amazon EFS. In this section, we will explore backup approaches for both types of volumes.
Non-database EBS volumes backup
Several Amazon EBS volumes are attached to SAP servers that are not part of the database, such as root volumes and SAP application-specific volumes. It is essential to back up these volumes to recover in case of any data loss. AWS Backup is a centralized, managed service that can back up data across AWS services in the cloud. AWS Backup offers a single dashboard for backup, restore, and policy-based retention of different AWS resources, including Amazon EBS volumes and Amazon EC2 instances. AWS Backup automates and consolidates backup tasks previously performed service-by-service, eliminating the need to create custom scripts and manual processes.
For SAP application servers, AWS Backup can be used to back up the entire Amazon EC2 instance. Alternatively, you can back up individual Amazon EBS volumes, including the root volume, so that if you need to restore a specific file, you can restore the respective Amazon EBS volume. For database servers, you can back up all Amazon EBS volumes except data and log volumes as the database backup is already being done using database-specific tools. Third-party tools like Commvault can also back up Amazon EC2 instances, skipping specific volumes, which can be an alternative option to back up database Amazon EC2 instances.
Shared File systems backup
Shared file systems like /sapmnt, /usr/sap/trans, and /interfaces are integral parts of SAP applications. AWS customers use Amazon EFS on Linux-based systems and Amazon FSx for Windows file server on Microsoft Windows-based systems for these shared file systems. AWS Backup can be used to back up both Amazon EFS and Amazon FSx file shares. Because AWS Backup natively integrates with Amazon EFS, any I/O operations initiated by AWS Backup will not count against Amazon EFS burst credits or general-purpose mode limits. AWS Backup also provides an option to transition your Amazon EFS file system backups from warm storage to a low-cost, cold-storage tier.
Conclusion
In conclusion, backup and recovery are critical components of any SAP workload running on AWS. With various backup options available, it can be challenging to determine the best fit for your specific workload. Our blog provides an overview of the different backup solutions available, including SAP HANA, Oracle, Microsoft SQL Server, and SAP ASE databases, as well as non-database file systems. By understanding the differences and capabilities of each solution, readers will be better equipped to choose the right backup strategy that meets their business needs and IT infrastructure. Configuring backups correctly is essential for protecting data and ensuring business continuity in the event of a disaster. We hope this blog helps readers make informed decisions and optimize their backup and recovery procedures for their SAP workloads running on AWS.
To learn why thousands of customers trust AWS to migrate, modernize, and innovate with their SAP workloads, visit the SAP on AWS page.