That's definitely useful and could be adapted for MySQL. I'm working on the basis that all our servers have 500GB drives but 100 days of daily backups is probably a bit extreme as you say.
Where the your backups automatically copied to the USB drives? Am having difficulty finding a reliable way of automating the mounting of USB drives on Ubuntu Server since device names can change. I've been reading about GNU PGP as that is how these guys from OpenEMR are doing it: http://www.open-emr.org/wiki/index.php/OpenEMR_Backup_Tools , but I'm also sympathetic to that school of thought that says don't encrypt because if you lose the private key then the backups are lost. We definitely will need to form policies around this, but for now I'm looking for ideas to present to our technical working group. Thanks On 24 February 2012 11:32, Bob Jolliffe <[email protected]> wrote: > 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] > -- *Rowan Seymour* tel: +250 783835665 http://twitter.com/rowanseymour _________________________________________ 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]
