But to get two instance synched I need to know if it the db is the only one think to move daily/hourly from the first one instance to the second one.
My target is to be ready for a disaster recovery situation and have a place where test upgrades to new versions before upgrade in the production enironment.
as a hot-standby scenario you’d need to sync both.
There are multiple files that are being processed / accessed from the CRM.
Documents are files (not in a blob storage)
vardefs / customizations etc. if you used Studio to configure your CRM
languages - in case you have any additional ones installed
Uploaded files / images if you have any
Logo
etc.
If you are fine with a daily / hourly job, I suggest an rsync through a SSH connection.
For the DB I’ve been in projects with a master slave replica as well as dump / rsync / restore scripts.
It works both fine, rsync is most likely the easiest solution.
Probably, just because I host everything on AWS, I can setup daily snapshot and a procedure to restore one of them on a new AMI instance in case of emergency.
To finalize the setup a shell script to change Apache 2 configuration and install the HTTPS certificate.
All the procedure can take time…I have to think about it.
This is a list of some important files and directories (located under the legacy/cache directory). Where it says " Deletable?" “No”, then you must backup the directory and restore it on the new Suite system, to have a full working copy of the Suite system. To keep it simple, backup the entire cache directory and restore it on your other system.
SugarCRM cache directory – it is NOT a cache directory!
By Jason Judge on 2012-06-11 in development, SugarCRM
SugarCRM has a directory called “cache”. When the application runs, PHP scripts, JavaScript, CSS, images and so on, are cached in there. This is how SugarCRM allows modules to plug into other modules; the cached PHP scripts combine together lots of smaller scripts across the full range of modules.
But that is not all the cache directory holds.
There are also email passwords, encrypted with Blowfish. (Ed: There are images, and encryption keys required to decrypt all stored email passwords so your Suite can send and receive email!) There are emails, and email attachments. There are uploaded documents and files.These are not cache items. These are data, and have just ended up in the cache directory through historical accident.
What this means is that when you want to clear out the cache, be very careful what you delete in there. Also when migrating sites, don’t forget to pull the cache directory along too.
Here is a list of the main directories under the cache directory, with notes against those where you need to be careful. This is for the Community Edition (CE) and is unlikely to be the complete list when you take additional modules you may have installed into account.
Directory
Description
Deletable?
cache/
The root directory holding cache files and data.
No
cache/blowfish/
The encryption keys used to encrypt and decrypt email system passwords.Deleting this will mean the email login passwords can no longer be decrypted, and so the passwords will all need to be entered again.
No
cache/csv/
Temporary storage for CSV files that are being exported.
Yes
cache/dashlets/
Cache of dashlet PHP scripts, built from source scripts as needed.
Yes
cache/diagnostics/
Store for diagnostics when you run SugarCRM’s diagnostics tool.
Yes
cache/dynamic_fields/
Cache of custom modules and fields, pulling together many smaller files into larger files for speed.A “Quick Repair and Rebuild” will rebuild this directory.
Yes
cache/feeds/
Temporary cache of users’ RSS feeds.
Yes
cache/generated_forms/
Where web-to-lead capture forms are stored when they are generated.Whether these can be deleted, depends on whether you use them in-situ, or copy them for use in an external website.
Depends
cache/images/
Contains many different types of data. Do not touch. For the Community Edition (CE) this contains images that are temporarily cached before attaching to emails. For the non-CE versions, it contains much more permanent images related to the Knowledge Base.
No
cache/import/
Temporary cache area for uploaded CSV files, e.g. lists of contacts or leads.
Yes
cache/jsLanguage/
JavaScript versions of the language files, providing localisation for JavaScript functions at the front end.
Yes
cache/modules/
Caches code for modules, templates, views, vardefs etc.Most of these files can be deleted, but some of the subdirectories can not. See below for more details.
Partially
cache/modules/emails/
Directories for emails stored within SugarCRM.Each directory will link to a user that uses the built-in email capabilities of SugarCRM.
No
cache/pdf/
Temporary store for PDFs that are generated for end users.
Yes
cache/smarty/
Caches and configuration files for the Smarty templating engine.
No
cache/upload/
All uploaded files, e.g. documents uploaded as notes, email attachments, uploaded modules.
No
cache/xml/
Temporary files used to create graphs.
Yes
Folders that can be deleted (“Yes”) will generally be rebuilt automatically as needed.
Update for SugarCRM 6.5.8:
It looks like there are a few changes, and these affect the SugarCRM .gitignore script too.
The cache/blowfish folder has moved to custom/blowfish
There are some new folders: cache/htmlclean, cache/include, cache/layout, cache/Relationships, cache/themes, cache/upgrades
I suspect most of these new folders have just moved from other locations.