Hi Rowan This script looks useful. Though 100 days worth of daily backup might be extreme (I know its configurable). It might be worth considering keeping generations of weekly and monthly backups and reducing the number of daily dumps. There is a script here which does the rotation on postgres dumps (pg_backup_rotated.sh) which could easily be adapted to yours http://wiki.postgresql.org/wiki/Automated_Backup_on_Linux.
What I have done before (long time ago) is have a system of color coded usb sticks - red, black, yellow masking tape + blue for weekly backups. And somebody's responsibility is to keep rotating the usb sticks in the machine every morning. The red, black, yellows just keep rotating. The blue one was copied off-site through physical transport. The file system on the usb sticks encrypted with truecrypt. Managing strong encryption and passwords is tricky though. In fact there is a school of records management thought that says that archives should NOT be encrypted in case the keys get lost over time, and physical security is the better guarantee. [There could be a case in Rwanda for a simple MOH PKI internal CA for managing keys for these 70 facilities which might scale better. There's already a couple of other use cases for this beginning to raise their heads.] In the end neither the encryption, nor the backup frequency/regime, are technical questions so much as ones of policy. Probably the best starting point is to ask for/assist develop relevant security policy for the EMR and build the technical solutions within that. In fact its only policy translated into HR directives and job descriptions which will ensure that the rotations and off-site backups (and crucially, the periodic restore tests) actually happen. Cheers Bob On 24 February 2012 08:23, Rowan Seymour <[email protected]> wrote: > At the Rwandan MOH we have 70 remote sites to deploy to soon and we need a > backup strategy that doesn't require great internet or IT capacity at the > sites. People have obviously tackled this problem before so am looking for > ideas. I think the general idea should be: > > 1. Nightly database dumps > 2. Delete dumps past a certain age to avoid filling up the hard drive > 3. Regular transport of latest dump to another location > > I've attached a bash script that I've written which will read database > connection details from the OpenMRS runtime properties file, dump the > database and delete dumps older than a configurable number of days. Easy to > hook this up to a nightly cron job. > > Not sure though about getting the database dumps to a different location. > Should we try to make it all automated via rsync? Should we rely on site IT > staff to copy dumps onto a USB device? Should those dumps be encypted? How > could we encrypt them? > > Ideas anyone? > > -- > > Dr Rowan Seymour > Partners In Health, Rwanda > Tel: +250783835665 > > > ________________________________ > Click here to unsubscribe from OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
