Best practices for backing up Sugar instances

bsoremsugar —  January 24, 2013 — 4 Comments

We’ve often had questions come up on the forums ( like this recent one ) about what the best practice of backing up Sugar instances. Generally speaking, this is what we recommend…

  • Backup the database Sugar uses on a minimum of a daily basis. The most common people run into with Sugar deployment management is needing to undo a change made, and the databases we support have tools to handle this well.
  • Backup the codebase on a semi-regular basis. Typically most people make changes to the codebase very infrequently, and leveraging a VCS system is a good tool to use here ( see this blog post and this one for some ideas SDLC policies for Sugar ).

What are you best practices? Let us know in the comments below, as we are looking to have this post drive a KB article around this.

4 responses to Best practices for backing up Sugar instances

  1. 

    Here my feedbacks regarding our OnSite customers :

    – ok for the daily backup of database. Regarding customer’s SLA, we are generally performing one or two backups daily (every ‘noon and night)
    – we are committing any code change is source-versionning tool (git, svn, …) BUT we exclude of course some directories (such as cache, custom/working, custom/history). For example we never commit the “upload” directory that owns any attachement files uploaded by Sugar users in Notes. These files doesn’t have to be in versionning !
    – We are backuping every file in upload + copie of whole filesystem each time the database is stored, in order to restore both DATA + Files at a given datetime (else you would be able to restore Notes beans without the attachements (physicial data on filesystem), that is hmmm…. pretty “useless” from a customer point of view).

    Don’t forget the Upload dir, many many customer’s most important documents are in (PDF, Contracts, ….) :)

  2. 

    Here my feedbacks regarding our OnSite customers :

    – ok for the daily backup of database. Regarding customer’s SLA, we are generally performing one or two backups daily (every ‘noon and night)
    – we are committing any code change is source-versionning tool (git, svn, …) BUT we exclude of course some directories (such as cache, custom/working, custom/history). For example we never commit the “upload” directory that owns any attachement files uploaded by Sugar users in Notes. These files doesn’t have to be in versionning !
    – We are backuping every file in upload + copie of whole filesystem each time the database is stored, in order to restore both DATA + Files at a given datetime (else you would be able to restore Notes beans without the attachements (physicial data on filesystem), that is hmmm…. pretty “useless” from a customer point of view).

    Don’t forget the Upload dir, many many customer’s most important documents are in (PDF, Contracts, ….) :)

Trackbacks and Pingbacks:

  1. Backing up of SugarCRM - January 30, 2013

    [...] [...]

  2. How to move Sugar CRM from one server to another ? - February 5, 2013

    [...] [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s