Quantcast
Channel: SAP Business One Application
Viewing all articles
Browse latest Browse all 219

How do I use the cron to schedule a backup

$
0
0

Introduction

There is a need to schedule a backup using cron. Cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule.  The SAP note 1651055 (https://service.sap.com/sap/support/notes/1651055) provides a backup script and PDF that explains how to use the script. 

 

The backup.sh file provided by the script will execute a backup, it will also show you a list of log files that can be deleted because they are included in a backup.  The script does not delete the log files.  This blog post will show you how to configure the script, how to execute the script and provide 2 additional scripts that can be used to clean up old log files. 

 

Everything shown below can be watched on a recording available from https://sap.na.pgiconnect.com/p93414224/

 

Script Prerequisites

Before the script can be executed you need to use hdbuserstore to create a user store key that will be used to logon to the SAP HANA DB.  The hdbuserstore file is install with the HANA client files.  You execute the program as ndbadm. 

 

The syntax of the command looks like

 

/usr/sap/hdbclient/hdbuserstore SET <KEY> <ENVIRONMENT> <USER> <PASSWORD>

Where:

- <KEY> is the identifier for the entry; can be freely chosen

- <ENVIRONMENT> defines the SAP HANA Database system in the form <hostname>:<port> where <port> is the SQL port of the indexserver process, i.e. 3<instance>15, <instance> being the two-digit instance number of the SAP HANA Database

- <USER> is the name of a SAP HANA Database user

- <PASSWORD> is that user’s password in SAP HANA Database

 

It looks like:

hdbuserstore.set.PNG

After the user store key is created, you can verify it exists using hdbuserstore list.

hdbuserstore.list.PNG

We are ready to configure the script.

 

Script Configuration

Download the script to your HANA Linux server.  I recommend keeping it in /usr/sap/NDB/home/scripts.  You will have to use the mkdir command to create the scripts directory.  I recommend keeping it here because it is central location with a clear naming providing information about the files contained within.

 

After you have the script uploaded to the SAP HANA server you need to set proper permissions.  This is done with the chmod command.  You also need to make sure it is owned by ndbadm and a member of the sapsys group, this is done with the chown command.

 

chmod 754 backup.sh

chown ndbadm:sapsys backup.sh

 

 

The script can now be executed, but execution will fail because we have not added our user key store to the script.  We add the user key to the script using the vi command.  In side the script we press the forward slash '/' to execute a search.  In the search box we enter USE_HDBUSERSTORE and press enter to execute the search.

searchVI.PNG

The first occurance of the term will be in the comments.  We need to change the value of USE_HDBUSERSTORE to TRUE

 

A few lines below we need to change USERSTORE_KEY to value of the key we created in the prerequisite section.  The example user store key name is DUNCAN.  Save you changes and exit vi.

 

Executing a backup

On the command line enter backup.sh.  The script will start after a built in delay as elapsed.

startBackup.sh.png

Verify the backup

It is possible you might see errors when the backup completes, like those shown below, and you want to verify it was successful.

BackupErrors.PNG

The backup is verified using backup.sh -ld. 

backup-ld.PNG

This shows that the backup was successful and I can ignore the generated errors.

 

Backup log file cleanup

In order to get a list of logfiles that can be deleted post backup you execute backup.sh -ll --backup-id=<backup ID>. 

We would use backup.sh -ll --backup-id=1374691689165 to get a list of logs that can be deleted post backup.

backup-ll.PNG

*|more is used here to prevent the output from overflowing the screen.  You do not need it and I will show a script that can be used to automatically cleanup these files,

 

Now, we have successfully execute a backup and seen the list of files that can be removed, how can this be automated?  I would propose the creation of 2 scripts, one is scheduled in cron the other is called by the scheduled script.  The scripts are GetLastBackup.sh and LogCleanUp.pl.

 

GetLastBackup.sh:

 

This is an sh shell script that uses a regular expression to get the last backup ID.  The last backup ID is used as a parameter for backup.sh -ll which redirects output to a file named "logsToDelete.txt".  The logsToDelete.txt file is used as an input parameter for LogClean.pl which deletes all listed files.

 

LogCleanUp.pl:

LogsToDelete.PNG

This is a simple Perl script that takes 1 command line argument, the name of the file containing the list of files to delete.  If no argument is provided it defaults to logsToDelete.txt.  It applies a few regular expressions to each line of the file and executes a delete.  The output looks like:

DeleteOutput.PNG

 

*More is shown because the script was executed with |more so output could be captured you will not see it when you run the scripts

 

After the first run of these scripts it is common to see rm: cannot remover file this occurs because the list of log files no longer required is not updated post delete.  The space is freed.  The backup runs as expected but the references are left. 

 

The Perl script's last output is how many files were remove.

DeleteCount.PNG

 

 

How to schedule the jobs

In Linux we use cron to schedule jobs.  We edit the cron using the command crontab -e.  This command execute vi on the cron table.  Note Linux only supports editing the crontab using crontab -e manually editing the table will not work.

crontab-e.PNG

*Note --retention=8 sets the retention time period for the backup.  It is not required.  The sample shown above is from an internal sandbox system and few backups are required

 

The numbers before the path to the script provide the frequency and time the job should run. The graphic below shows what each position means. 

 

 

cronTimeValue.png

 

After adding the jobs to the crontab you can verify the settings using crontab -l

crontab-l.PNG

 



Viewing all articles
Browse latest Browse all 219

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>