I've recently started putting some Drupal installations in to source control. Editing modules and the like is pretty easy since they're obviously just text files. I run in to issues with the database though.

My current idea is to run a cron job to pull in database from the live server every night to keep things up to date.

The current method is to just drop the local db and then mysqldump the live one on to my local machine.

I'm pretty sure doing it the way I currently am could cause me to lose things like content types and fields if I make new ones on the local machine and then the 'outdated' live db gets pulled in.

What is the best way to approach this situation?

3 Answers 3


I haven't used this (but read about it today on this site).

Seriously look at the Configuration module. I have used Features and have seen their warts.

Since I'm not using Configuration myself yet, I am using Features + Git to check in the database on every-ish commit.


A small overview of how i'm using Features+Git+Drush. I try to use Features to store my configuration in a Features based module, but many modules still dont fully support code export properly. This becomes problematic. Even when using a custom install profile and hook_install or hook_update its a pain to try and create an initial configuration of a module that doesnt support code export properly.

So, try to grab all the configuration using Features. Then I use drush sql-dump with a site specific drushrc.php that sets a common key to basically ignore all cache tables.

Then when I feel I have "captured" most of the Feature into code. I use drush sql-dump to grab a snapshot of the development DB and make a commit of the website.

At some point I have a snapshot to push to a production website. Then I can use Drush from there to keep dev/prod in sync with eachother.

I want to try out Configuration next.

  • 3
    Can you explain your method of Features + Git to check in the database on every-ish commit
    – niksmac
    Commented Nov 30, 2012 at 6:42
  • Configuration module looks pretty great. Commented Nov 30, 2012 at 8:42
  • I have supplied an edit with more details.
    – tenken
    Commented Nov 30, 2012 at 15:34

It's important to understand the differences between the data of your site and the structure. You probably don't need all the data (new nodes, user information...) updated every day in your development site, What you need is to upload the new structural changes to your live site once you reach a stable point in your development.

I've been using a combination of git + features to develop my sites and keep them in sync between develop and live enviroments. With Features you can upload the structural changes to your live site without overwriting the database. When you reach a stable point in your development site you prepare a feature with the changes (content type, image style, views... whatever), save it to code and upload to your live site with the source control program.

Then only sometimes, when the content difference really is important I download the database to my local site, usually with drush.


If you have control of both servers you just use drush on a cron from the main server or the testing server. This details how to http://drupal.org/node/670460. It's the reverse process but it should apply. Take the steps put it into a php or .sh file and have cron do it at will.

There's a couple modules that do a similar things but not as nice as drush will. A direct sync from your databases will be heavy but probably faster and without the disk write and reed making it a bit faster especially if your doing it often.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.