Situation
failing to restore from backup on newer version
OpenEMR Version
I’m using OpenEMR version 4.2.2
Browser:
I’m using: Firefox
Operating System
I’m using: Xubuntu 17.04
I finally decided to upgrade the OS, but I wanted to make sure I could successfully restore OpenEMR from the emr_backup.tar file, as I have done in the past. I tried to install the latest version of OpenEMR on a different computer to test the restoration process. Of note, the other computer was running Xubuntu 18.04.
Initially, I installed using the openemr-php7_5_0.1-2_all.deb file. No apparent problem there. I then followed the restoration-from-backup procedure, which seemed to work, except that anything past the calendar frame was blank. After reading a few forum entrys/pleas with vaguely similar issues, I assumed it might be a PHP5 vs 7 mismatch. So I reinstalled Xubuntu 18.04 to wipe all traces of OpenEMR (it had just been newly installed anyway), installed PHP 5.6, disabled the PHP 7 modules and enabled the 5.6 modules, and attempted to install OpenEMR with the openemr-php5_5.0.1-2_all.deb. This resulted in failure, too, with a long list of not-installed dependencies (mostly php5 stuff and mysql/mariadb).
Is there some easy way to use my openemr_backup.tar file from a 4.2.2 version to restore to a newer version? Or is there some other easy-to-follow procedure to dump the database contents into a newer version, doing an end-run around the PHP issue? I don’t mind a lengthy procedure, as long as it works - I simply have almost zero working knowledge of SQL.
As an aside, I may not have made myself clear. You wrote “…one usually tests the restore process on a separate test instance of openemr…”. This is exactly what I had done, which I tried to explain with: “…I tried to install the latest version of OpenEMR on a different computer to test the restoration process…I then followed the restoration-from-backup procedure…” This is what failed (sort of).
On your suggestion, though, I tried again install OpenEMR to the different computer (my “separate test instance”, to use your parlance), but this time using the 4.2.2 .deb file. I got the same failure with the long list of not-installed dependencies. I realize that changes in OpenEMR (PHP5 to PHP7, etc) don’t necessarily happen in lock-step with changes to any given OS, including Ubuntu. However, I have successfully installed (and restored) OpenEMR onto the same OS (Xubuntu) more than once in the past, and the Ubuntu/Debian/Mint installation guide page still says “This is basically a one-click installation/configuration package for Ubuntu and Debian OS that also configures Apache and PHP.”
Unless anyone has a less “nuclear” option to advise, my next idea is to install Xubuntu 17.04 (outdated though it might be) onto the other computer, then attempt the install/restore procedure with 4.2.2. If that works (and obviously, it should), I’ll just “bootstrap” it thru to the most recent version, then re-install/restore it to the original computer, after upgrading Xubuntu.
Hi @rccapps ,
Rec using Ubuntu(or Xubuntu) 16.04 as the middle man here since it uses PHP 7.0 which both 4.2.2 and 5.0.1 are compatible with (rather than 17.04). Then when you get it up to 5.0.1, then you can bring it to 18.04.
-brady
Thank you, too, for your advice - a 16.04 test bed probably would have been the wisest choice, in hindsight.
But the good news is, it worked with 17.04: I installed/restored the original, then “bootstrapped” it thru to 5.0.1, then created a backup of that. Then I reinstalled 18.04 on the test-bed computer, installed OpenEMR 5.0.1, then restored the backup to it. It worked! So now, all I have left to do is upgrade or re-install Xubuntu with the latest version on the original server, and then restore OpenEMR as I did in the test-bed.
The lesson I’ve learned: I should do a better job of keeping up with updates/patches/upgrades/etc.