Contents
- Introduction to SAP HANA and BACKINT interface
- Native SAP HANA backup and recovery process
- Manually creating SAP HANA backup jobs in Bacula Enterprise
- SAP HANA backup configuration in Bacula Enterprise
- Manual SAP HANA backup initiation
- Backup administration using SAP HANA studio
- Manually creating SAP HANA recovery jobs
- Conclusion
Introduction to SAP HANA and BACKINT interface
SAP HANA is a complete relational database and suite of accompanying management tools to store, recover, manipulate, and analyze data. Like any good RDBMS it provides advanced tools for analytics and analysis, and also functions to allow data to be backed up into a standardized format and recovered easily and accurately into a new database when necessary.
“Backint”, on the other hand, is the name of the SAP HANA API that allows for a direct connection between SAP HANA database and third-party backup agents. This facility aims to ensure there are no interruptions between a database and a backup agent, making it easy for backups to be transferred via the SAP HANA database to a third-party backup server with the help of that same third party’s backup agent.
This kind of integration results in two different operation categories – in-depth backup agent parameter configuration with the help of the SAP HANA cockpit, and the actual execution of either backup or recovery processes using that same cockpit (via SAP HANA SQL commands).
Since backint offers direct access to a SAP HANA database, it is only natural for SAP HANA to have a list of vendors that are certified to create and recover backups of a SAP HANA database using backint. Bacula Enterprise is a part of this list, along with some well-known names in the field, such as EMC, IBM, HP, Veritas, and more.
This article details the process of SAP HANA backup and recovery with the help of Bacula Enterprise’s multifunctional SAP HANA backup plugin leveraging the ‘backint’ interface. But first we’ll look at how SAP HANA backup and recovery process can be done using nothing but its own, built-in backup and recovery tools.
Native SAP HANA backup and recovery process
In addition to backint, there are other existing backup methods. SAP HANA offers three different approaches to backup jobs – the first one being the aforementioned backint, while the second and the third one are file system backup and snapshot, respectively.
Backint as a backup type has already been explained above – an API-based backup method that is capable of bringing a variety of features to regular backup jobs, including data encryption, data compression, and more.
The snapshot-based backup is a completely different approach to the same tasks, since it uses the ability to create snapshots to back up not only the current data, but also data that is still being worked on. Unfortunately, this is just about as far as a snapshot as a backup type can go – with no consistency checks, no third-party feature integration, etc.
A file system backup is probably the most common backup type, creating extra copies of the existing data using one of several different backup types (full, incremental, differential). File system backups can also be checked for consistency, which is a big advantage on its own. They can also place a rather large strain on the company’s internal network in the process of backup creation, and monitoring the storage level is essential to avoid missing out the entire days of backup due to your storage being full.
Since the backint backup type is the closest one to the file system backup type, we can compare the two to see how different they are in the way they approach backup as a job. With that being said, we would be starting with native SAP HANA file system backup process, explained step-by-step.
First of all, it’s important to mention that a person performing a SAP HANA backup would have to have either a “backup operator” or “backup admin” role assigned to their HANA database user account.
Knowing that your account has sufficient privileges, the first thing you’ll have to do is of course, to open up HANA studio and connect to the system that you want to make a backup of.
To start up the backup process you’ll have to right-click the system in question and choose the “Back Up System…” option.
By default the backup wizard launches with standard parameters for both “Backup destination” and “Backup prefix” fields. You can change the default backup destination path by modifying the “basepath_databackup” line in the global.ini file. The default value of this line is $(DIR_INSTANCE)/backup/data.
Of course, you can modify this specific operation’s backup destination, as well as the backup prefix, in the same first window of backup wizard that we’ve just opened.
You can also see that the backup estimate can be seen from the first step of the backup process, close to the header of the wizard window. Clicking “Next” within this same window would lead you to the finalization screen that shows all of your future backup settings.
Clicking “Finish” in that window would start up the backup process. The entire process is also displayed in the separate wizard window, as follows:
As soon as the backup process shows a complete 100% everywhere, the process is complete and the backup files are created. It’s also possible to double-check the creation of the backup files via the command line.
Another way of performing backups with only the most basic SAP HANA capabilities is via the SQL command and through the SQL console. The command itself is as follows:
BACKUP DATA USING FILE (*****);
The ***** part represents the target backup destination and should be entered with single brackets on both sides, for example – (‘/usr/backup/data’).
Recovery part of your SAP HANA backup and recovery process is relatively simple, as well. You’re starting up in the same way as the backup process, but looking for the “Recover System…” option instead.
The first choice that you’ll have in this process is the recovery type. SAP HANA backup and recovery built-in software supports three main recovery types:
- Most recent state. For this recovery option to work properly you’ll have to have an entire last backup and logs available to be able to restore it.
- Specific point in time. This option attempts to restore the backup that’s closest to the point in time that you’re choosing.
- Specific data backup. Gives you a list of currently stored backups, and you can restore any one of the ones that you have.
Choose whichever you want and click “Next” in this window.
In some cases you’ll have to confirm the location of the backup catalog, as well. As soon as you’re ready, click “Next”. You’ll receive a notification warning you about the need to stop the database in question to perform a restoration process.
Clicking “Ok” on this notification would stop the database in question and take you to the next screen. Next you’ll have to confirm both the last backup that’ll be restored and the location of the log backups. The last two screens that you’ll see before the restoration process begins are the “Other settings” window and the “Review Recovery Settings” window. Choosing “Finish” at the end of the “Review Recovery Settings” window would start up the recovery process.
The recovery process itself is split in three phases: data recovery, log recovery and database restart. After all three of the phases are done, you’ll be given the “Recovery Execution Summary” window about either success or a failure of the recovery process. Clicking “Close” on this window finishes up the recovery process for your SAP HANA database.
After seeing how it works with the built-in tools, now we’ll go over Bacula Enterprise’s way of doing it. Bacula’s SAP HANA module offers a number of advantages when it comes to creating a SAP HANA database backup – including both significant speed improvements and smaller QoL changes. Let’s look at these clear advantage.
The first general advantage is all about small but useful additions to the classic backup process, such as backup scheduling, backup automatization, and so on. Bacula Enterprise’s SAP HANA module can also perform quick recovery, quick job creation, and many other operations.
The second advantage revolves around centralization – the ability to backup multiple different parts of your company’s infrastructure in one place with one unified control panel. That way, Bacula can create backups of your apps, your virtual machines, as well as many other parts of your system.
The third advantage might be the biggest one of the three, but it is not as obvious as the other ones – the existence of Bacula’s experienced support team that can help its users with a variety of backup-related questions. As such, clients can use Bacula’s support team to figure out what kind of backup would be the best one for their specific situation, as well as backup target location, backup storage type, and many other parts of their own backup policy.
The fourth advantage is the “elephant in the room”: Cost. Bacula’s overall price for SAP HANA functionality is almost negligible, making it fairly unique in the industry. That fact, coupled with Bacula’s policy of no capacity-based licensing, means the value gains are more than significant.
Manually creating SAP HANA backup jobs in Bacula Enterprise
Although normally the process of both backing up and recovering your SAP HANA database is automated using Bacula Enterprise or your specific SAP HANA infrastructure, we’ll go through the process of doing so manually using Bacula Enterprise’s SAP HANA plugin and the Bacula bconsole command line. The manual backup and restore procedure is chosen here to show all of the steps of this specific process.
SAP HANA backup configuration in Bacula Enterprise
To begin, SAP HANA backup plugin must be configured so that the Bacula Enterprise server and the SAP HANA backint process can authenticate and share data. This potentially complex process can be automated by running the included configuration script, which will prompt the user for the necessary SAP HANA information and store it for future backup jobs. Once this configuration script has successfully executed, backup jobs can be scheduled for regular operation or can be run manually.
Manual SAP HANA backup initiation
Next, let’s go through the process of initiating a backup job manually. The first step is to log in to a SAP HANA interactive console. The backint command is configured to send data directly to the Bacula Enterprise server. When running manually, you can also specify a job name and timestamp.
After running that command you should be able to see your brand new backup jobs, created by the backint command.
Backup administration using SAP HANA studio
There’s also a graphical way of managing backups that you’ve created, and it’s done with the help of a SAP HANA admin console, also called “SAP HANA studio”. This graphical interface allows you to initiate backups and also makes it easy to schedule runs of backint to initiate Bacula SAP HANA plugin backups. This leaves control of backup scheduling with the DBA, which is often preferable.
Regardless of how the job is initiated, you have a very detailed log of every job available via BWeb by clicking on the status icon in the same line as your backup job is (if the job is done correctly, it should be a white checkmark with a green background). For example, here is the backup job that was created in the previous steps, the first line is showing that there is a connection between the SAP HANA database and the server, and the rest of it is a detailed steps of the whole process, including the total size of your backup, how many files are in it, what’s the compression rate and so on. And the very last line should, of course, be the confirmation that everything went right – an OK status.
Manually creating SAP HANA recovery jobs
Now let’s move on to the SAP HANA recovery process. There are many ways to recover a database, including restoring a backup from previously mentioned SAP HANA studio or directly restoring a backup through the same backint command, but for the sake of simplicity in this example we’ve used the Bacula Enterprise user-friendly recovery script. All you need to do is specify a restoration point-in-time and the recovery script handles the rest.
After executing the script , recoverSys leads the process to check the database in question, to stop it if it’s running, connect to the Bacula Enterprise servers and to restore the data you need. Once the restore finishes you’ll see the console outputs showing that the process was a success.
You can also check BWeb to see your restore job logs and see in detail how the process went and that it was a success (confirming what was shown via the command line restore script).
Conclusion
As you can see, Bacula Enterprise’s SAP HANA backup and recovery plugin is capable of both backing up and recovering your critical data within SAP HANA databases and provides a number of options to script and automate the process or to leave it in the hands of the SAP HANA DBA. The Bacula Enterprise SAP HANA plugin is SAP certified to protect your data.
Creating SAP HANA backups turned out to be easier than I thought it was. Thank you for this article, it was an interesting reading material.
The versatility of Bacula’s BWeb interface never ceases to amaze me. And the fact that it also works with SAP HANA backup and recovery jobs is even more surprising.
Automatization for some of the steps of creating a SAP HANA backup seems like a good way to save both time and money. This was highly interesting.
How does Bacula support the procedure for database and log backup cleanup?
Can I define a retention period for database full backup, database incremental/differential backup and log backup individually?
Hello Thomas,
The retention of catalog backup, Full and Incremental/Differential backup are all set and handle through the SAP HANA mechanism, which then impact the Bacula retention accordingly. Bacula Enterprise Edition SAP HANA plugin is fully integrated with backint. It means the end user should follow carefully SAP HANA documentation on this topic and our best practice written in the Bacula plugin SAP HANA documentation.