Thanks for your reply, Toby! Sorry, I haven't checked the NetApp community site for some time. I took the post off after I created it, but was not aware that it still got posted. Anyway, we had to abandon the idea of installing Snap Creator on the management servers, because in our appliance, there is no interface setup to access the hana nodes, meaning, I cannot ping or access the hana nodes from the management servers. That's how the Cisco Appliance was setup.
So, we ended up installing Snap Creator (both Server & Agent) on a Windows Jump sever. HANA Client, HANA Studio & NetApp OnCommand System Manager were also installed on the same Windows server. I was able to setup, configure and successfully run backups and restore/recovery with no problems.
However, when I wanted to run the bash script mentioned in the document - 'TR-4313 HANA Backup and Recovery Using Snap Creator August 2015 pages 29-30', to clean up old log backups in the HANA database, I run into issues.
I edited the configuration files as menitoned in the guide. Here is the config:
On the Server config:
PRE_MOUNT_CMD01=SERVER:echo "This is run on the SC server"
On the Agent config:
command: /bin/su - pw1adm -c "/usr/sap/<SID>/del_log_files.sh"
When I run the backups they fail becasue it cannot find the path specified. Since, the Agent is running on the Windows server and the script is residing on Linux, it cannot find the path. Plus, I'm not passing any credentials to logon to the target HANA node to run the script.
Since, ours is a multi-node (2-node) HANA system, the Snap Creator Agent is not recommended to be installed on the HANA nodes as per the NetApp doc - 'Sanp Creator Framework 4.1.2 - SAP HANA Plug-in Operations Guide, June 2015, pages 10-11'. And we don't have any additional Linux boxes in our environment to install the Snap Creator Agent.
So, how can I run the bash script to clean up old log backups, with the setup we have?
A bigger question for us is - what is the NetApp’s best practice in implementing this kind of solution. It is important, because we will also be implementing Disaster Recovery setup using Asynchronous replication at a COOP site as described in the guide - 'TR-4279 HANA Disaster Recovery using Asynchronous Storage Replication March 2014'. The COOP site will have an identical 2-node system as production. Thanks.