There is a module for this: https://wiki.openmrs.org/display/docs/Database+Backup+Module . I don't think its quite as full featured as what you have in your script, but it could be cultivated to be so.
Ben On Fri, Feb 24, 2012 at 7:44 AM, Rowan Seymour <[email protected]>wrote: > Changed the script to make daily/weekly/monthly dumps each with their own > expiration times like the postgresql example > > In a few months I may know if it works... > > Source at https://github.com/rowanseymour/openmrs-backup-tools > > I'll investigate mounting more but I think there still might be an issue > around unpredictable device names (/dev/sdb1 /dev/sdc1 etc) which might > break such a script. > > On 24 February 2012 12:56, Bob Jolliffe <[email protected]> wrote: > >> On 24 February 2012 10:11, Rowan Seymour <[email protected]> wrote: >> > 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. >> >> Yes. Though it was RedHat and I didn't set it up myself :-( >> >> This link ( >> http://cdfx.penguins-on-hudson.com/2010/01/20/automount-removable-devices-on-ubuntu-servers/ >> ) >> seems to provide some reasonable guidance on automounting based on >> wildcard /dev/sd*. >> >> OTOH you might not want or need to automount at all. Given that your >> script is going to run as a cron job you might want to explicitly do >> the mysqldump followed by mount the drive (if it exists), copy the >> dump, and unmount again. Automount or not, this last step is probably >> important if you expect the user to be just pulling the stick and >> popping in another. >> >> > >> > 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 >> > >> > ________________________________ >> > 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 > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>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]
