4.1.7 Backups

Any production use of OSCAR should be accompanied by a backup strategy that protects the data.  Here we suggest a two pronged approach. 

1. First, as an essential minimum, is simply a rotating compressed encrypted backup delivered to the network share of your choice accessible through OSCAR Admin.  The following describes the backup strategy automatically installed with Oscar15 when installed by deb.  Dynamically changing files will be backed up including the database and all downloaded files.  This ensures a complete backup of the "chart" in case of system failure.  The archive file of the uploaded files will become quite large over time, so we’ll only keep a month of copies on hand at any given time.  As the files generated are sitting on a network share or the server itself you will still need to arrange to have the backups periodically downloaded to removable media (eg disc tape or USB) and taken off site for storage.
2. Network shares are at risk of ransom ware and physical disasters such a fire.  Storage of an encrypted backup created as above onto one or several USB keys that the staff take off site is an inexpensive way to limit those risks.
   
3. Consider the option of having a mirrored server.  This level of complexity may be overkill for a small office, but its not difficult to arrange.  The documents are rsync-ed across to the new server which yields an efficient and functional backup of the part of OSCAR's data that quickly becomes the largest aspect of the regular backup as only newer files are copied over.  The database is also overwritten with a new copy in the middle of the night.  Loading the authors backup takes 3 hours.  The script can also serve as a basis for a test server where new configurations or versions of OSCAR meet the hard realities of real production data.
   

sudo crontab -e

And add to the existing file an entry so that the command looks like below

# m h dom mon dow command
01 23 * * * /usr/share/oscar-emr/backup.sh

You will be able to see the contents of the backup directory with the command:

sudo ls /usr/share/oscar-emr/backup/

These backup files can also be viewed and downloaded via the Admin->oscarDatabase/Document Download tab from within OSCAR.

Restoring the backup

In order to restore the backup you need to know all the encoding details that were selected during the encryption process otherwise you get an unreadable binary file.  The relevant details are

• the cipher used
• the password used (plus the initial vector if applicable)
  
• if the file was salted (and the salt string if no key was provided)
• the format (eg encoded with -base64) and the padding
• if the documents were stored in a incremental backup
  

Assuming you have not deviated from the default, de-encrypt the backup with the following command.  Eg for the backup files created on Feb 18th, 2017 the parameters will be

openssl enc -d -aes-256-cbc -salt -in Full.OscarBackup.oscar_15.2017-02-01-23:01:01.tar.gz.enc -out FullOscarBackup.tar.gz 
openssl enc -d -aes-256-cbc -salt -in OscarBackup.oscar_15.2017-02-18-23:01:01.Document.tar.gz.enc -out OscarDocumentIncrementalBackup.tar.gz
openssl enc -d -aes-256-cbc -salt -in OscarBackup.oscar_15.2017-02-18-23:01:01.Database.tar.gz.enc -out OscarDatabaseBackup.tar.gz

gunzip OscarDatabaseBackup.tar.gz 

mysql -uroot -p******* oscar_15 < OscarBackup.sql

For documents you need to decompress the remaining files.

tar -pxzf FullOscarBackup.tar.gz
tar -pxzf OscarDocumentIncrementalBackup.tar.gz

Test that you can open the backup and read the contents before you depend on this script. Windows™ and OS X™ equivalents to openssl and tar are available to test the integrity of the backup on those systems with details available elsewhere. 

http://gnuwin32.sourceforge.net/packages/gtar.htm

http://www.slproweb.com/products/Win32OpenSSL.html

Large Backup

Over time the OscarBackup.sql grows to multi gigabyte proportions.  The above mysql load is very slow and may even stall or appear to stall.  One can be patient but if your system is resource challenged it is possible that the backup fails.  One approach in these circumstances is to split the backup into multiple files with something like

awk '/^DROP/{close("file"f);f++}{print $0 > "file"f}' OscarBackup.sql

#!/bin/bash

# loadMysql.sh
# loads a sequence of SQl files named file, file1 etc into the Oscar Database 

# you can split OscarBackup.sql into individual tables with
# awk '/^DROP/{close("file"f);f++}{print $0 > "file"f}' OscarBackup.sql

for f in file*; 
do 
	echo "processing $f";
	mysql -uroot -p******** oscar_15 <$f &
	wait $!; 
done