AWS for SAP
SAP backups on AWS using Commvault – architecture and core component deployment
In this blog series, we cover best practices for customers to use Commvault to back up and recover their SAP instances securely. Customers who run SAP on AWS today have various backup solutions available to back up their SAP instances. Some use cloud-native AWS services while others continue to use their enterprise backup solutions like Commvault, NetBackup, etc. based on the requirements of each customer.
In this blog, we focus on Commvault architecture and how Commvault core components are deployed on AWS for backing up the SAP HANA database.
Commvault architecture:
* Grants access to S3 buckets. AWS KMS CMS’s (local/remote) and AWS resources
** Grants access to S3 buckets. AWS KMS CMKs (local) and AWS resources. Provisioned via initial account creation
*** KMS Key policy controls encryption access. Grants the tenant account IAM user and MediaAgent role Amazon EBS encryption/decryption permissions
The Commvault solution consists of a number of different components and can be customized to fit business requirements. The core components necessary to build a robust and scalable implementation are called a CommCell. All the following components require the use of the appropriate Amazon Elastic Compute Cloud (Amazon EC2) instance type, and Amazon Elastic Block Store (Amazon EBS) volume detailed in the Commvault documentation.
Commvault components:
- CommServe:
The CommServe is the system that coordinates all activity in the CommCell environment and houses the metadata database (where CommCell information is managed). This system is made highly available by deploying a standby CommServe into another AWS Availability Zone or Region. The primary and standby CommServe instances are kept in sync with Commvault-managed database log shipping. - MediaAgent:
The MediaAgent conducts the movement of data from source to destination. The MediaAgent maintains the deduplication database, and communicates with an Amazon S3 bucket (Backup Media Target) to store deduplicated data. Multiple MediaAgents should be deployed to increase backup and restore capabilities. To provide high availability, MediaAgents should be deployed to multiple AWS Availability Zones.
AWS components:
- Amazon S3 Bucket:
Amazon S3 buckets act as the backup data repositories. As the MediaAgents collect data, it is stored inside these buckets are in a deduplicated state. One bucket is created for each MediaAgent. A bucket policy is put in place to restrict which users/roles can access the data contained in the buckets. Default encryption should be enabled on the buckets using Amazon S3-Managed Keys (SSE-S3). AWS managed Customer Master Keys (CMK) or a Customer managed CMK may be used, however keep in mind that these keys interface with the AWS KMS service every time an object in the bucket is encrypted or decrypted. AWS KMS API calls are tracked and billed against once they exceed the free tier. A bucket where deduplication has created millions of objects can yield significant AWS KMS fees if you use AWS managed CMK or Customer managed CMK. - IAM Role:
IAM Roles that are attached to EC2 instances are used to grant Commvault software components access to S3 buckets and other AWS resources. - EC2 Instance:
Amazon EC2 instances that run the SAP HANA DB which have Commvault file and HANA agents deployed on them. - AWS KMS CMKs:
AWS Key Management Service Custom Master Keys are used to encrypt data at rest from EBS volumes being backed up via Commvault Virtual Server Agent (VSA) proxy. It is required that Customer Managed CMKs are used for Amazon EBS encryption and not Amazon Managed CMKs. This enables you to modify the KMS policy and grant cross-account access to Commvault. - EC2 Security Group:
Commvault agents require an EC2 security group to allow inbound communications from the Commvault CommServe and MediaAgent servers. It is recommended that security groups inbound TCP 8400-8409 from the AWS AZ subnet CIDRs where Commvault CommServe and MediaAgents are deployed. This enables scalability for Commvault without having to tune the security groups as Commvault scales out.
Protecting SAP HANA:
The protection options available for SAP HANA are:
- File-level backup, where the data gets written to a local EBS volume.
- Snapshots using storage-level with cloud-native services. Read more about this in the blog on how to use snapshots for SAP HANA database to create an automated recovery procedure.
- Backint for SAP HANA, which is SAP-defined streaming backup interface for connecting centralized third-party solutions to back up HANA
In this blog, we focus on Backint for SAP HANA which enables customers to integrate their SAP certified backup solution, such as Commvault directly connect with the HANA database.
A best practice is to back up a database with the ability to restore it to any point in time. This 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
- Transaction log backups
In addition to full database backups performed at the application level, transaction log backups are important to restore the database to a certain point in time or to empty the logs from already committed transactions. After a crash, the in-memory database gets loaded from the last savepoint (persist all changed data along with log files to disk at regular intervals). The database is then rolled forward to the latest transaction using the externalized log files.
Commvault protection of HANA Database:
For Commvault to back up the SAP HANA database, a few requirements must be in place. The Commvault file agent and HANA agent need to be deployed to the EC2 instance housing the HANA database. Detailed configuration steps for setting up HANA database backup using Commvault are shown below.
-
Configuration steps on HANA
- Create a HANA user for backup and assign the required role
- Create a user from HANA studio SQL editor or hdbsql
- Create a HANA user for backup and assign the required role
CREATE USER <user_name_for_backup> PASSWORD <password to be used> NO FORCE_FIRST_PASSWORD_CHANGE
-
-
- Create the HANA role and attached it to the preceding user
-
CREATE ROLE <BACKUP_ROLE>;
GRANT BACKUP ADMIN, CATALOG READ, INIFILE ADMIN, DATABASE ADMIN, TRACE ADMIN, SERVICE ADMIN TO <BACKUP_ROLE>;
GRANT <BACKUP_ROLE> TO <user_name_for_backup>;
Where BACKUP_USER is the user name and Backuppwd01 is the password used in this example. Make sure that the user is created for the SYSTEMDB and all tenant databases. The user must have the same password for each database. Once the user is created, you can verify the same by logging into HANA Studio.
-
- Set HANA store key for backup
hdbuserstore set HDBBACKUP imdbmaster:30015 <user_name_for_backup> <password to be used>
-
Commvault File Agent installation on HANA DB instance
The team responsible for the Commvault server must create a custom Commvault file agent package for the server hosting the HANA DB. This package can be installed from command line interface on the server via the cvpkgadd command included in the Commvault file agent package.
-
Configuration on Commvault
- Once the Commvault file agent is installed on the server hosting the HANA DB, the client appears in the Commvault CommServe console under client computers
- Right-click on this client, choose All Tasks, then Add Remove Software, and then Install Software
- Leave override cache option unchecked unless required
- From the list of Packages to Install, Select “Databases”, then select “SAP for HANA”
- Add to a client group now or modify later
- Set the UnixGroup to sapsys and check the box to “Override Unix Group and Permissions”
- Review and finish the installation
-
Configure the Commvault SAP HANA client
- Select “New Client” in the CommCell browser and then create Pseudo-client by selecting “SAP HANA Client”
- In the general tab, specify:
- In the details tab, choose the instance which houses the HANA DB
- In the Storage Device tab, specify the storage policy for this HANA DB backup. The storage polices are created based on backup storage requirements
-
Adding additional HANA Instances
-
Creating Schedule Policy
-
Update Backup destination on HANA
- In the SAP HANA Studio, set the Backint Parameter File in the Data Backup and Log Backup areas to the file
- In the SAP HANA Studio, in Log Backup Settings area, select Backint as the Destination Type and set the Backint Parameter File
- And as the last step, the AWS security group attached to the EC2 instance must have inbound TCP ports 8400–8409 and ICMP from the subnets where the Commvault MediaAgent/VSA proxy instances are deployed. This allows the CommCell servers the ability to communicate with the file and HANA agent
- In the SAP HANA Studio, set the Backint Parameter File in the Data Backup and Log Backup areas to the file
This completes Commvault setup for HANA database backup.
Conclusion
We have covered Commvault architecture and how Commvault core components are deployed on AWS for backing up the SAP HANA database. In part 2, we talk about how to protect SAP application components and shared file system using Commvault backup solution. Contact us if you have any comments or questions – we value your feedback.
About the Authors
Ajay Kande is a Senior SAP Consultant with AWS Professional Services. He helps customers around the globe to design and architect SAP solutions on AWS. He is passionate about driving innovation and digital transformation initiatives for customers using the AWS platform for their SAP instances. Outside of work, he loves spending time with his family and friends.
Mike Virgilio is a Senior Security Transformation Consultant with AWS Professional Services. He focuses across the environment helping customers improve their security, risk, and compliance posture. When he’s not at work, he is out riding his motorcycle, smoking brisket or practicing his mixology skills.