Veeam B&R and SAP HANA

[AnshulNagori]

I am working with Veeam to understand the Veeam's solution for SAP HANA environment and I need your inputs on the following observation:-

1. Natively HANA data backups and log backups can be put into different repository. How we can do this using Veeam PLUG-in for SAP HANA?

Details:-
SAP HANA has a functionality to redirect data and log backups to separate backup destinations. For HPE StoreOnce, these can be 2 different Catalyst stores. Veeam B&R doesn't support this functionality. Both data and log backups, by default, go to the same Catalyst store.

I got to know that that's how Veeam HANA backups are designed. Functionality wise, this is fine. However, HANA data and HANA logs deduplicate differently. Typically logs deduplicate with a 5:1 ratio whereas data backups can go up to 20:1. When both these are put in the same Catalyst store, the combined deduplication ratio will tend towards 5:1 over time as there are significantly large number of log files than data files. A customer might wonder that they aren't getting the deduplication as promised by HPE. Hence, having data and log backups going to different Catalyst stores will solve this problem.

2. With image-level backups, does Veeam offer Professional services to manage and customize the pre-freeze and post-thaw scripts that are available on GitHub? Or is it left to the customer to manage and customize them based on their needs?


3. VM Reboot while image level restore or even Volume level restore

Details:-
While restoring a DB, like SAP HANA, from an image-level backup, Veeam B&R asks for rebooting the VM. Even while trying a volume-level restore, it asks the VM to be rebooted. The issue with this is that HANA volumes can get unmounted due to reboot if not added in /etc/fstab. Secondly, no other app that I have used, asks for the host or VM to be rebooted, in order to restore SAP HANA. This is specific to Veeam B&R. Generally, only HANA services need to be shutdown. A VM reboot usually require additional permissions from the admins as there may be other apps running on it. Can this be made as simple as restarting the HANA services?

Another thing with above restore method is that a HANA restore is a 2-step process. So with Veeam B&R, in the first step, the VM is getting rebooted. And in the second step, when we run the HANA recovery wizard, which shuts down HANA Services once again, leading to additional time and resource utilization, in turn increasing the RTO.

4. This question is related to HANA snapshot backups on Physical SAP HANA scale-out environment.

Details:-
SAP HANA Scale-out on bare metal is a configuration that is currently not supported by Veeam B&R. This config is slowly declining in the SAP world, but we do have several HPE customers running large scale-out clusters. If Veeam can support this, it will add more firepower to its support matrix.

Regards,
Anshul Nagori
Senior Technical Marketing Engineer
Solutions & Technical Enablement
HPE

[Andreas Neufert]

Hi Anshul,
I will answer here today. Thanks.

[Andreas Neufert]

Hello Anshul,

Thanks for sharing this feedback and your questions. I hope that the following explanations will give you some additional insights.
1)
If I understand correctly, the BACKINT target module needs to be the same for all Database and Log backups. Backup vendors can use the parameter files to hand over settings to the backup software. In some backup software, you can define the target storage (in Veeam “Repository”) to use different parameter files for the database and log backups to use different storage targets.
In Veeam, we try to automate everything as much as we can or use wizards so that you do not have to deal with parameter files. We also try to keep backup chains together on the same Veeam target entity of our software so that we can reliably manage backup chains and copy them around to different storage media types. Or use tiering models where we backup, for example, to disk and move older backups to more cost-effective media. The backup chains are also backed into the immutability processing, which needs to treat the backup differently based on backup chains. So, in the end, we will always write backups (database and log backups) to the same backup entity.
In the case of backup entities, we can use a classic Repository (one Server and target storage system) or we can use Scale-out Backup Repositories (SOBR) to leverage multiple backup target and multiple storage system together for optimized backup throughput in combination here with tiering to cost effective media for example. In the case of the SAP HANA backup scaling, if you use 4 channels, you could write in up to 4 target servers to 4 storage systems. We did this to address the demand of Enterprise customers that backup extremely large databases (you can go way higher in case of channel counts and server/storages if you like). This backup mode is called as well “Performance policy”. For image-level backups, there is as well the option to place full backups and incremental backups on different storages (possible in the “Locality Policy”). We will take your feedback here and think about if it makes sense to add additional capability in the case of Enterprise Application Plug-ins to place log backups on different extents (server/storages) with a Locality Policy enhancement for it. When you consider the SOBR capabilities in case of scale-out performance and capacity, it is the question if this enhancement would make sense. I will give you an example. When you have 2 storage systems and you backup databases and logs, wouldn´t it be better to use the performance of both in parallel instead of placing specific backup types on specific storage systems and having only the performance of this storage system?
Working with HPE StoreOnce team I know that each Catalyst store is its own entity in case of deduplication. There is no global deduplication between them. If you would store data in different catalyst stores the total capacity on disk is higher and so the solution is more expensive. We even got asked by HPE to offer a solution to let multiple Backup & Replication environments write into the same Catalyst store. See https://www.veeam.com/kb2987 . When you say that your customer would see less deduplication ratio in the UI and would change this if we would support it to a dual Catalyst Store configuration, it would mean that the customer lose some deduplication and the solution would be more expensive, just to see higher dedup ratio on one Catalyst Store, while less dedup ratio on the other, it is not in the interest of the customer.

2)
Veeam provides (sold) services through an accredited service partner organization. https://www.veeam.com/find-a-veeam-accr ... rtner.html They offer as well scripting support. The scripts provided at VeeamHub https://github.com/VeeamHub are just examples that can be changed by users/partners for the need of the customers. In case of SAP HANA pre freeze post thaw scripts, you just need to fill in I think one parameter (+prepare the environment for authentication). HPE has as well a service organization that is trained for Veeam.

3)
For this, you can use Instant Disk Restore https://helpcenter.veeam.com/docs/backu ... ml?ver=110
Instead of waiting for the restore, it will make the disk directly available (out of the backup) and transfers the data in the background back to the primary storage (or within a maintenance window). If you worried about the performance, then just wait until the transfer to the primary storage is complete. It should take a similar time compared with classic disk restore.
The advantage is, is that this is more flexible and the VM does not be in shutdown mode.
On the other side, the Normal Disk restore gives you the option to use a change block tracking restore approach (Quick Rollback), which only reverts the block changes back (less IO and faster), but as you shared, this needs a shutdown of the VM. https://helpcenter.veeam.com/docs/backu ... ml?ver=110
I have a car manufacturer that recovered with this a 10+TB database within some minutes with Quick Rollback after a software update destroyed data.

You see that the instant restore mode (even when you wait for the data transfer to complete if you are concerned about IO) was built for your requested scenario.

Other option would be to use our Agents and there recover the volumes while the system runs (physical server mainly). https://helpcenter.veeam.com/docs/agent ... tml?ver=50 (of cause you need to unmount the volume before you start restore).

4)
You can backup scale-out environments with our current BACKINT based backup approach and the new Application Backup Policy in our upcoming v12. It uses database (full/incr/diff backup) + Logbackup (orchestration/monitoring).
For the snapshot prefreeze-postfreeze approach you would need to enhance the sample script a lot.
For example use external scheduler or the Job Pre/Post processing (not the VM pre/post scripts) to schedule this. Create a script that connects to SAP and reads the cluster members. Prepare the snapshots as needed. Start the Image Backup Jobs and release the Snapshot within SAP HANA. Maybe you already have such a script based on some other solutions that you can adapt to Veeam.

You can always contact our Alliance Solutions Architects and me directly. Even writing directly in teams works between our companies. For the StoreOnce side, I suggest reaching out to Federico within your organization to discuss the enhancement of this product.