For a consistent and supported SAP HANA backup with Veeam you must use the SAP HANA Backint interface. You can extend your restore capabilities of HANA systems by adding an image level backup of your HANA system (VM or physical) to your Backint based database backup.
You can leverage the SAP HANA pre- and post-scripts to create a consistent HANA database snapshot before taking an image level VM/physical backup. These snapshots do not verify the consistency of the database on block level though, so you should not only rely on these. Image level backups are great to extend your possibilities for restores. Like restoring from a complete system loss or providing a test-machine based on the latest backup via IVMR. These can be combined with technologies like storage snapshots to achieve very low RTOs.
The database snapshot taken during the pre-script process will be visible as a restore point in the native HANA tools, though it will only be available from the image level backup, as the post-script deletes this snapshot again from the productive system.
These kind of backups are mostly managed and leveraged by the infrastructure or backup team.
Note The method is not supported on multi-tenant environment
Backups taken via the backint interface will be checked for consistency and are fully supported by SAP. These backups are operated via the native SAP HANA tools, like HANA Studio, HANA Cockpit or via SQL scripts.
Log backups are supported and recommended via the backint interface. They can be configured via the native tools.
Restoring from these backups allows a lot of database restore scenarios, like rolling forward logs, etc.
These kind of backups are mostly managed and leveraged by the application team and DBAs.
It’s best practice to provide dedicated repository resources for application backups like SAP HANA. The data transfer will be directly from the SAP HANA system to the repository server via Veeam data movers. So each data stream from a HANA system will require a repository task slot. Running a lot of log backups might permanently block some tasks slots just for logs, so this should be taken into consideration at sizing.
Also the application backups to create a lot of metadata which is stored in the Veeam Backup & Replication SQL database. So make sure to not use SQL Express and have enough SQL resources and place the database on SSD to avoid performance issues.
For SAP HANA backint, most configuration items reside in a database configuration file called
global.ini. Inside it is a backup section with self-explanatory parameters 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 we 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.
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.
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
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.
- Veeam Enterprise Availability for SAP HANA Whitepaper
- SAP HANA Database Backup and Recovery
- Supplemental information to SAP HANA backups