Looking to create a rollback and recovery system that allows me to create monthly backups that are easy to use to do a restore with, but would also like to be able to log and rollback changes. It would be nice if the rollback system is not 100% linear, but able to clusters and type system dependences. Also, like it if the rollback system was a module, but that's not 100% required.

If you have any questions, just ask -- thanks!!

1 Answer 1


"The best way" is always hard to define. I think you have to make a difference between backing up code and backing up the database.

To backup the database, you can use the Backup and Migrate module.

To keep track of your code, there are many strategies. The simplest way (apart from doing nothing) is take all of your site's code and store it in a version control system (VCS) like SVN, GIT, etc. Myself, I'm considering to start using Drush Make for this. Drush Make is an extension for Drush, a command line shell and scripting interface for Drupal. It allows you to define your site in a .make file, describing the combination of Drupal core, contributed modules and custom code. Drush Make will then grab the code (from drupal.org, your SVN repo, or where ever it's at) and roll out the site. If you keep your .make file under version control, you can easily take last month's version and rebuild the code as it was then. Have a look at the slideshow For every site a make file to learn more about this approach.

  • marcvangend: Agree about code-VS-database, based on my limited understanding of Drupal so far, parts of the code based are managed by the database. For example, I believe the templating system creates tables for each template; this is based on me trying to remove default templates. Main focus is trying to manage client mistakes in being a webadmin, meaning deleting "stuff" by mistake or making a change to settings they didn't know they made. A true version control system will not auto-document in context what changes were made; again, based on my limited understanding. Thanks for posting!
    – blunders
    Oct 16, 2010 at 21:16
  • You are right that code and db are closely connected. A good backup procedure will allow you to go revert to both code AND db from a certain date. Reverting only db or code may cause problems. Of course backups are only a last resort; try to prevent accidental mistakes and incorrect settings by a) creating a user friendly interface, b) setting the user permissions so your clients can only access pages they really need, and c) training your clients. Oct 16, 2010 at 21:33
  • @marcvangend: Agree, and I've got A,B,C covered - just looking to see if there's a better solution than the raw dump to a point in time, verse an event driven system that contextualizes and manages reversion dependencies... :-)
    – blunders
    Oct 17, 2010 at 1:31

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.