With SAP HANA 2.0 one of the biggest changes is its multitenancy property. By default, SAP HANA 2.0 will have multitenant database containers (MDC) and it is the only operational mode. This is the third part of three-part blog series, I am going to cover in detail how to use FlashArray//m snapshots for doing backup and recovery of SAP HANA 2.0 MDC system with only Single Tenant. This is the current limitation from SAP where only SAP HANA 2.0 MDC system with the single tenant is supported with storage snapshots. The first part you would have seen (here is the link:https://krishnasatyavarapu.wordpress.com/2018/01/17/backup-and-recovery-of-sap-hana-2-0-multitenant-database-containers-with-single-tenant-on-pure-storage-flasharray-m-using-snapshots-part-1/)is about how to perform backups using storage snapshots using SAP HANA studio and the second part is how to do recovery of SAP HANA as seen here (https://krishnasatyavarapu.wordpress.com/2018/02/16/backup-and-recovery-of-sap-hana-2-0-multitenant-database-containers-with-single-tenant-on-pure-storage-flasharray-m-using-snapshots-part-2/).
In this third part, I will cover how to automate this backup process using shell scripts.
SAP HANA 2.0 MDC basically consists of a system database and one or more tenant databases. System database is used for overall system administration activities and tenant databases are self-contained and completely isolated in terms of the persistence layer, database catalog, repository, backups, and logs. As mentioned previously storage snapshots will work only for SAP HANA MDC systems with a system database and only one tenant database.
As shown below, is an SAP HANA MDC 2.0 system with one system database and one tenant database.
SAP HANA backup and recovery is a long painstaking process for SAP HANA system administrators. These administrators spend considerable amounts of time and effort prepping the environment and going through complicated procedures to ensure that the backup process is carried out with minimum disruption to the business and in accordance with best practices.
Pure Storage helps simplify the backup process for SAP HANA environments through our unique snapshot capabilities. Pure Storage snapshots are nearly instantaneous and highly space efficient, allowing system administrators to greatly speed up the backup/recovery process with minimal effect on production environments.
The storage snapshots are suitable to provide very fast data backups for a huge amount of data with a negligible impact on the network, overall I/O performance and the SAP HANA database itself. Also, storage snapshots are most suitable for fast database recovery (recovery-time-objective; RTO).
The whole process of backing up SAP HANA using Pure Storage snapshots takes few minutes. Storage snapshot support is enabled using a loose coupling between the SAP HANA database and the storage system. The creation of a storage snapshot is done in three steps that must be executed on the SAP HANA database site as well as on storage system level. The SAP HANA database offers SQL statements to PREPARE, CONFIRM and if needed ABANDON a storage snapshot.
Here are the steps in detail to backup an SAP HANA MDC by using the shell script. The SAP HANA system SID is PSD and <sid>adm user is psdadm.
Add this shell script to crontab and run it frequently like once every 2 hours. You can then reduce the File-based backup less frequently like once every 3 days. This storage snapshot method gives more recover points for SAP HANA reducing the RTO drastically.
Compared to file-based or backint-based data backups, a storage snapshot will consider the entire data area of all SAP HANA database services and not only the payload of each service specific data volume.
Here are the steps in detail to do the recovery of an SAP HANA MDC by using the shell script. The SAP HANA system SID is PSD and <sid>adm user is psdadm.
The recovery starts with the system database and then you recover the tenant database by clearing the log. It is recommended to put a sleep statement in the script has the recovery of system database takes time. Below screenshot shows the recovery process…