Drush Bam Civi Wham

A while ago I mentioned that I was finding the backup and migrate module a better option to syncing Civi installs that the Civi drush command and Lobo asked if I would do a write-up on it. I'm going to keep this pretty brief but I think it is worth telling people about as I find it really quick & easy. http://drupal.org/project/backup_migrate (AKA BAM) I've been pretty lazy with this module and haven't used it's full potential but basically what it allows you to do is to create a backup profile which is a mix of full table backups, table structure only backups and exclusions of tables you don't want to backup. All the stuff I am about to describe is configurable through a simple drupal front-end interface So, what I do is set it to back-up structure only for the sessions table, the various drupal cache tables, and the civi-cache tables. I exclude a handful of tables specific to our set-up. I also exclude the civicrm_domain table because that way I can restore the whole backup onto a staging install on another server (which has already been correctly configured) and it just works because the install specific settings are in the civicrm_domain table. You can backup to download which is not nearly as slow as you might think or to a pre-configured backup destination on the server. You can also schedule your backups and use more than one backup profile on different schedules (to different locations). Here are the possible location types: Server Directory Save the backup files to any directory on the server which the web-server can write to. MySQL Database Import the backup directly into another MySQL database. Database destinations can also be used as a source to backup from. FTP Directory Save the backup files to any a directory on an FTP server. Amazon S3 Bucket Save the backup files to a bucket on your Amazon S3 account. Email Send the backup as an email attachment to the specified email address.
And, the final selling point - BAM module is fully down with drush.

Comments

Eileen,

BAM is one of the modules I always install - and I set its schedule for short intervals during dev, and make manual backups before any tricky config.

It's also key to facilitate transfer of the site's database from one server to another (well, it's just a tad easier than migrating with phpMyAdmin)

I created a drupal.org forum topic extolling the virtues of BAM and suggesting it should be part of Drupal best practices: Best Practices: Backup & Migrate module facilitates emergency recovery and site migration

It has gotten me out of a pickle more than once, with the ability to rollback if unexpected results occur.

Cool - here is the correct version of that link from the above comment

http://drupal.org/node/806208 (it had an extra bit of html on the end of it)

Any thoughts on whether it is robust enough to flush the transaction log afterwards? We have a database which is too big to back up happily in the available disk space so I have been doing a very cut down BAM back-up. I'm happy with no backup of the missed data & cache tables.

Eileen-

It would be really great if you could save us the work of recreating the exact list of structure-only tables by posting your setup somewhere! Thanks for highlighting this - very cool!

Hi,

I exclude all the import tables & the civicrm_domain table (for portability).

I do structure only for the drupal sessions table and any table with the word 'cache' in it (civi tables end in cache e.g. civicrm_cache, civicrm_group_contact_cache whereas drupal ones are main_cache, main_cache_block etc)

I also use BAM a lot, including with CiviCRM, but on CiviCRM database I've only been succesful with manual backups using 'Advanced', not scheduled / with profiles. There seem to be some problems with backing-up non-Drupal databases:
- Backup CiviCRM database?
- Unable to exclude tables from non drupal db.
So how did you exlude those civicrm tables? And does scheduled backup (with a backup profile) work for you?

I've got the same question as Arjan. How do you exclude non-Drupal tables from an CiviCRM db? Do you combine the civi and drupal tables into one DB? With separate DBs on the same server, I'm unable to get a listing and choose CiviCRM specific tables to exclude. The listing of tables are the default options for Drupal. It seems that the options aren't dynamically driven by the selected database (which would be awesome!!) Using BAM 2.2.