Easy Drupal Backups with Backup and Migrate Module

Submitted by kristen on Sat, 01/24/2009 - 07:58

I'm approaching 20 blog articles and I haven't yet made a backup of my Drupal site. YIKES! It would suck if my hosting server crashed and I lost everything. So... I guess I should do it now.

The only backup module I've used is Backup and Migrate. I like it and it's easy to use, so let's set it up:

  1. Download backup and migrate module
  2. Unzip and put in sites/all/modules (or wherever your modules are)
  3. Turn on module at /admin/build/modules
  4. Go to /admin/content/backup_migrate (NOTE: users with admin menu installed will see a blank screen when navigating to Content Management > Backup and Migrate > [some sub menu item] though you can choose the top level menu item and see the page)
  5. Backup/Export DB - choose the tables to include/exclude and save away. You can save to your sites' files directory (e.g. /sites/default/files/backup_migrate/manual) or to your computer.
  6. Restore/Import DB - if you want to move data to another Drupal site or revert back to an earlier version you have saved, you can use this feature.
  7. Saved Backups - shows a list of backup files for download or to revert the site.
  8. Backup Schedule - if you want to automate backups, you can set that up here. Even if you automate backups, you should transfer copies off the web server somehow in case the server crashes.

Start making regular Drupal backups of your site right away! It's easy ;)

UPDATE (1/24/09) - I wrote this up before trying it on kristen.org and unfortunately it doesn't work on this site. I blame GoDaddy... ugh. I'm getting this error when I try to save my backup:


Warning: Lost connection to MySQL server during query query: INSERT INTO watchdog...

Warning: MySQL server has gone away query: INSERT INTO watchdog...


I guess I will have to go through GoDaddy's database tools to make a copy of it. Annoying!

Tags: 

Comments

Variations on a theme. . . .

Sat, 04/10/2010 - 17:33 — jpw1116 (not verified)

Here's one for the experts.

What if you had a multisite with two sites total (each as their own dir off of /sites, and neither one /default) . . . and each of the two sites had its own database.

Could you still use Backup and Restore?

Bonus: What if you wanted to update core in the process--for instance, a D7 dev version that doesn't yet support the update function. Could you still use B&R to handle just the websites' data and expect a clean and functioning multisite reinstallation if you dropped all of the tables first, installed the new core and modules, and finally invoked Restore for the site data?

Maybe I'm wrong, but there doesn't seem to be any documentation on these situations. Thanks for any ideas!

Multisites

Sat, 04/10/2010 - 17:44 — kristen

I haven't used Backup & Migrate in a multisite environment but it *should* work just fine. It knows what database it is operating on based on what site it is "in" so I don't imagine there is a problem.

One way to test it would be:

1) run backup & migrate on both of the sites and save the files - you may want to include *all* tables so it's easier to compare

2) run a regular mysqldump on both sites and save the results - either include all tables if all tables were included in #1 or exclude the same tables (e.g. watchdog)

3) diff the corresponding files (e.g. diff site #1 files - one backup & migrate file and one mysqldump file... and same for site #2 files)

The results should be identical or, if there are differences, they should be things that don't matter. If they are different in some important way, then there is a bug.

As for the D7 upgrade, I'm not sure I know what upgrade you are doing... upgrading from D7-dev to D7-alphaX or ?? In general, it shouldn't matter if you upgrade the Drupal core. You should still be able to do the backup & restore.

One scenario where it might get weird is if you install modules that create database tables, then create a database backup, then uninstall those modules (which uninstalls the tables), and then do a backup & restore... the old tables would come back and the system table would set the uninstalled modules back to installed.

Good luck,
Kristen

That helps. . . .

Mon, 04/12/2010 - 15:34 — jpw1116 (not verified)

Thank you for the quick reply. I plan to look into Backup & Restore and post any results that are worth it.

As for the D7 scenario, no matter whether you are using the dev versions or the Alphas, supposedly there is no way to update to the newest release--that feature may become available in Beta and is supposed to be definite in the full release of 7.

Meantime, I'm in the situation where I want to keep developing my D7 multisite with the latest dev releases and modules but am concerned that situations like the ones you raise--for instance, modules leaving certain info in the databases--will make for a tricky, less-than-automatic experience. In other words, I'd rather be spending time developing, not troubleshooting the "leftovers" following a core version update.

Some say that starting in D6 and waiting for the full D7 is the way to go but I'm of the school of thought that starting with 7 and sticking with it is a richer strategy. We'll see!

about "Mysql has gone away..."

Wed, 02/24/2010 - 09:04 — pia-web (not verified)

try to desactivate "Update status module" that seems to make the mysql queries too long for servers that have à MAX_EXECUTION_TIME too small.

You can also try the db_tweaks module to increase the timeout (doesn't work anymore with drupal 6.15 and my hosting).

Cheers

à french internet drupaler

Thanks for the tips!

Thu, 02/25/2010 - 19:08 — kristen

I'll try them out ;)

Kristen

um sorry but everyone knows

Mon, 02/22/2010 - 05:18 — Anonymous (not verified)

um sorry but everyone knows how to click the backup and save the sql file, the problem NO one knows how to do is how to take that file and then install your drupal site on an ENTIRELY DIFFERENT HOST.

WHAT DO YOU DO?????

Migrating data

Mon, 02/22/2010 - 05:33 — kristen

You actually have to have the site on the other server set up already with Drupal and with Backup & Migrate installed in order to use Backup & Migrate to install the original site tables over. You go to the new site and choose to install the file you have saved from your original site. The downside of this is that you actually need to have installed Drupal first.

The alternative would be to use whatever mysql tool you have available from your new hosting provider and do the following:

1) create database with name that you want (could be different name than original site if you want)

2) use mysql tool provided to import the tables in the sql file from the original site backup

3) copy all code over to new doc root

4) change settings.php at new site to point to new database

Then you are done. The latter method makes more sense when setting up a new site based on an old one.

Good luck,
Kristen

You can select specific

Wed, 02/18/2009 - 15:05 — Anonymous

You can select specific databases to leave out and I believe "Watchdog" is one of them. There are a few databases that are huge and GoDaddy never cooperates so it may be timing out. Hope that works, cheers!

I'm a Speaker at DrupalCon Portland

This is a featured content block that has been configured to show blog nodes with terms SEO or Drupal SEO by the author kristen. It shows random list of 20 results in the block and 30 results on the more page.

Read more
Subscribe feed rss