Scribble Designs: Web Design Northern Ireland

Backing Up Your Drupal Database

By gerardmcgarry on 24th April 2008, filed in Drupal, Web Applications. You can skip to the end and leave a response. Pinging is currently not allowed.

Being a WordPress devotee, the shocking thing about Drupal is that it doesn’t have a backup utility built into the core system. Any content management system that relies upon a back-end database should provide a way to back that database up regularly.

Shockingly, Drupal doesn’t. But it does have a dedicated community, and there are a number of options out there for backing up your database. The one which I’ve been using lately is the Backup/Migrate module.

This module makes it easy to do both on-demand and scheduled backups of your Drupal installation. With the on-demand backups, you can download them to your computer immediately. The scheduled backup saves the files to your webserver for downloading at a later date, and you can specify how regularly to back up and how many backup files to keep, so it’ll do the housekeeping for you as well.

Because Drupal uses relative hyperlinks by default, you can download an entire live website to a local server and use it to test themes, modules and Drupal upgrades without affecting the live environment.

This is more useful than you’d believe. I recently upgraded a Drupal site I manage, and the upgrade failed. I couldn’t get access to the site and thought it was ruined. However, I installed Drupal 5.1 on a local webserver and restored the database backup to that. I then upgraded that installation to Drupal 6.2 successfully. With a completely recovered and upgraded database, I was able to put this on the live webserver. We were up and running again relatively quickly.

I decided after that to test all my Drupal upgrades on a local server before doing the upgrade on a live website!

What’s missing (in my opinion) is a way to back up the uploaded files, themes and modules that each Drupal site contains. I want to look at some way to set up FTP synchronisation to back up site files on a scheduled basis.

If you’ve got any suggestions, please share!

5 Responses to “Backing Up Your Drupal Database”

  1. Brian Puccio said on April 25th, 2008 at 1:14 am :

    First hit when you google “drupal backup script” is this handbook page with scripts to backup and restore your site, including files and databases.

  2. sepeck said on April 25th, 2008 at 8:29 pm :

    I am not sure I agree with your assertion that their should be a built in way to backup your sites. In fact, I am fairly sure I disagree with it.

    Drupal is a flexible system that has a multitude of configuration options/setups and uses. It makes a predictable/automated one size fits all solutions more complex and better suited as an add on for those who desire it integrated.

    Drupal sites can easily scale to comprise multiple front end and back end servers and other complex configurations. The addition of multi-site setup where multiple sites share a same code base just add to the complications. The overhead cost of code that is applicable on a small percentage of sites just doesn’t seem worth including in core to me. (feel free to supply patches and advocacy in the issue tracker if you disagree, it is after all how features get added :)

    On my site I automated the back up of 10-15 sites that are split between three root code bases.

    I will point out that the best practices ( encourages you to back up your site and to not start updates with your live site (

    You might want to look at the drush project for command line automation tools. I haven’t had time and have other methods in place already myself.

  3. Gerard McGarry said on April 25th, 2008 at 9:09 pm :

    I’ve got to respectfully disagree, Sepeck. Why not look at Drupal from a non-technical point of view for a minute?

    The first person any sensible business person with a web presence will do is ask about backup and recovery. If I install a Drupal site for a client and they’re running a shopping cart off it – it’s pretty critical to have a backup for two reasons.

    One is that if there is a problem with the host, the site can be brought up elsewhere in a relatively short space of time with minimal loss and no need to spend hours rebuilding the database.

    The other is to guarantee (as I did) that you won’t damage your database during an upgrade and ruin your site. The ability to import the database locally and perform tests on it is crucial.

    I take your point about the complexity of site configurations Drupal is capable of. However, that shouldn’t stop a basic backup utility being included as part of the core with a recommendation for other backup methods for more intricate installs.

    I’m thinking of the non-technical Drupal user here, as well as something which I think would encourage the adoption rate of the Drupal platform.

  4. sepeck said on April 26th, 2008 at 12:00 am :

    I often look at Drupal from a non-technical perspective. However, Drupal is a very technical thing that hides the complexity of what it does well. If something goes horribly wrong then you will have to have some minimal technical ability or access to someone. Things going horribly wrong for non-technical people are why I wrote the best practices.

    On having backups and test sites, this is good, we both agree on it. :)

    There are a wealth of tools to backup databases that have communities around them that are superior to anything that could be included in core could be. Some of the issues that came up several years ago was that ‘through drupal backups’ (dba module in 4.5-4.6) had a lot of issues scaling. PHP memory limits on the server causing failures or white screen of death. So there went the save through your website to your desktop. Email… file to large, blocked. Save to your server file system…. space issues or the server crashed and no local copy. Security vulnerabilities and the fact that your site could be dead with such database access configured.

    These are some of the challenges I remember others going through in attempting a solution. Does it support MySQL and PostGRE and can it be extended to support MS-SQL should that support get in?

    I wouldn’t trust a built in solution myself anymore when using tools designed by the various database communities and vendors themselves do a much better job.

    If you implement Drupal sites, then you need to make sure you leave your users with proper instructions, documentation and tools to protect their sites because there is other database maintenance that should be going on at regular intervals as well. If you run a site, you should have some technical ability especially if your business relies on it. I am not saying that making things more accessible is bad, I am saying that Drupal already makes very technical things easy and always hiding that is not always good.

    All that said, propose a feature in the project tracker, get a developer behind it and some advocacy going (code is gold). It is possible to get features in if people work on it. The very module you are using could probably serve as a base entry point so you should definitely bring that up with the module maintainer. Maybe just get the base API in with a GUI interface being contrib for one more version.

    Non-techies aren’t often sensible about technology. :)

    Best of luck, glad you like Drupal.

    Steven Peck

  5. Nicholas Thompson said on November 27th, 2008 at 10:15 pm :

    I recently wrote a database backup script for some large sites and documented it on my blog. It ‘intelligently’ does structure-only dumps for certain tables which contain non-essential data such as cache(_*), session and watchdog… You can find it at How to backup a drupal database. This saved me nearly 200Mb off a database dump!

Leave a Reply