Hadn't thought of formalizing that. If people were regularly testing the restore process then it would make using encryption a bit safer because you always know that the dumps are able to be decrypted.
And that's also a good point about backing up the OpenMRS data directory as well Thanks On 28 February 2012 20:57, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > Rowan --**** > > Part of your strategy should be actually to install from > backup from time to time to make sure it works. That probably means > backing up your OpenMRS directory as well because of changing versions of > dependencies (although that may be more under control if you're centrally > managing the 70 sites). Perhaps the weekly or monthly backup could > circulate through the central office and it could be a central office task. > **** > > Saludos, Roger**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Rowan Seymour > *Sent:* Friday, February 24, 2012 7:45 AM > *To:* [email protected] > *Subject:* Re: [OPENMRS-IMPLEMENTERS] Strategies for database backups**** > > ** ** > > 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 > **** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > -- *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]
