Drupal 7: Offsite Backups with Backup and Migrate

At the time of this writing, just under 300,000 websites use the Drupal Backup and Migrate module.  It is an great tool for moving databases from production back to staging and development servers, and it is an essential tool for automatic backups of the database and files of the production server.

About a year ago, Version 3.0 was released, which integrated the offsite functionality from another module, and brought additional functionality, like files and code back ups.  This is what I would like to go through today in the steps below.

Why offsite backups?

I hope by now everyone has heard of the Backup 3-2-1 Rule.  If you haven't, it is a good thing to strive for in all things digital.  The rule mentions "In case your house burns down", but in our case, with web servers, there are a lot more risks.  The server could get hacked.  The developer or client could accidentally delete.  The hosting company could go out of business.  There are probably a lot more reasons that I sudder to think about!

Installing Backup and Migrate

  • Install the Backup and Migrate
    drush dl -y backup_migrate
  • Activate Backup and Migrate
    drush en -y backup_migrate
  • Set the modules permissions
    • Access Backup and Migrate
    • Perform a backup
    • Access backup files
    • Delete backup files
    • Restore the site
    • Administer Backup and Migrate
  • Configure Backup and Migrate at:
    /admin/config/system/backup_migrate
  • Configure Destinations, where the backup files are going to go at:
    /admin/config/system/backup_migrate/settings/destination/add
    • NodeSquirrel.com - By far the easiest and most professional solution.  It is premium service made by the people who developed the module to be safe, secure, and reliable.  Setup is easy, just enter the "Secret key" you get after signing up.  There are various pricing levels to fit budget and need.  This is what I use for most clients.
    • FTP Directory - Enter the credentials of an FTP server that to back up to.  Very straight forward.
    • Email - Email yourself the file.  I've never done this, but it says its possible =)
    • Amazon S3 Bucket - This requires a few additional steps.
      • An additional dependency is the s3-php5-curl project, which needs to be downloaded to:
        /sites/all/libraries
      • In your Amazon account, Set up a IAM User (Key and Secret)
      • Set up a Bucket, and add Authorized User permission to bucket
      • I like to add a folder in the bucket called "backups" so I can use the bucket for other things, like PSDs, Docmentation, etc, and I can also set the folder to "Reduced Redundancy" to save a few pennies.
      • Come back and enter that all into Drupal:
        Add a Destination
      • Click Save
  • Under the Schedules tab, click "Add Schedule".
    • Select Default Database under Backup Source to backup the database; enabled on Drupal Cron every hour; automatically deleted with the "Smart Delete" settings.  That settings keeps  hourlies for a day, dailies for a month, and weeklies forever.
      Drupal Database Backups
    • Select the Destination you want the Backup to go.
    • Click Save
  • Confirm it all works by doing a "Quick Backup" to your offsite destination from the main tab of the config.

I keep my code in git on Github, so I don't need to backup my code, but I do need to backup my files, so I repeat the process for Backup Source = Public Files Directory.  Files are a lot bigger than the DB, so I just do a "Simple Delete" on this one, back up daily, and keep 2.

Downsides and alternative methods

I have been told that since it is PHP based, and uses Drupal to run, this can cause strain on Drupal/the server, and uses more resources than alternative methods like:

  • Bash Scripts
  • mysqldump
  • drush sql-dump
  • PHPMyAdmin**

To Sum up

Backup and Migrate offers Site Builders and Administrators a very powerful tool to protect and restore their content easily through the Drupal UI.

*   You should set up a server based cron/crontab to trigger Drupal cron.
** Be wary of using PHPMyAdmin on production servers.  I have been advised that it is notoriously vulnerable to attack.