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 Instant VM Recovery. 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 linked script does not work in multi-tenant environments
Backups taken via the backint interface with the Veeam Plug-in for SAP HANA 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.
Plug-in backups will be transferred directly from the plug-in on the database server to the Veeam repository. Veeam data movers will be started at both ends of the communication channel and consume resources as written below.
Every single parallel backup stream will require a task slot on the Veeam repository side. Running a lot of parallel plug-in backups can consume a lot of repository task slots. As Veeam plug-in backups cannot wait for repository task slots to be free, they fail if there are no free task slots available.
Because of that you should use a dedicated repository for application plug-in backups to avoid issues with other backup types running in parallel. The dedicated plug-in repository can be configured with enough task slots to handle the largest parallel load, or can even be configured with unlimited task slots. For the latter case you need to control the parllel load from the source (database servers) side to avoid the repository running out of resources. Also consider that backup copy jobs for application backups will use task slots, too.
When you target a Scale-Out Backup Repository (recommended) which is dedicated for plug-in backups, you should use the Performance Mode setting. This way the single plug-in backup files will be distributed over the extents using all the available repository resources in parallel for faster processing.
Plug-in backups do create a lot of files and thus a lot of metadata which has to be stored in the Veeam configuration database. Make sure you have enough resources for your config database and are not using SQL Express when using plug-in backups.
The following processing resources are required for plug-in backups:
Veeam Backup & Replication Server A minimum of 2C/8GB for Windows + 1 CPU core and 1GB RAM per 5 concurrent channels.
Plug-in database server 1 CPU core and 200 MB of RAM per concurrently used channel.
Backup repository server 1 CPU core and 1 GB of RAM per 5 concurrently used channels.
Please be cautions to count number of database backups run in parallel, also consider the restore operations for the large environment where during the backup operations for database A and database B, you need to perform restores for Database C
Number of Numbers Channels * Number of Databases = Total Number of Channels Total Numbers of Channels / 5 = Amount of Memory + 15% Amount of Memory in GBs = Number of CPU Cores
5 Databases backup running in parallel with 4 parallel channels:
5 Databases * 4 parallel Channels = 20 Tasks 20 / 5 = 4 GB + 15% = 5GB Number of CPU Cores = 4 Cores
If you are using Veeam Agent to run the plug-in backups via pre- and post-scripts do include the repository channels for the agents job as well.
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?
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.
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.
Adjust this according to the configured number of channels. Consult the SAP HANA admin guide for details.
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.
- Whitepaper - Veeam Enterprise Availability for SAP HANA
- Helpcenter - Veeam Plug-in for SAP HANA
- SAP - HANA Database Backup and Recovery
- Supplemental information to SAP HANA backups