Depending on the space in the /hana/shared and the size of each set of backup files, we leave n number of days of backup on the Linux server (in our case will be 3 days). The second script we will call ZSYNC-CLEANING.sh this is a backup cleaning script for SYSTEMDB and TENANT NDB (in this case we name the SID of HANA as NDB) and its log backups – for HANA we schedule it in the root crontab also, since it synchronizes the data backup made in the HANA backup execution script. The delete is placed in the script so that it will also clean the old files generated in the destination since it will normally only copy the recent log files.ī. In this case, the “old” files will be erased and the cleaning will be in another script scheduled with root as well and that will synchronize the data backup made in the HANA backup execution script. This script is in charge of scheduling every 15 minutes in cron, between 5am and 11pm (data backups are executed at night). We will call the first script ZSYNCLOGS.sh.
We will create 2 scripts with the root user which will take care of the “files” issues to avoid the infamous “disk full situation” and other stuff that happens when the customer don’t have or accomplish with a “good” backup strategy.Ī. We will call this user ZBACKUP and it will have these privileges:ġ0. Then we’ll go to the HANA Studio and you have to create the user that will perform the scheduled backups. Executing mount should appear as a file system:ĩ. When you execute the cat on the file it should return something like this:Ĩ. EC2AMAZ-XXXXX/BackupsB1 /mnt/SAPBK cifs user=montaje,pass=123XXX,rw,users 0 0 We edit the /etc/fstab file with vim and write the necessary line to mount this shared disk and be accessible from Linux.
For this we should first create a user at the level of the local Windows instance which we will call “montaje” with a specific password and with the following permissions.
Once we have created the drive in Windows it must be “mounted” in Linux. Create a folder on /mnt (we could call it /SAPBK)Ħ. This drive must have at least 5-10 times the size of our full HANA backup, the idea is to have space to enter the backups of several days and thus have minimum data protection policies.
Create a drive, a disk unit, or a mapped unit on a Windows that has access to the Linux server where we install HANA to replicate the backups that we will take from Linux in order to avoid that if we lose this instance, we lose all the system information. This is just another one that can be used by technical consultants who implement SAP Business One or have to manage solutions of this type.Ĥ. In these types of clients, there is much less staff available to carry out the minimum backup / administration policies that a system that uses HANA requires, so in some way (and after installation) it is necessary to ensure its operability before untimely events during its life cycle.Ī quick way to do it, and with few resources involved, is by implementing scripts that run the backups on a scheduled basis, delete the old ones and copy them to another site outside the Linux server.Īuthor’s note: There are a thousand ways to do this “administrative task” (and that it is best to use the HANA Cockpit of that we are clear) to guarantee the minimum backup policies in the most economical way possible. to guarantee the data of the products that we can use in them, but these are sometimes not products chosen by some “very small” customers profile. Most hyperscalers offer replication solutions, data protection, etc. This happens mainly in On-Premise environments where the customer has to ensure the security and integrity of their data, regardless of whether the solution is installed under a hyperscaler or not. ĭue to the characteristics of this type of project and the target of some the clients, many times these don’t have the necessary infrastructure and the technical personnel qualified for the administration of HANA as it “should be”. When we starting with the operation of a SAP Business One on HANA 10 environment, sometimes you may find that there are no possibilities to install a SAP HANA Cockpit for the administration of the database HANA 2.0 or simply “it is not budgeted” in the scope of the project.