The configurations used for backup and the scripts required for backup are described here.
Note: We have framed the technical requirements based on our understanding. Your suggestions are most welcome.
**Technical Requirements**
The configurations to be used are:
Backup: Yes/No
Types of backup: Daily/Weekly/Monthly
Backup location: ____
Delete Old Backups: Yes/No
Backup to be deleted after __ days old.
Convention for the backup File name: The timestamp can be added along with the backup file name
Scripts & cron jobs to be created: To take the backup, to delete the old backups
For Restore action:
List the available backups present in the backup location with the backup created date
For situations of data loss and data crash, the chosen backup database can be restored.
Administrative guidelines
• The backup disks need to be moved for different geographical location
• Securely erase all media before discarding
Agreed. Please note that each platform has its own unique backup protocols, so that may require a "platform specific" workaround if we are to satisfy the plan with a single distribution from OpenEMR. If we are not, then we may incur huge costs for multiple certs.
BTW - has anyone gotten a clear definition of what happens with certs as new releases occur? Unless it is a low-cost update, there will be a DIS-incentive to improve a "certified" version.
Presently my EHR has about 40 Gigs of data - it’s not feasible to create backups the way you describe, it would take too long. Instead I use MySQL replication. One computer continually backs up the server. I bring a notebook PC in daily and it also acts as a slave to the MySQL server; when turned on it then updates itself. Finally, I take the notebook to another location (happens to be my home), where another machine acts as a slave to the notebook computer. So there’s a live backup in the office, a backup on the notebook PC, and a backup on another Linux box at home.
I think there is a significant security flaw in the way OpenEMR handles documents. OpenEMR is saving documents as files on the server. If someone has access to the server and has a Linux boot disk to enable them to bypass the root logon, they can get access to the directory where the documents are stored (someone correct me if I’m wrong here - I’m running Linux on a few machines but I’m not an expert). I think it’s preferable to store documents in MySQL as blobs. My EHR is over 40 Gigs large because of the large number of documents (over 100,000) stored as blobs on the server. We do not have paper charts, everything has been scanned in for over 5 years now. Initially I kept the documents as native OS files but I decided that was too risky and a year or two ago I moved them all to MySQL tables. MySQL is fast enough that it is not a noticeable difference in speed to access them from MySQL. It IS necessary to increase the size of the maximum record that can be sent to MySQL - done with
maximum_allowed_packet
in the my.ini or my.cnf file. I set it to 512M, probably signficant overkill, because sometimes we scan in records obtained from another hospital or doctor, and I also scan in tax returns, payroll, etc. to other MySQL tables - those can be 100 pages or more.
If someone gains physical access to a machine then there’s not much that can be done to keep them from getting to your files, even in MySQL. For example, in your scenario where someone used a boot disk…they could restart MySQL with -skip-grant-tables and see everything in your database, including the image blobs.
A better solution may be to use LVM2 and an encrypted volume.
Thank you for the information. As I said, I’m not an expert, and that was something I did not know (starting MySQL with skip-grant-tables).
I still prefer to keep my documents in MySQL becs then master-slave replication keeps the backup effort to a minimum, but you’ve alerted me to an issue that is not easily resolved. Even if I were to encrypt the server’s disk, that wouldn’t affect the slave backups, 2 of which are Windows computers.
The other advantage (to me) of keeping the documents in MySQL is that they’re not easily copied or deleted from other computers on the network. I suppose the directory in which they are kept in OpenEMR is owned by OpenEMR only? Or can someone navigate to those directories via local network access?
To create encrypted volumes on Windows I think you can use TrueCrypt. I’ve never used it myself but I believe it’s free software.
We use live MySQL replication to create our offsite backups as well. I use rsync every few hours to copy the images. Perhaps storing images as blobs in OpenEMR could be added as an option.
The files are owned by the web server. I don’t think the default permissions would allow a regular user to blow them away. They might be able to read/copy them however. We don’t give regular users accounts on the same servers where we host the EMR so I haven’t had to think about that.
Something you should consider in addition to replication is periodically dumping your database to a file. I do this every three hours and I keep several generations on hand. If something were to happen that hosed your whole db, replication will dutifully follow through and hose your backups as well. I would then be able to go back to the recent 3-hour backup and restore it. I perform these dumps on one of the replication slaves so as not to disrupt the production machine.
I’m not too worried about the replication slaves being wiped out, because two of them are off-site and only connected when I tell them to connect; if I detected a wipe-out at the server I would just turn off replication at the remote site. I would then be only one day behind.
The database is just too large to dump every 3 hours. Even copying 40+ gigs from one computer to another over the network would probably take an hour.
An unauthorized user reading or copying the documents is almost as bad as accidentally or maliciously deleting them, though. I feel safer knowing they’re locked behind MySQL. It would require a sophisticated Linux user with physical access to the server (which, incidentally, doesn’t have a keyboard, mouse, or monitor attached!) to get to the documents.
I think this discussion reveals the most important point of backing up OpenEMR. That is, there is no single software solution.
I feel that the best OpenEMR can offer is what it does right now; a link to dump the database in a single snapshot.
The reality is that it’s up the the administrator of the system to apply their own backup strategy. Several have been discussed in this thread and more can be found by searching the forum archives.
This CCHIT requirement be solved with business-process instead of new software.