The Backup process

This page contains data on how to backup and restore the Shared Health Record using a script which creates backup files of the SHR database and the App Data folder, and copies them into an external server / machine specified by the user.

This process is only valid for linux SHR server machines, and not windows.

Backup steps,

• Download and edit a copy of backupScript.sh

The purpose of this file is to create a backup of the OpenMRS database and the AppData folder, and move it to an external server.

The contents of the file would be as follows –

# Dump the data from OpenMRS to a file

mysqldump -u root --password=test openmrs > /home/ubuntu/openmrs_bkup.sql

# Copy the AppData folder into /home/ubuntu

cp -rf /usr/share/tomcat6/.OpenMRS /home/ubuntu/

# Zip up the backup files

zip -r openmrs_`date +%y%m%d` openmrs_bkup.sql .OpenMRS

#Display new file

echo "created backup file : " openmrs_`date +%y%m%d`

#send the file into the remote server

scp openmrs_`date +%d%m%y` username@host:.

Make the following changes to this script

• Edit the MySQL login credentials (highlighted in red)
• Do not change the name of the time stamped zip file name created by the script
• Edit the file to include the username / host of the server where you want to send the backup file (highlighted in blue)

Configuring the backup machine

• Ensure that the zip package is installed
• Ensure that cron and crontab commands (which are installed by default) are working properly
• Set up the server to execute the backup script periodically
• Copy the edited script file into the server

Create a new cronjob on the linux server

• Execute the command crontab –e
• Edit the displayed cron job file to include the new job you wish to execute. The new command should reflect the number of repeats / schedule the cron job should be executed.

A sample command to execute the script file every five minutes would be –

*/5 * * * * /home/ubuntu/backupScript.sh > /home/ubuntu/backup.log 2>&1

Here, the log output created by the commands (success or failure messages / output of echo messages ion the script file) are written into the backup.log file.

One the cronjob is triggered, the backup files will be created and copied into the remote server specified in the script file.

Notes :

In order to run the same script multiple times on the same machine, we will need to clean up the previous backup files (zip + sql) so that fresh copies can be created.

The current backup script assumes that the machine the backup files are being copied into has not enforced any special security restrictions. However, tighter security restrictions may make it nessesary to modify the script file to match these needs.

Remote vs. local backup

 Considering the importance of the data, backups files should be physically moved to remote locations at least once a week.

Recovery procedures

 In the event of a failure, we can restore the system using the backup files. This process can be broken down into the following steps, 

•  Identify the most recent backup file from the list of available backups 
•  The backup file contains (a) an OpenMRS war file (b) a folder with the OpenMRS modules in use and (c) a sql backup script. 
•  First, restore the OpenMRS database using the MySQL script. 
•  Upload the OpenMRS war file into tomcat, and copy the module omod files into the app data folder 
•  Now, restart the tomcat and log in using the credentials used by the original installation
•  The system has now been rolled back to the most recent valid state prior to failure, and can be used accordingly. 

Monitoring the backup process

Currently, the backup process occurs once daily, and the resulting tar file is stored in the same server. These backups are not currently transferred into an external server. 

Therefore, the only way to monitor if the backups are successful is to do so manually by unzipping a backup file and checking if it contains all required files.