is the directory where scanned documents are stored.
If you backup those files, you can copy them into the same directory of your fresh install, and have them available on the new copy. You might need to alter permissions on those files too depending on your operating system, but assuming an OpenEMR installation without customizations, backing up the database, and copying the sites/default/documents directory all of the information needed for a restore is present.
Great to hear that you have no problem with the built-in backup. Your 64 bit device saved you from the hassle of the gzopen bug some of us experienced with our 32 bit machines.
If I understand correctly, your backup method is described here but modified for daily instead of hourly mysqldumps.
I have attached a screenshot of the openemr/sites/default folder components. With a fresh install of OpenEMR there will be a brand new openemr web directory. The problem is that this web directory will be missing data not found in the database. Folder 1 will not have your scanned documents including copies of insurance cards. Folder 2 will not have Office Ally reports of accepted/rejected claims. Folder 3 won’t have the electronic remittance advice reports if your office downloads 835’s from Office Ally. Folder 4 won’t have the mysql user name and password if they had been changed. Not talking about the mysql root password which is another animal altogether. Folder 5 contains the code to generate the patient statements. Most practices have tweaked it a little bit. If you’ve never changed it, then it’s not a concern.
Chances are that Folders 1 and 2 are unique to your practice, thus you cannot just do a backup with only mysqldumps. You need to copy the openemr web directory from your office copy of OpenEMR as well.
The nice thing about the built-in backup is that it dumps your database and copies your openemr web directory fairly effortlessly. The task before you is to create a cron job for the built-in backup. In order to use the restore script, the backup utility has to be done first. It is equally easy to recover with it. This section in the Wiki provides very explicit instructions. Even your dog/cat can do it (tongue-in-cheek).
fsgl, i totally agree my previous back up was not complete with sql data only, and am happy the restore script works for you, not sure why it was not working for me. Kevin also mentioned how to manually backup the documents if a fresh install is done.
this will generate the 2 backup files at 1am every day and tar the 2 files into one, and put it in a different remote directory on each day of the week, so you get the most recent 7 days of backup any time you want. i do not know how to update the wiki, feel free to post it there should it be of any help. of course, one will need to change the password, user, ip-address, etc accordingly.
i believe this could be written into one shell script and have the cron doing the script, but do not have time to study that yet, as it is, it works well for me. only thing is you would want to have enough time in between each task so that it would have finished the previous one when the next task is scheduled to start. i leave 40min, that is ample time for a small practice like us.
It’s clear that the restore script will not work with openemr.sql.gz because it lacks the backup of the web directory and phpGACL, the other components of emr_backup.tar.
However it is not clear why it failed if the emr_backup.tar was successfully created in Ubuntu 14.04 and if both script and tar file were copied to the home directory for recovery.
Thanks for offering to add to the Wiki article. Info on how found here.
This is probably due to the security key found in sites/documents/logs_and_misc/methods
There are two files there, sixa and sixb. Using sudo permissions rename them to sixa.bk0 and sixb.bk0. When you log back into OpenEMR it will generate new files called sixa and sixb.