SAP HANA Best Practices Guide

THIS PAGE INTENTIONALLY LEFT BLANK.

Contents

INTRODUCTION / 4

PROTECTING SAP HANA / 5

PREPARATION / 5

INSTALLATION / 6

Command Line Installation / 6

Push Install / 6

CONFIGURATION / 7

Backint for HANA Parameter File / 7

Commvault® GUI Configuration / 8

SAP HANA Studio Configuration / 9

Enhanced Multi-Streaming / 11

BACKUPS / 11

Triggered by SAP HANA Studio / 11

Scheduling of Backups / 13

Scheduling via SAP DB13/DBACOCKPIT / 15

HANA-SIDE TROUBLESHOOTING AND MONITORING / 16

RESTORES / 17

Restoring via SAP HANA Studio / 17

Restoring HANA via Commvault® GUI / 20

HANA Database Copy / 21

Commvault GUI / 21

SAP HANA Studio / 22

INTELLISNAP® FOR HANA / 24

Preparation / 25

Backup / 26

Restore / 28

HANA SNAP CLONE / 28

Prerequisites / 29

Supported Storage Arrays / 29

Source Database Preparation / 29

Clone Database preparation / 30

Cloning Procedure / 30

MULTI-TENANT DATABASE CONTAINERS / 32

Configuration / 33

Backup / 33

Restore / 34

HANA SYSTEM REPLICATION / 34

Install and Configuration / 35

Source and Destination Database Preparation (SAP Configuration) / 35

Commvault Configuration / 37

APPENDIX / 38

SAP Commands for managing replication / 38

Commands for stopping and starting HANA services / 38

Commands for starting and stopping HANA replication / 38

4

INTRODUCTION

SAP HANA® is a new and innovative in-memory database platform and SAP’s answer to the question on how to analyse Big Data in near real time. HANA takes full advantage of all-new hardware technologies by combining columnar data storage, massively parallel processing of modern CPUs and in-memory computing. This puts HANA in a position to be able to support numerous use cases in the real-time analytics space. Above that, SAP HANA can also be deployed as the underlying database of SAP Business Suite® applications.

A HANA database is identified by a unique SID. Up to four so-called servers (depending on HANA SPS level) form a HANA database. Each of these servers has its own data and log volume. In case of increasing workloads, a HANA database can be scaled up by adding more memory and CPUs to the local node it’s running on.

HANA SID

MEMORY

PERSISTANCE LAYER

BACKINT FOR HANA

NAME SERVER STATS SERVER XS ENGINE INDEX SERVER

LOGVol

DATAVol

LOGVol

DATAVol

LOGVol

DATAVol

LOGVol

DATAVol

CONFIG FILES

CLOUD

Figure 1: SAP HANA Single Node Configuration

There is also a scale-out option which works through adding additional nodes leading a single database being spread across multiple nodes.

NODE 1

INDEX SERVER

STATS SERVER

XS ENGINE

NAME SERVER

CONFIGFILES

NODE 2

INDEX SERVER

STATS SERVER

XS ENGINE

NAME SERVER

CONFIGFILES

NODE 3

INDEX SERVER

STATS SERVER

XS ENGINE

NAME SERVER

CONFIGFILES

NODE 4

INDEX SERVER

STATS SERVER

XS ENGINE

NAME SERVER

CONFIGFILES

HANA SID

BACKINT FOR HANA

CLOUD

Figure 2: SAP HANA Multi Node Configuration

5

In order to protect against power failures and system crashes, HANA has the concept of persisting all changed data of the four HANA servers along with their logfiles to disk as so-called savepoints. Those savepoints are scheduled to happen periodically (typically every 5 minutes). Savepoints are consistent images of the database. After a crash the in-memory database gets loaded from the last savepoint and is rolled forward to the latest transaction using the externalized logfiles.

PROTECTING SAP HANA

There are basically three main protection options for SAP HANA:

• File-level backup, where the data gets written to a local storage location • Snapshots using storage-level snapshot technologies• Backint for HANA, which is a SAP-defined streaming backup interface for connecting centralized

3rd party backup solutions to backup HANA

As of now, Backint for HANA is the backup approach preferred by many HANA users as it is the only way for connecting a SAP HANA landscape to the existing centralized backup solution like Commvault® software in a SAP-certified way.

Commvault, as a market leading solution for enterprise backup, not only implements Backint for HANA but also supports SAP HANA Snapshot interface as part of the Commvault iDataAgent for SAP HANA. Commvault software protects scale-up and scale-out configurations for standalone SAP HANA deployments alongside with SAP Business Suite Powered by HANA and SAP S/4 HANA environments.

Data transfer via Backint for HANA works through named pipes. Communication between HANA and the backup tool is done facilitated using the so-called input and output files. For instance, for a backint backup call, HANA allocates named pipes and passes their full path via the input file. Once the backup has completed, Commvault software returns backup status information (like the backup IDs) and return codes via the output file back to HANA. According to the standard, the Commvault SAP HANA agent executable is named “backint” and is accessed via a logical link in a defined directory

PREPARATION

Before the installation of the Commvault agent for SAP HANA can start, the SID of the SAP HANA database must be determined. Above that, we also need to make sure that two directories exist, which are required during and after installation:

• SAPHANAEXE directory, which will hold the symbolic link to Commvault SAP HANA agent later-on - /usr/sap/<SID>/SYS/global/hdb/opt

• Backint for HANA agent configuration file directory - /usr/sap/<SID>/SYS/global/hdb/opt/hdbconfig

If either one of these directories is missing, it needs to be created manually as user <SID>adm. This activity needs to be repeated on all SAP HANA nodes in a multi-node environment.

6

INSTALLATION

Commvault SAP on HANA agent can be installed from command line or using push install. Remember, this needs to be done on all SAP HANA nodes.

COMMAND LINE INSTALLATION

Command Line Installation needs to be performed using cvpkgadd. When running cvpkgadd, select SAP HANA agent. During installation specify:

• /usr/sap/<SID>/SYS/global/hdb/opt as SAPHANAEXE directory• sapsys as OS group (alternatively, one can create and specify on own group, but need to assign it

to <SID>adm as secondary group)

After installation, the link to Commvault backint executable should be available (if not, create it manually as user <SID>adm, see also next section):

PUSH INSTALL

After selecting the SAP HANA agent, make sure you enter the correct OS group (see above) before pushing out the agent.

For V11 up to SP3, the path for SAPHANAEXE is not requested by the installer. Therefore, the symbolic link to Commvault backint must be created manually after completion of the push install. Starting with SP4, SAPHANAEXE path will be requested during push install.

7

CONFIGURATION

Before running Backups and Restores, the configuration must be completed by creating and linking a parameter file, creating a pseudo-client in Commvault GUI and switching on Backups via Backint in SAP HANA Studio.

BACKINT FOR HANA PARAMETER FILE

Once the installation is complete, the Backint for HANA parameter file (containing parameters for the Commvault SAP HANA agent) and the associated symbolic link from SAP HANA side must be created.

With Commvault V11 it is important to name the parameter file “param” and place it under /opt/commvault/iDataAgent. It should be given read-write permissions (664), assigned to group sapsys and owned by user <SID>adm.

For single-node HANA, the minimum parameter set to be included is CvInstanceName

Create required symbolic link in hdbconfig directory:

The configuration procedure must be repeated on EACH HANA node in a multi-node environment. A shared parameter file for HANA multi-node configurations can be used.

8

COMMVAULT® GUI CONFIGURATION

In Commvault GUI, a pseudo client for the SAP HANA instance must be created.

The client name is arbitrary and can be whatever is preferred by the user. In addition, the following entries are required:

• SID of the HANA database• <SID>adm HANA OS user• HANA instance number • Authentication credentials. There are two options here

• Provide an existing HANA hdbuserstore key. When created using hdbuserstore CLI, it needs to be associated with a database user having all privileges for backup and restore. In this case, no password is required

• Specify a database user which has all priviledges for running backup and restore operations along with its password. Commvault software will then automatically create a hdbuserstore key which is connected to this database user

• Location of the hdbsql command (run “which hdbsql” as user SIDadm on HANA machine)

9

• In the “Details” tab, the client name for all participating HANA nodes must be added. In this example a single node environment is configured and therefore only one hostname is entered. Please note, for HA or HANA system replication setups, the Primary Name Server must be the first client/node selected, followed by the secondary clients/nodes.

Under tab “Storage Device” tab enter Storage Policies, Dedupe and Compression settings as needed. As for setting up a suitable Storage Policy, it is recommended to configure the primary copy to go to a disk library. This is because HANA environments can easily generate thousands of logfile backup jobs per day. Backing up every single logfile to tape library or VTL would create a massive overhead and also wear out the hardware quickly. If a tape copy is desired, it is recommended to configure this as a secondary copy and run periodic auxcopy jobs every couple of hours to copy all new logfiles to tape or VTL.

Please note that the HANA GUI instance is simpler in Version 10. This product version also does not support subclients and Intellisnap for HANA. With Version 10 HANA backups can be scheduled by using a shell script.

SAP HANA STUDIO CONFIGURATION

What needs to be accomplished here is to make sure Backint is enabled and to configure this backup method both for data and log file backup. Now start SAP HANA Studio GUI and open the backup console and respective SID.

10

After clicking on “Configuration” and “Backint Settings”, one will notice that HANA has already detected Commvault SAP HANA agent as it has found the symbolic link in the expected place. The previously created parameter file should have been detected as well (if not just enter the HANA-side path to symbolic link). Tick the box that instructs HANA to use the parameter file both for HANA data and log backup.

Now all data backups will go to Commvault, but logfile backups will still go to file (which is the default). In order to change the log file backup destination to backint, go to “Log Backup Settings”. In order Under “Log Backup Settings”, select “Backint” as Destination type, then enable automatic log backups and specify an appropriate backup interval. For testing, a 5 minute interval should be fine in order to see quick results.

Finally, don’t forget to save the settings in SAP HANA Studio. After a while, one will notice logfile backups coming into the Job Controller view.

11

ENHANCED MULTI-STREAMING

For newer versions of SAP HANA SPS11 and above, and as of Commvault V11 SP4, enhanced multistreaming is available. Enhanced multi-streaming works through the new global.ini parameter parallel_data_backup_backint_channels on the HANA side. For more information please follow the link in the online documentation for Best Practices for the configuration in Commvault and look it up in SAP online help for HANA-side configuration. Note that adding streams will require additional memory and may result in a backup error with an “Out Of Memory” error. If this occurs, “data_backup_buffer_size” parameter in the “global.ini->backups” HANA Studio configuration section may need to be reduced to allow for more streams. The default parameter value is 512MB, but reducing to 256MB may allow for the backups to run with additional streams (if more memory cannot be added to the environment).

BACKUPS

TRIGGERED BY SAP HANA STUDIO

Full, incremental, and differential database backups can be initiated from SAP HANA Studio GUI. Alternatively, a shell script using the respective HANA “hdbsql” command can be used.

For running a full backup to SAP HANA Studio, right click the SID and select “Back Up”.

Select “Backint” as Destination Type and decide on backup type (full, differential or incremental). One can also decide on a specific backup prefix, then hit continue:

12

On the next screen, hit Finish. Note that the backup is starting. One can watch all four HANA servers being backed up in parallel.

In Commvault GUI a new job is displayed of the type “Application Command Line Backup” as this was started from the HANA machine. By checking Commvault’s backup history, one can see the successful differential backup and a number of logfile backups which happened in the meantime. Please note that HANA Backup Catalog Backups also show up as logfile backups (marked as “log_backup_0_0_0_0” in HANA backup catalog details)

When opening HANA’s backup catalog, one can easily correlate the listed jobs with the Commvault job history by clicking on a single job and looking at the backup identifier (EBID). The last number in the identifiers is the Commvault job ID (in this example job 12699 and EBID 62852948_12699, see below). One can also see that the highlighted job is a differential backup consisting of multiple backup pieces, representing the different HANA servers. By right-clicking on a specific job it can be deleted from SAP HANA history and optionally from Commvault backup history at the same time.

13

SCHEDULING OF BACKUPS

After saving the new HANA instance in Commvault GUI a “default” subclient will be created automatically. One can use this subclient or create additional subclients for scheduling full, differential and incremental HANA backups or for using Intellisnap. Please note that using SAP HANA incremental and differential backups requires SAP HANA SPS10 or higher. Scheduling can be configured at subclient level or via a schedule policies. HANA logfile backups are always initiated on the HANA side and cannot be scheduled using Commvault.

For scheduling with Commvault Version 10, one must create a little shell script, which invokes the HANA hdbsql tool. First step for this is to create a backup user in SAP HANA Studio (having all backup and restore privileges). In order to avoid having to specify a password clear text in the script, a special key (BACKUPOPERATOR in our example below) needs to be created in HANA hdbuserstore (with a password) and associated with the pre-created database backup user (which has backup and restore permission). This allows the use of the “-U” option of hdbsql in the script which doesn’t ask for a password. The script should also create and pass a unique identifier which will be shown in HANA Backup Catalog and allows one to understand which backup was run by whom and when. Here is a complete example script for a HANA instance HSB:

#!/bin/bash

TIMESTAMP=”$(date +\%F\_%k\%M)” BACKUP_PREFIX=”SCHEDULED” BACKUP_PREFIX=”$BACKUP_PREFIX”_”$TIMESTAMP”

su – hsbadm -c “hdbsql -i 0 -U BACKUPOPERATOR \”backup data using backint (‘$BACKUP_PREFIX’) ASYNCHRONOUS \”” RETURN_CODE=$? exit $RETURN_CODE

14

In Commvault GUI, one can then create a subclient under the File System agent on the HANA node (or control node in a scale-out setup). In the content tab, enter all HANA config file paths (we need to back up theses files separately as they are not covered by the HANA DB backup).

In a final step, one must integrate the previously created script into the subclient. It is recommend to add it as PreScan script, as this this will ensure that the scripts will be executed even if the file system backup fails.

Once a backup of this subclient is initiated, one will get a file system backup job along with a HANA full backup.

15

The name tag that was assembled by the script becomes the prefix of the backup name in HANA Backup Catalog, which makes it easy to differentiate between manual and scheduled backups.

SCHEDULING VIA SAP DB13/DBACOCKPIT

To schedule HANA backups using transaction DB13/DBACOCKIT, for instance in a “SAP Business Suite powered by SAP HANA” setup, one must create a new action, select the desired action type (e.g. Complete Data Backup) and choose “Backint” at “Destination Type” and make sure that “Backup Destination” and “UTL File” have the same values as in HANA Studio. Please note that UTL File is called Parameter File in HANA Studio.

16

HANA-SIDE TROUBLESHOOTING AND MONITORING

In case of issues, it’s always good to understand what’s going and what’s happened. On the SAP HANA side it’s useful to examine the backint.log and backup.log.

While backup.log is more of a summary of the backup activity, backint.log shows the actual backint (i.e. Commvault SAP HANA Agent) invocation and the CLI output of the agent. This log for instance allows you to see if your parameter file was found and all parameters were correctly passed over to Commvault.

17

Those logs can be found in SAP HANA Studio and also under

/usr/sap/<SID>/HDB<Inst No>/<hostname>/trace/backup.log /usr/sap/<SID>/HDB<Inst No>/<hostname>/trace/backint.log

RESTORES

RESTORING VIA SAP HANA STUDIO

In order to bring up the SAP HANA Recovery restore and process, right-click on the HANA instance and select “Recover”.

18

As HANA needs to be offline for the restore, one will be asked to agree to shut it down. In the following screen, one can also select between full and point-in-time recovery. One can also select to restore a backup taken from a different HANA system.

After selecting the recovery option, pick the desired full backup from a list of backups which is taken from HANA backup catalog.

19

In the next screen, please make sure you instruct HANA to use backint for searching for required log files. HANA will conduct this search before the restore is initiated.

All HANA services are restored at the same time.

After the restore is finished, HANA automatically requests all logs which are required to recover the database.

After the database recovery (according to initial settings) has finished, all HANA services are automatically started and the database is made available.

20

RESTORING HANA VIA COMMVAULT® GUI

As with other Commvault agents HANA restores can be initiated via selecting “Browse and Restore” when right-clicking on the HANA instance.

In terms of restore granularity it is currently only possible to restore the entire database. In the final screen one can decide between full and PIT recovery, enable a data-only restore or optionally remove all existing logs for log area. Once the OK button is clicked, the restore job will automatically shutdown the database, transfer the data and startup HANA again after the recovery phase.

21

HANA DATABASE COPY

Database copy is an out of place restore in conjunction with a change of the SID. One can create the database copy on the same host or on a different host, for instance in order to create or refresh a HANA test or development system. Please note that any SAP-side restrictions affecting database copies using a third-party backup tool based on the backint interface apply. Please check SAP HANA Administration Guide and SAP notes for more details.

COMMVAULT GUI

A HANA database copy is a cross system restore from Commvault’s perspective. For this, one must start the restore dialog in the GUI from the source HANA instance. As an example, to restore database TR2 running on host hana3 to TD2 running on host hana4. Select “browse and restore” on instance TR2. In the final screen we need to select the correct destination client (HANA_TD2) from the drop down. This will also populate the “Destination Instance” field. If more than one HANA instance runs on the destination, make sure to select the correct one. Furthermore, please make sure to select the “Initialize Logs” option which will clean up the log destination so that no remaining logs from the old target instance can prevent proper recovery after the database copy. Once the OK button is clicked, the database copy will run fully automated. There is no need to apply changes to the HANA parameter file. Everything will be handled automatically in the background.

22

SAP HANA STUDIO

In the next example, to do it the other way around and restore database TD2 to TR2 using SAP HANA Studio. The major differences between creating a database copy via Commvault GUI and via HANA Studio are:

• A SAP-defined, special naming convention for the HANA parameter file on the target machine needs to be followed (see SAP HANA Administration Guide, chapter 7 for more details). The SID of the source database as part of the parameter file name of the target database instance

• The parameter SrcCrossClient needs to be present and point to the source database host. Please note that this parameter is set automatically if one restores via Commvault GUI

This means for example:

The correct parameter file needs to be configured in HANA Studio as well:

23

The database copy can now be initiated on the target system by selecting “Backup and Recovery” -> “Recover System”. After deciding between full and point-in-time recovery, one must enable the “Backint System Copy” option on the following screen and enter the SID of the source system.

Now HANA requests (from Commvault) the backup catalog of the source database which eventually gets displayed in the following screen, where one must select the desired full backup to be restored.

24

Make sure that the correct source system gets displayed. In the next screen it is important to enable the initialize log area option again.

This screen indicates that the database copy was successful.

INTELLISNAP® FOR HANA

As part of Commvault V11 SP3, Intellisnap® for SAP HANA was introduced. This feature is based on the SAP HANA snapshot interface and fully SAP-integrated. Before starting, please note that a couple of restrictions/caveats are important to understand. As of V11 SP3 only single-node (scale up) HANA configurations are supported by Commvault. From the SAP side, snapshot backups of HANA Multi-Tenant Database Container (MDC, see next section) setups are currently not supported. Please see SAP Note 2096000 for details and possible changes with future SAP HANA releases.

25

PREPARATION

Using Intellisnap for HANA requires some preparation. First of all, one must install a Commvault Media Agent instance on the HANA client machine (in addition to the HANA agent) and apply SP3 on all Commvault components. Secondly, it is important to understand that Commvault snaps the HANA persistent data storage area only. On the HANA side, one must find out where the persistent data storage area is located. This information can be found in the persistence section of global.ini file. Look for parameter basepath_datavolumes. Making sure that the persistent data storage area sits on a storage LUN which is supported by Commvault Intellisnap. Please note that HANA log backups will always run in the streaming fashion.

In case of running SAP HANA in a virtual machine and want to use Intellisnap technology, one should be aware that the HANA persistent data area cannot reside on a VMDK disk. Intellisnap only supports storage mapped into VMs via:

• NFS• iSCSI

It is sufficient to only place the HANA persistent data area on such a LUN or NFS share.

Once the storage-level configuration on the HANA side is done, some configuration work needs to be done on the Commvault GUI. First, enable Intellinsap on the pseudoclient level in advanced client properties area. Then configure the storage array hosting the HANA snapshot LUNs. Click on “Manage Array” for this configuration. It can be sufficient to enter here a user and a password, but depending on the storage product in use it might be required to enter additional information. See Commvault Online Documentation for more details. This configuration is pretty much the same for all Commvault agents supporting Intellinsap.

26

In a next step, create a new subclient under the HANA instance. Make sure to associate this sublient with a storage policy that has a primary snap copy configured. In the “Intellisnap Operations” tab, enable the Intellisnap option on the subclient level and also select the correct snap engine for the storage product in use. Finally select a so-called proxy which will create snapshot copies to disk or tape by mounting the snapshots. Any media agent running the same OS as the HANA clients can be leverage for this.

BACKUP

When manually initiating a new HANA snapshot, one will notice that only full backups are available (and supported). By checking the job monitor, notice that the job is marked as a snapshot backup:

In HANA Studio, one can also follow the snapshot creation while the job is running:

27

Once the job has finished, it is correctly displayed as a snapshot in HANA backup catalog.

Using “List Snaps” (on HANA instance level), one can monitor snapshot operations conducted by Commvault.

HANA Snapshots can be selectively copied to disk/tape using the Backup Copy function of the storage policy.

28

RESTORE

Restoring from HANA snapshots follows the described procedure via Commvault GUI. All one needs to do is select a snapshot backup job, go through the dialog and start the restore. In this case, the relevant snapshot will be mounted on the target system and all files will be copied from there. The performance of this restore variant is largely depending on configuration and throughput of the entire data path (Storage, SAN, LAN, etc.). Many storage vendors also support a so-called revert restore, where no data is transferred. Instead, the snapshot is transformed into the primary data volume. This restore option is usually much faster as it usually takes only minutes. It is recommended to take a new snapshot backup immediately after the revert restore has finished. This is because the revert operation usually invalidates all newer snaphots which were taken after the snapshot which was used for the restore. Revert restore can be enabled under advanced restore options (“Use hardware revert capability if available”).

Please note that restoring from Commvault Snapshots is currenty not supported via HANA Studio.

To restore from a snapshot copy (residing on tape or disk) using via HANA Studio or command line, include the parameter CV_restCopyPrec alongside with the number of the storage policy copy in the parameter file. When restoring from snapshot copy using Commvault GUI, configure the “Copy Precedence” tab under advanced restore options. In this case, the parameter file can remain unchanged.

HANA SNAP CLONE

This section will cover the requirements and best practice for performing a SAP HANA clone operation using the SAP HANA iDataAgent in Commvault. The HANA Clone feature enables a user to quickly and easily stage a copy of a SAP HANA database that is being protected with the

29

Intellisnap feature of Commvault. The HANA database clone is established by cloning an existing Intellisnap snapshot backup. This can be useful when:

• A quick and storage efficient DB copy is needed• Performance requirements are not too high• DB copy has a limited lifetime requirement (for example: sandbox or training systems)

PREREQUISITES

The following prerequisites must be met prior to performing a HANA database clone operation.

SUPPORTED STORAGE ARRAYS

Currently, supported storage platforms are:

• Netapp• Pure Storage• EMC Timefinder Clone

SOURCE DATABASE PREPARATION

The source database must have the array mounted off the root partition on the server. For example, a typical file system for SAP HANA consists of 3 directories beneath a root “/hana” directory.

For example:

• /hana/data• /hana/log• /hana/shared

In the above example the data volumes are stored under /hana/data/<SID> where <SID> equals the instance name such as DB1 or TR2. Consequently on a typical HANA installation each of the 3 directories listed above would have a <SID> directory for each database installed and configured on the server.

When using Intellisnap the database would need to be stored in an array, so an administrator would potentially be tempted to mount the array in the <SID> subdirectory under /hana/data, but currently there is a limitation where the clone operation expects to see the data volume mounted directly under the root directory. So for this example the data volume is mounted under /hsnap where the log and binaries are left under /hana/log and /hana/shared respectively.

The structure for a database called TD3 would then appear as follows:

• /hsnap/data/TD3• /hana/log/TD3• /hana/shared/TD3

In this example, the source database is using a NetApp filer for the array, and the data volume is attached as an NFS mount:

hana4:~ # mount |grep hsnap 172.19.122.103:/vol/DPR_HANA2 on /hsnap type nfs (rw,addr=172.19.122.103 hana4:~ #

30

CLONE DATABASE PREPARATION

The following additional steps are required on the destination in order for the Clone process to succeed.

• Create the clone instance/database on the destination. There must be a SAP HANA database existing on the destination in order to provide a target in the GUI for the clone. In this example a database called CL1 was created. The data paths for the data, log, and install volumes can share the same “/hana” parent directory.

• Register the clone database in a SAP HANA pseudo-client in the Commvault GUI. It can be in its own pseudo-client or may share the pseudo-client of the source DB to be cloned. Please refer to the previous sections and to the online documentation for creating a SAP HANA Pseudo-Client and creating a New Instance for a SAP HANA Pseudo-Client. Without the Clone database registered in the Commvault GUI it will not be shown in the drop-down list for the clone operation. For this example the CL1 instance was added to the existing pseudo-client for the source database TD3.

• The Clone database should also be configured with the symbolic links for hdbbackint as well as the param file prior to the clone operation. This is also detailed in previous sections and in the online documentation, see Configuring Multiple SAP HANA Instances and Creating the SAP HANA Parameter File

• It is not necessary for the clone DB to be running when the clone operation is started, but even if it is, the agent will properly shut it down before beginning the cloning process. In the example shown here the clone database CL1 was left running prior to beginning the operation.

CLONING PROCEDURE

Once the prerequisites have been met, the clone process can be run. Follow the steps outlined in the online documentation.

As detailed in the documentation follow the following steps:

• Run a full snap backup on the source database.• Right click on the source database, click All Tasks, Clone

31

• Select the default “Latest Backup” and click the “View Content” button. • In the resulting view select the database and click on the “Clone” button.

• In the resulting pop-up window select the destination client from the drop-down list (It will be the same client since we added the CL1 database to the same client as the source) and also select the destination database “CL1”

• For the “Destination Instance HANA Data Directory” point to the PARENT of the database directory “/hana/data” NOT the actual database directory “/hana/data/CL1”

• In the “Clone Options” tab there is an option to select “Snap Mount Location” as well as a “Reservation Period”. The snap mount location designates the temporary location where the snapshot will be mounted, and the reservation period determines the duration of time that the cloned database will exist. After that period expires, the clone is deleted and the snap is unmounted from the server. For this example the defaults will be used.

• After clicking the OK button one last dialog will pop up prior to initiating the clone process. Click the OK button to begin the cloning job.

• Note that 2 jobs will ultimately appear in the Job Controller… the GUI started restore, as well as a “command line restore” that the client iDA initiates.

32

• As the clone operation nears the completion, application log backup jobs will begin to appear in the job controller.

• At this point the clone operation is essentially complete and the CL1 database should be open and accessible in HANA studio.

• On the actual Linux host, one can see the location where the iDA mounted the snapshot by running the DF command:

hana4:~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 102096224 79742468 17167504 83% / udev 16504788 112 16504676 1% /dev tmpfs 25165824 72 25165752 1% /dev/shm 172.19.122.103:/vol/DPR_HANA2 19922944 9132544 10790400 46% /hsnap 172.19.122.103:/vol/DPR_HANA2_267937_SP_2_267795_8659_1475262087_CVclone 19922944 5536704 14386240 28% /opt/commvault/ Base64/Temp/267937

• Also if one were to look at the /hana/data directory one would see a symbolic link pointing to the mounted snapshot

hana4:~ # cd /hana/data

hana4:/hana/data # ls -l

total 4

lrwxrwxrwx 1 root sapsys 40 Sep 30 19:20 CL1 -> /opt/commvault/Base/Temp/267937/data/TD3

drwxr-x--- 3 cl1adm sapsys 4096 Sep 27 13:11 CL1.b4clone

• Note that the original CL1 directory did not get removed, but instead was renamed to CL1.b4clone. This is all done automatically by the agent during the cloning process.

• After about 1 hour (Or however long the clone was reserved) the clone will be shut down and the mounts removed. Also note that the CL1.b4clone directory renamed back to the original CL1.

MULTI-TENANT DATABASE CONTAINERS

SAP HANA Multi-Tenant Database Container (MDC) installations consist of a system database and a number of so-called tenant databases. The system database is the central component is it manages the global configuration. Tenant databases are isolated from each other and can be assigned to different applications, users or customers. All backup and restore operations (including tenants) go through the system database. However, tenant database have their individual backup catalogs.

A couple of SAP-side requirements and caveats are in place when is comes to protecting SAP HANA MDC installations via backint agents. First of all, HANA SPS 09 Rev 94 or higher is required. Please also note that currently only streaming backup is possible at this time (no snapshots) and restores can be in place only. See SAP Note 2096000 for more details.

33

CONFIGURATION

Configuring a HANA MDC instance on the OS level (installing the agent, symbolic links, parameter file) and in Commvault GUI is done via using the SID of the MDC instance and is not different from a non-MDC setup. In HANA Studio you will notice that only the system database has a configuration tab as part of the backup console. This is the place where you need to put your configuration in place as described before.

BACKUP

As of Commvaut V11 SP3, it is not (yet) supported to run and schedule backups out the GUI. This is planned for a later V11 Service Pack. Backups can be initiated via HANA Studio or using a script. In HANA Studio, when selecting “Backup and Recovery” on the level of the system database, one can kick-off backups of the system or a tenant database.

After selecting tenant, one can now pick which tenant database to back up.

Afterwards, the backup is started and progressing just like we are used to it. When the job has finished it is recorded in the backup catalog of the tenant database.

34

Please consult Commvault online documentation for an example of a tenant backup script.

RESTORE

Restores of SAP HANA MDC setup is supported via HANA Studio or via script. Restoring via HANA Studio starts with picking the desired tenant.

In the following screen, one is presented with the backup catalog of that tenant. After selecting the backup to restore from, start the process.

Please consult Commvault online documentation for an example of a script-based tenant restore.

HANA SYSTEM REPLICATION

This section will cover the requirements and best practice for protecting a SAP HANA System Replication environment using the SAP HANA iDataAgent in Commvault. SAP HANA System Replication allows to quickly and easily failover an active HANA database that is being protected with the Commvault HANA iDA to a standby node running a passive database instance. Installing the Commvault agent onto a replication environment will allow for protecting this replicated setup. This guide will cover the installation and configuration of a simple replication environment with one primary node and one secondary node.

35

INSTALL AND CONFIGURATION

Install and configure the software on each node in the replication environment as per the Installation and Configuration instructions in this guide.

Once the agent is installed on every node in the environment, the SAP environment must also be configured in HANA Studio to recognize the Commvault iDA. Follow the steps for SAP HANA Studio Configuration in this guide to configure the Primary replication node for backup. This cannot be done on the secondary node as it is in a “standby” operational mode, where it is not possible to configure the backup parameters.

SOURCE AND DESTINATION DATABASE PREPARATION (SAP CONFIGURATION)

The passive replication destination server is not accessible through HANA Studio so it is not possible to configure the backup (backint) configuration on the secondary server using HANA Studio.

However, since SPS12, HANA ini file parameter replication is possible, where changes made on the primary are automatically replicated to the secondary sites, including the backup parameters configured to use the Commvault iDA. This can be done with a configuration parameter called inifile_checker/replicate in the global.ini section in the configuration tab in HANA Studio. The default setting is false but setting this to true will cause the replication process to automatically transfer the backup settings in HANA for the primary database to the secondary database. If this is not done, then after a takeover occurs, the secondary will need to be configured BEFORE backups can run from that node. Another option would be to manually edit the global.ini file on the secondary to match the backup configurations on the primary once the primary has been configured. There is another parameter in the global.ini for inifile_checker/enable which is enabled by default, so once the settings have been changed on the primary node, the differences in the parameter file can be seen in HANA Studio by looking at the alerts tab in the Studio GUI.

36

This can be used to determine what needs to be adjusted in the secondary node so that after a takeover occurs the backups can start to run immediately without having to go through the configuration in HANA Studio on the second node after a takeover event. For example, here are parameters from the global.ini file on a test server in the lab:

[backup] data_backup_parameter_file = /usr/sap/PDB/SYS/global/hdb/opt/hdbconfig/param log_backup_parameter_file = /usr/sap/PDB/SYS/global/hdb/opt/hdbconfig/param log_backup_using_backint = true

[inifile_checker] replicate = true

[persistence] basepath_logbackup = /usr/sap/PDB/HDB02/backup/log basepath_databackup = /usr/sap/PDB/HDB02/backup/data enable_auto_log_backup = yes log_backup_timeout_s = 14400 log_mode = normal

The highlighted sections are the parameters that were updated on the primary through HANA

Studio when the configuration was updated for Commvault. Note that the “inifile_checker”

parameter is also stored here as well. If these changes are not made on the global.ini file on the

secondary node, the backups will not run to Commvault after a “takeover” occurs.

37

COMMVAULT CONFIGURATION

In the Commvault GUI under the instance properties of the HANA database, there is a “Details” tab

that contains ALL the nodes configured in the HANA replication environment. Here is a snaphot of a

lab server with two nodes configured in the instance:

Client Nodes listed here where primary must be first

Order of nodes can be adjusted here

As stated in the Documentation the Primary node MUST alsways be listed first in the details tab

or the backup when run from the CommServer will not work. After a “takeover” event the order of

these nodes must be updated in order to continue running the backups through the Commvault GUI

or Commvault scheduler. This can also be done from command line using the qcommand feature in

Commvault. For more information see the following link: Modifying SAP HANA Instances

Running backups through Hana Studio are not affected by the order of the nodes in the Instance

configuration, as long as the node being used to run the backup is listed in the details tab.

For running backups and restores see previous sections or the online documentation.

APPENDIX

SAP COMMANDS FOR MANAGING REPLICATION

Below are some common commands for managing replication in SAP HANA. These commands are run by the SAP

admin user <SID>adm.

COMMANDS FOR STOPPING AND STARTING HANA SERVICES

• sapcontrol -nr xx -function StopSystem HDB Stop the Hana services where “xx” = the instance ID of the services to stop

• sapcontrol -nr xx -function StartSystem HDB Start the Hana services where “xx” = the instance ID of the services to start

COMMANDS FOR STARTING AND STOPPING HANA REPLICATION

• hdbnsutil -sr_state Get the status of the replication configuration. Can be run on both primary and secondary

• hdbnsutil -sr_disable Disable replication. Executed from the Primary.

• hdbnsutil -sr_takeover Initiate a “takeover” process. Executed on the secondary node.

• hdbnsutil -sr_enable --name=<Primary Site Label> Enable Hana Replication. Executed on the primary node to start the replication process. “Primary Site Label” is

an arbitrary name to identify the primary site.

• hdbnsutil -sr_register --remoteHost=<Primary Host> --remoteInstance=<Instance #> --replicationMode= <sync|syncmem|async> --operationMode=<delta_datashipping|logreplay> --name=<Secondary Site Label>

Register secondary node to primary. Executed on the secondary node to register the secondary to the primary and synchronize the databases. The remoteHost and remoteInstance parameters define the primary host and instance, and the “Secondary Site Label” is an arbitrary name to identify the secondary node. The command to register the secondary node must be run from the secondary with the services stopped on that node. After the command completes the services must be started to begin replication. This is done using the appropriate sapcontrol command.

For more information on replication or these commands, please refer to the SAP documentation on how to set up

HANA replication. This can be obtained at the following SAP link: How-to Perform System Replication for SAP

HANA Guide

© 2017 Commvault Systems, Inc. All rights reserved. Commvault, Commvault and logo, the “C hexagon” logo, Commvault Systems, Commvault OnePass, CommServe, CommCell, IntelliSnap, Commvault Edge, and Edge Drive, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.

COMMVAULT.COM | 888.746.3849 | GET-INFO@COMMVAULT.COM© 2017 COMMVAULT SYSTEMS, INC. ALL RIGHTS RESERVED.