Everyone needs to have a backup plan for their live site. Not only can your server's disk get corrupted, but you can also erroneously overwrite your site with bad code or bad data, or your site can get hacked. Detecting the latter situations takes some time. Hours or days.

For this reason, you should have multiple backup copies at multiple time points.

The most convenient scheme is to have a 7 day sliding backup: that is, you have one backup snapshot for each day of the week, with today's backup overwriting the backup from 8 days ago.

The scheme we describe in this post uses the extremely flexible, popular and useful Drush the command line swiss army knife for Drupal.

It has the following advantage:

  • No need to know what user, password and host MySQL is running on.
  • Single self contained all-in-one backup file for database, Drupal and static files.
  • 7 Day sliding backups.

Note: The use of Drush for backup, or any other scheme that uses mysqldump, are suitable for sites that do not have a large database. If your site's database is large, then you may want to explore other backup schemes, such as using MyDumper for Fast Parallel MySQL backups.

Install Drush

You can install Drush using Composer, as discribed on Drush's github. Or you can install it via PHP PEAR.

Installing from PEAR is as follows:
First, install the PHP PEAR package from Ubuntu's repositories.

aptitude install php-pear

Then install dependencies:

pear upgrade --force pear
pear install Console_GetoptPlus
pear install Console_Table

Finally install Drush itself.

pear channel-discover pear.drush.org
pear install drush/drush

Now that you have Drush installed, we proceed for using it for backup.

Create A Backup Directory

We now create a directory to hold the backups, and change its permissions so no one could read it but someone with root access.

sudo mkdir /home/backup
sudo chmod 700 /home/backup

Create a Drush alias file

Then create an aliases file for Drush to know where your site is installed. Change example.com below to your real directory where the site is installed and its real URL.

# This file should be in ~/.drush/aliases.drushrc.php
$aliases['live'] = array(
  'uri'  => 'http://example.com',
  'root' => '/home/example.com/www',

Creating the drush backup script

Now create a file in /usr/local/bin/daily-backup.sh


# Daily backup of the database, using Drush

# Backup directory

log_msg() {
  # Log to syslog
  logger -t `basename $0` "$*"

  # Echo to stdout
  LOG_TS=`date +'%H:%M:%S'`
  echo "$LOG_TS - $*"

DAY_OF_WEEK=`date '+%a'`

log_msg "Backing up files and database to $BACKUP_FILE ..."

drush @live archive-dump \
  --destination=$BACKUP_FILE \
  --preserve-symlinks \


if [ "$RC" = 0 ]; then
  log_msg "Backup completed successfully ..."
  log_msg "Backup exited with return code: $RC"

Make the script executable:

chmod 755 /usr/local/bin/daily-backup.sh

Scheduling the daily backup

Now add the script to cron so as to run daily, for example at 2:30 am

30 2 * * * /usr/local/bin/daily-backup.sh

After a few days, you should see backups in the directory, kept for 7 days:

ls /home/backup/


It is also a good idea to copy the backup files to another server, ideally not in the same datacenter as the live site. At least do this weekly using an addition to the script using scp or rsync.


Thu, 2014/05/29 - 11:08

Thanks for the clarification.

Yeah, I will leave the link you posted here so others can check it if they need something other than the past 7 days.


Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting