SugarCRM Disaster Recovery strategies

[jsbenson]

I'm trying to figure out how to provide Disaster Recovery/Business Continuity for my Sugar Open Source installation.

As a first cut, I was thinking of a warm backup approach using hosting service A to handle the primary instance, and then send periodic filesystem and MySQL backups over to hosting service B and script things in such a way that the backup site on B can be brought up on demand, reflecting the latest backup.

This would give me the ability to offer a fallback, read-only site where people can consult the system data but would have to hold their updates aside until the primary system on hosting service A was back up.

A second cut was to allow primary status to flip-flop back and forth between A and B, at the cost of some extra scripting complexity.

Then I remembered my experience running some other software inside VMWare virtual machines. Maybe I should just take a performance hit, run Sugar inside a Linux VM, periodically snapshot the entire VM (RAM+disk+running SugarCRM app) and FTP the snapshots to a backup virtual hosting provider. Theoretically, the application can come right back up as of the last snapshot courtesy of VMWare with little reconfiguration (save perhaps some IP address jiggling). No MySQL database sync, no need to quiesce the primary SugarCRM app (the snapshots can be taken off a running VM!), no separate filesystem backup restore issues.

Does anybody out there have experience running Sugar and MySQL inside VMs? Are there any gotchas I need to watch out for?

If they work as advertised, the Disaster Recovery advantages will make VM hosting practically obligatory for Sugar because CRM is definitely a mission-critical piece of the average business.

[egork]

Making a complete copy of a SugarCRM is not such a problematic task. We do it with CVS and a MySQL database dump. When all is set up, copy and restore on other system take minutes. So may be if you can live with daily backups, you can do it once nightly?

The question for me is, what to do with the stuff that was changed in the window after backup before the breakdown.
Synchronizing may be rather cumbersome. May be one could use the sync feature that is in use for the off-line client?

[jsbenson]

I currently use the sugar admin Backup feature to save the filesystem part (PHP code etc.), and MySQL Administrator gui to save the database part. Because I'm a belt-and-suspenders man, I also occasionally FTP the filesystem part as well.

However, my background is in fault-tolerant NonStop systems for enterprise computing so I'm used to systems looking after themselves to a greater degree.

So, I'm looking around for stuff like automatic remote database sync techniques to handle the MySQL part and maybe a cron job to snapshot the filesystem part on a reasonable cycle.

I suspect that virtualization will change the whole game once hosting services offer shared machines but private VMs, so that what belongs to your account is an entire instance of an OS, MySQL, Apache etc. and that everything that you deal with (the entire VM) will be backed up and can be restored as a whole. Support will be more problematic since there will be MySQL and Apache instances per user in this scenario, and unless they are locked down so the user can't malconfigure them, support costs may get out of control. Because of this, virtualization will probably put intra-VM problems squarely on the back of the account owner whereas now the hosting service is responsible for keeping shared Apache and MySQL instances up and running. But the backup/restore power and business continuity features that accompany it will probably drive adoption of the virtualization approach quite independently of whether it optimizes hardware resources or not.

[al3]

Let me ask this question again looking for a more specific answer.

1. I have Sugar on remote server AND local machine (Mac Mini... works great... don't laugh).

2. All production work done on server.

3. I do an hourly sqldump on server MySql database and store it in a directory

4. Once a day I want to manually ERASE the local database and manually download the sqldump suck in all the stuff from the sqldump.

What is the best-practice way to do this? Should I use the Sugar installer to re-create an empty database and phpMyAdmin to suck in the data? I'm afraid that if I manually 'empty' all the tables I might take out something that Sugar needs.

Please point me in the right direction. I'm technical enough to go from there.

Al

[al3]

Answering my own post: I did a phpMyAdmin sqldump with the "drop if exists" along with structure and data. I used the MYSQL40 compatibility 'feature" of phpMyAdmin. I don't know if that is necessary.

I downloaded the dumpfile to my Mac Mini and slurped it in with local copy of phpMyAdmin and it all worked fine. The only difference is that the login password changed to what what is used on the server... which is fine.

(Earlier I did the above but edited the dump file and deleted the "user" table sql and after the import the login was what it was for the local machine. I then went back and did the above just to see... and I'm fine with the login being the same on both local and remote.)

I hope this helps someone.

Al
The InsuranceSolutions123 Agency
Life, Health, Annuities in California
www.insurancesolutions123.com

[susiewilliams]

Thank you for posting your answer! I'm sure it will help someone.