| Part 1 — 3 steps to protect your SAP HANA database Part 2 — How to optimize and backup your SAP HANA environment Part 3 — SAP HANA tenant database system copy and recovery Part 4 — How to recover SAP HANA tenant database |
SAP administrators face many challenges, including maintaining reliability, minimizing downtime and providing business units the intelligence they need when they need it, while managing the complexity of disparate systems and layers dependent upon business intelligence. My first blog, 3 steps to protect your SAP HANA database, provided insight as to how Veeam can help with these challenges, including installing and configuring the Veeam Plug-in for SAP HANA and leveraging it to perform backup and restore operations. This blog expands that discussion and focuses on SAP HANA backint configuration, as well as recommendations on protecting your SAP application environment.
I hope you never have to leverage Veeam’s unique restore capabilities for SAP. If you do, minimizing the downtime associated with your SAP infrastructure is critical. The 2019 Veeam Cloud Data Management Report surveyed over 1,500 senior business and IT decision makers worldwide and found that lost data from mission-critical application downtime costs organizations $102,450 per hour, on average. Now downtime costs vary by industry, scale of business operations and an assortment of other factors, but it is still a staggering amount, causing SAP administrators to review disaster recovery capabilities for upcoming SAP S/4HANA migrations from ECC.
Additional configuration items in SAP HANA
In my previous blog, I discussed the recommended practices for installing and configuring the Veeam Plug-in for SAP HANA. I also recommended SAP Basis Administrators should work along with their Veeam Administrator counterparts, as by working more closely together, you can achieve success and potentially make your life easier.
For SAP HANA backint, most configuration items reside in a database configuration file called global.ini. Inside it is a backup section.
Many of these parameters are self-explanatory but you may consult the SAP HANA Administration Guide, if needed.
Which ones are important for Veeam Backups?
Catalog_backup_using_backint — This determines if the catalog backup will be written to a local disk or to the Veeam repository. There are advantages and disadvantages with each but changing the value to true allows the catalog backup to also write to Veeam repositories instead of local disk.
Parallel_data_backup_backint_channels — This determines how many channels will be used to write the data to a Veeam repository. The HANA service must be greater than 128 GB of data (not RAM) to use parallel channels. The maximum number of channels is 32, but I would encourage you to be cautious. The axiom I often suggest is to use as much as needed for performance and as low as possible for resources used. A recommended approach would be to start with as few as two or as many as four and double it per run to gauge the impact on the total time needed for the backup to run. You should expect to see the time for the backup to complete change in a linear fashion. If not, you may be leveraging too many channels, consuming significant and valuable resources on the HANA instance and the Veeam repository. This can impact overall backint performance, which I will comment on later in this blog.
Do not forget to adjust the data_backup_buffer_size according to your channels. Please consult the SAP HANA admin guide for more information.
Other parameters should be set based upon guidance from SAP and/or Veeam support, as they are dependent upon specific elements within your environment and architecture. For example, larger systems may require you to change the backint_response_timout parameter to a higher value, possibly in conjunction with the log_backup_interval_mode. Both parameters influence how log backups are written into backint.
Performance of Veeam Plug-in for SAP HANA
As there are many opinions on this topic, I wanted to be sure to address performance expectations with the Veeam Plug-in for SAP HANA. In my experience, businesses often have high expectations for throughput values but have trouble achieving them. Yet there are ways to optimize performance and I wish to share with you my top recommendations in hopes you will find them helpful.
- Network throughput. As SAP HANA backint communicates via network only, this is a great first place to look. My personal recommendation for customers is to use iperf3 to test throughput from the SAP HANA system to the Veeam repository. On a 10 Gb network I would expect you to see similar results to the ones in the screenshot below. While you may believe these values to be suboptimal, I have seen environments that have struggled to achieve even these values.
- Start iperf3 -s on your repository.
- Start iperf3 -c ‘repository system name’ on your non-productive SAP HANA system.
- Run iostat and Windows System Resource Manager (disks) to understand your storage in further detail and examine throughput and latency.
- If you need to evaluate the maximum throughput value your infrastructure can deliver or better understand any bottlenecks, you can simply test your infrastructure without using any Veeam components. To do this you need to mount your CIFS or NFS repository share. It is important is to use the uid or gid to have write access for the <sid>adm.
- mount -t cifs -o username=username, domain=domain, vers=3.0, rw, uid=<sid>adm //server/cifsshare /mnt/cifs/
- As a result, SAP HANA will provide you a runtime length for your backup and after performance optimization, SAP HANA backing usually yields a more desirable value.
Now that you have a good overview of what you should look for in terms of configuration and tuning recommendations, I want to address operational considerations, including scheduling and what to backup beyond SAP HANA backint data.
Scheduling options for SAP HANA
As described previously, the Veeam SAP HANA backint Plug-In follows an SAP database centric approach, hence scheduling options are SAP centric. Depending on your daily operation requirements, I can provide an overview for the following scheduling options:
- External scheduling software like autonomy, cron and others
- SAP HANA Cockpit
- SAP S/4 DBA Planning Calendar (DB13)
- Veeam shell job for scheduling
All these options have unique advantages and disadvantages, hence you will want to discuss them with your operations team to decide which one best fits your environment.
External scheduling software
For using external scheduling software, we provide a sample script/example available via GitHub.
The steps are straight forward and can be easily scripted in the following steps.
1. Login to the OS with <sid>adm (if not performed by scheduling software)
2. Start “hdbsql -d SYSTEMDB -U <HDBUSERSSTOREKEY> -I <filename>
In the file use the following SQL commands as needed:
# Full Backup SYSTEMDB
# backup data using backint ('$backupcomment');
# Diff Backup SYSTEMDB
# backup data differential using backint ('$backupcomment');
# INCR Backup SYSTEMDB
# backup data incremental using backint ('$backupcomment');
# Full Backup tenant <tenant name>
#backup data for <tenant name> using backint ('$backupcomment');
# Diff Backup tenant <tenant name>
#backup data differential for <tenant name> using backint ('$backupcomment');
# INCR Backup tenant <tenant name>
#backup data incremental for <tenant name> using backint ('$backupcomment');
With timeouts, the scripting of the option asynchronous might help, as the scripts will start but will return without waiting for the backup run.
# backup data for VDQ using backint ('$backupcomment') ASYNCHRONOUS;
If you have a very dynamic environment with a lot of tenant changes, you can also easily incorporate the following SQL command to capture all tenants at the beginning of the backup.
# list all tenant DBs (logon to SYSTEM DB first) including all informations select * from "SYS"."M_DATABASES" # list all tenant DBs (logon to SYSTEM DB first) - only names select DATABASE_NAME from "SYS"."M_DATABASES"
SAP HANA Cockpit
SAP HANA Cockpit is the new SAP HANA administrative tool, replacing SAP HANA Studio. After logging into SAP HANA Cockpit, select your database and go to Database Administration — Manage database backups.
Inside your database backups there is a Go to Schedules button.
From there you can enable your scheduler and then create schedules for your database.
After enabling the scheduler, click the scheduling table or press the + sign. Select Schedule a Series of Backups.
Make sure to use a meaningful or intuitive name for your schedule.
Set your settings to your backup type (ex. full backup) and select Backint as destination type. Change the backup prefix as needed.
Choose your recurrence type.
Configure your recurrence details.
Check the summary and save the schedule.
You will find your newly created schedule in the backup schedules table.
SAP S/4 DBA Planning Calendar (DB13)
You also have the option to use your DBA planning calendar. Just jump into DB13 and you create your schedule from here.
Usage of Veeam jobs for scheduling
For those who want to control the backup from Veeam Backup & Replication, you can create a Veeam job for an agent or a VM. Simply create the job and add the desired agent or VM, enable application aware processing and start a script to start the backup. See the steps for the pre or post-thaw script under scheduling software.
How to back up your complete SAP system
Now that we have explored scheduling options, I want to offer recommendations on how to secure your complete SAP environment, including ASCS, Dialog and batch instances, and the HANA system, including OS and database installation. The steps are similar, regardless if you are running Windows or Linux application servers or if they are physical or virtual.
Create a job, which includes all systems.
In this example, you see a HANA database system and one application server with ASCS and the first application server. You can add these both into VMs to back up.
Next, it is important to Enable application-aware processing, so that the database will be backed up in snapshot mode. A script can also be added for the database VM to activate an application aware backup.
Click Applications and configure a script for the HANA system.
This will make sure the HANA database leverages snapshot mode before taking the backup and completes the snapshot after taking the backup. If you are using Veeam storage integrations, this will significantly shorten the time a snapshot is open.
Sample scripts may be found via GitHub.
For those seeking recommendations on scheduling, unfortunately there is no simple answer. It depends on your environment, your service level agreements (SLAs) (recovery point objective and recovery time objective) and your SAP environment behavior. At a minimum, I suggest at least once a week, though I would urge you to consider once a day. Recently, ESG published a survey that found that 74% of servers have a downtime tolerance of less than two hours.[1]
This survey was conducted across all workloads, not just mission-critical, and more information on this survey can be found in The race to zero downtime and zero data loss vlog. The good news is that everything besides the HANA database is typically very static and with Change Block Tracking and storage integrations this should be simple from a capacity and performance perspective.
Closing thoughts
Now that you have progressed through the second blog in this series, you are not only more educated regarding SAP backups and restores but are well prepared in case of a disaster — which will hopefully never happen to you. I know there are many other elements to consider for disaster recovery (e.g. like cluster, HANA System replication and VMWARE FT for the ASCS,) but in case you lose an application server or your ACSC, you can simply recover it with Veeam via Instant VM Recovery. Veeam Instant VM Recovery immediately restores a VM back into your production environment by running it directly from the backup file in minutes, minimizing disruption and downtime for mission-critical applications like your SAP system.
If something happens with your HANA server, simply restore this system with Veeam Instant VM Recovery and check that your database is up and running. Restore your latest full backup via Backint and forward all the needed logs via the SAP certified solution.
In the next blog we will discuss retention policies, including long-term retention, as well as HANA system copies. In the meantime, make sure to install the Veeam Plug-in for SAP HANA, which is included with the Veeam Backup & Replication installation package.
[1] ESG: Real-world SLAs and Availability Requirements by Edwin Yuen on May 4, 2018
See More:
- On-Demand Sessions from VeeamON Virtual
