fsgl wrote on Sunday, March 30, 2014:
In the transition from Windows to Linux, one cannot simply run the OpenEMR built-in backup utility in Windows and then restore in Linux because that utility is not reliable in Windows.
How does one transfer data from Windows to Linux?
Is it advisable to replace var/www/openemr/sites with htdocs\openemr\sites and var/lib/mysql/openemr with mysql\data\openemr?
If not, why not? Better alternatives to folder replacements?
cmswest wrote on Sunday, March 30, 2014:
do a regular install on linux of a new openemr
then grab the database -> export sql from phpmyadmin, see attached, and then import from command line on linux: mysql -u root -p openemr < backup.sql, it will prompt for mysql password
then you can copy over any custom source files from old htdocs/openemr
fsgl wrote on Sunday, March 30, 2014:
Thanks a bunch. Once again simple and elegant.
Hope that the work on AMC reports is progressing well and the practice has put its shoulder to the wheel.
I am rooting for the home team.
cmswest wrote on Sunday, March 30, 2014:
no prob fsgl, if you have timeout problems with too large of a database you might have to use mysqldump from command line in windows which should be located in the bin subdirectory of mysql’s root directory on windows
mysqldump -u user -p openemr > backup.sql
fsgl wrote on Sunday, March 30, 2014:
Our patient population is so tiny that calling it a nano-practice would not be hyperbole.
Thank you for the timeout work-around, nonetheless.
sunsetsystems wrote on Sunday, March 30, 2014:
Is there a tracker item for that bug? If not, we need one that articulates in what way it’s unreliable.
fsgl wrote on Sunday, March 30, 2014:
See Tony’s 9/22/12 post in this thread and Joe Holzer’s first sentence in this article.
When I did a restore in February 2013, .jpeg files, Impressions/Plans from LBV forms were lost and LBV Data Type Sizes had to be reconfigured.
CVerk’s script has remedied the problem completely.
sunsetsystems wrote on Sunday, March 30, 2014:
Thanks fsgl. I can appreciate that a large backup might run out of allotted temporary disk space, memory or execution time – but not seeing anything specific other than that. On a normally configured system with modest disk usage the built-in backup tool should work. If anyone knows differently and has more detailed info, a ticket would be appropriate.
And of course I agree that an automated and more robust backup system is also needed for production environments.
fsgl wrote on Monday, March 31, 2014:
You’re most welcome.
For small solo practices, it is rare that a cron job is needed for daily backup. It’s like teeth brushing, one forgets only if one is demented.
I do strongly concur that backup must be done everyday. From the numbers of views of the various backup methods, users don’t seem to care.
cverk wrote on Tuesday, April 01, 2014:
I had a PC with windows XP on it that I had taken out of use in my office and replaced due to lack of support. I reformatted it with Linux mint cinnamon after reading Brady’s post, and I have to tell you, it is remarkably better than previous times I have tried to work on Linux. So if anyone out there is still trying to decide what to do with windows xp, it may be time to look at Linux again with the above transfer instructions if you want it to host OpenEmr. Also the Debian/ubuntu install program worked flawlessly on Linux Mint.
fsgl wrote on Tuesday, April 01, 2014:
It was Jack Chan in Kuala Lumpur who first suggested the migration to Linux Mint 16. Rod seconded the suggestion. (Thanks again, gentlemen.)
Ubuntu was not hard to install but a bear to customize. The Linux Mint fan club is growing.
It seemed that Brady decided to switch on the premise that if old geezers could make the transition, likewise young folks.
htuckjr wrote on Wednesday, April 02, 2014:
Yes, Linux Mint is a winner; I’ve been using it for my daily netbook/ desktop for several years. It’s far less problematic than Ubuntu and is great for low spec computers. If one has the skills to set up OpenEMR, the Mint forums offer plenty enough help to customize a Mint install.
Mint uses the same software repositories and installation system as Ubuntu; Mint 13 is a Long Term Support (LTS) release based on Ubuntu 12.04 Pangolin and will be supported til 2017. I believe the next Mint LTS release will be v17, to be released mid-2014. Mint 16 is the current release and is a good system but its repositories won’t be updated past Jul 2014.
fsgl wrote on Friday, April 04, 2014:
Hi Harley,
Used the same logic when I downloaded Ubuntu 12.04.4 LTS but got burned following some erroneous online advice for upgrading to Saucy Salamander. My desktop has a very old video card resulting in half sized green/purple YouTube flash images. Turned out that it was not a version problem but an acceleration problem. It was a big mess with a happy ending, the journey from Ubuntu to Linux Mint.
Read that if one is happy with Linux Mint 16, one does not need to upgrade to the next version. The upgrade process is far less simple than upgrading OpenEMR. No cake walk by any stretch of the imagination. More like a re-install. On the other hand, if LM 16 ceases to be supported, does it not become vulnerable? Probably less so than in the case of Windows XP; but less secure, nonetheless, if unsupported.
We look forward to more Wiki articles from your “pens”.
cravaus wrote on Sunday, July 13, 2014:
I was trying to migrate over from my Windows installation on my PC to a Linux installation on a Synology NAS running the DSM OS which is based on Linux but is not exactly like Umbuntu or Mint. It also uses MariaDB instead of MySQL. They are similar but not the same. So far I am finding ways to work with this.
I have tried using the Stephan’s method described above. When I used:
mysql -u root -p openemr < backup.sql
I was getting
Enter password: ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: YES)
I checked permissions in phpMyAdmin. I have temporarily checked all permissions for all users. This did not help. I tried several other command line solutions found on Google with no success either. I was frustrated.
My solution–use Bigdump
http://www.ozerov.de/bigdump/
I also made these changes in php.ini (in case size was an issue):
memory_limit = 512M
post_max_size = 512M
upload_max_filesize = 128M
I am not sure if this is optimal but it worked.
I dumped the file as fsgl recommends in phpMyAdmin however I also checked the “custom” radio button in the Export dialogue. I also checked “include column names in every INSERT statement” in the “Data creation options”. This is important for the import to go smoothly using Bigdump.
In phpMyAdmin in the new OpenEMR database I dropped all tables that exist. I then had the openemr database with no tables in it on the new system.
I loaded Bigdump in its own folder and edited the database configuration per the instructions:
$db_server = ‘localhost’;
$db_name = ‘openemr’;
$db_username = ‘root’;
$db_password = ‘my5ecurePA$5word’;
I put my dumped data from the old OpenEMR database in the Bigdump folder. I ran Bigdump. It slowly loaded the tables into the OpenEMR on my new server.
It worked. I deleted Bigdump from my system per the instructions. I copied over any custom source files from old htdocs/openemr as advised by Stephan. All is good. I think this will be my backup solution.
I hope this helps someone.
Craig
jcahn2 wrote on Monday, July 14, 2014:
Ahoy Craig.
Try your query with no space in the password parameter:
“-u root -popenemr” . Hope that helps. Jack
jackfruit501 wrote on Monday, July 14, 2014:
Try this if your backup is from the built-in program
mysql -u root -p openemr < openemr.sql
fsgl wrote on Monday, July 14, 2014:
Stephen’s advice worked very well when I tried the transfer from Windows 7 to LM 17.
Running mysqldump from the command line circumvents the problem posed by PHP timeout and large databases. CVerk had confirmed this in an earlier post about mysqldump in Windows. It was unnecessary to use the Terminal because phpMyAdmin worked well with our small file.
The mysql root password is completely different from the login password for the operating system, therefore mysqldump will not proceed without it.
Now the big fat problem for some Ubuntu/Mint users is the inability to run the backup utility, so forget about the restore script.
As Jack in Kuala Lumpur has kindly informed us, it’s not a problem in Fedora 20 but only with Ubuntu 14.04 and LM 17.
A Linux user should not be required to bifurcate backup into web directory and database dumps. This was not the case in Ubuntu 13.10 & LM 16.
Production copy is still in Windows 7. CVerk’s backup script works faithfully & restore is even easier than with the Linux restore script. No reason to change operating system for production until January 14, 2020 at which time this poster may well have transmigrated into a blade of grass.
cravaus wrote on Monday, July 14, 2014:
Even when I leave out the space I get:
ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: YES)
I think it is a DSM OS issue or the way they deployed MariaDB. At any rate, The Bigdump method worked. It is not that graceful but it does the job.
fsgl wrote on Tuesday, July 15, 2014:
For the benefit of other readers,
Jack in Sparta is correct when importing mysqldump in Windows, while Jack in Kuala Lumpur has the correct syntax for import in Linux. No space in Windows but 1 space in Linux.
Both dumps can be achieved from the Terminal. Either Jack should be able to tell us how to run the web directory dump from the command line. I’m still very green with this stuff.
yehster wrote on Tuesday, July 15, 2014:
Incorrect
Syntax between windows an linux is the same
mysql -u -p openemr
with the space will attempt to access the openemr database and prompt for the password
mysql-u -popenemr
without space uses openemr as the password and attempts to connect to mysql server without specifying a default database.
some of the confusion here is almost certainly because both the db password and the db name are called “openemr” in some of these scenarios.