Using drush for Drupal site Backup/Restore and Migration
On this page
'Drush', or the "Drupal Shell," is one of the Drupal administrator’s best friends. Its many command line tools allow a user to log into a web server and perform routine tasks such as applying updates, block users, or even "bootstrap" a brand new Drupal installation.
As with any software, it is wise to keep regular back-ups. This is also true in the case of Drupal, where updates to the add-in modules will perform certain database operations that can’t be easily undone. If these cause issues with other modules or the core of Drupal, you’ll want to be able to "roll back" to a prior version.
Fortunately, the drush application provides a useful "archive" utility, as well as a corresponding "restore" command.
Backing up your Existing Installation
The drush command comes with many sub-commands, among them the drush ard or "archive dump" command. This command takes the following actions when run from within a Drupal installation (i.e. from anywhere within the directory tree):
-
Firstly, it will export a copy of the database(s) for your site(s)
-
Next, it will grab a copy of all the installation’s files
-
Last, it will create an archive of the database export and site files in the current working directory
This allows you to create a snapshot of your site with the following command shown in the below example.
Drush’s drush ard command.
drush ard
Database dump saved to [success] /tmp/drush_tmp_1477498943_5810d83f2ad81/mobius_dev_drupal.sql Archive saved to [ok] /home/path/to/archive-dump/20161026162145/mydrupalsite.20161026_16 2206.tar.gz
Notice how drush will add a date/time stamp to the archive…? nice, huh?
Note
You can also use the following to perform the same command as above
drush archive-backup
drush arb
By default, drush will use a filename that contains a date/time stamp, so you can keep as many snapshots of the site as you like. The back-up files are in standard gzipp’ed tar format, so you can use your favorite archive utility to inspect their contents. A few useful options you can provide along with the drush ard command are as follows:
-
"--destination": This option allows you specify another destination for the backup file, so you won’t be littering your Drupal installation with archives in random locations. Note you will need to provide a full path and file name, e.g. "drush ard --destination /home/user/backups/drupal/drupal_backup.tar.gz."
-
"--overwrite": Normally if you try to take a back-up with the same path and filename as an existing file, the command will fail. But this option allows you to overwrite the older file with a new version. This is useful if you want to always keep a current back-up handy for quick restoration.
-
"--no-core": This allows you to exclude the core Drupal installation and only back-up the data related to the site(s) you’ve built. Why would you want to do this? Well, you can always get the latest Drupal release from the project’s website or FTP, so there’s no need for you to waste storage space on it. It could also be that something happened to your core installation, and you’d like to restore a clean copy of Drupal itself and then your site over top of that.
Once you have a drush ard command that suits your needs, don’t forget to include it in your favorite admin shell script or as part of your cron jobs.
Restoring Your Site
So in the event your old server has exploded (sorry), you’ve found new hosting, including web space and access a database server. Now it’s time to restore your site from one of your back-ups. The drush arr command will do this for you if you take the following steps:
-
First, copy the back-up file you want to restore to the location to which you want to restore it (this will usually be the root directory of your web server).
-
Next, run the drush arr '/path/to/nameofyourbackup.tar.gz' command. This will unpack the entire directory tree of your Drupal installation (provided you didn’t use the "--no-core" option).
-
In addition, in the root of your Drupal installation will be an export of the database. You’ll need to import this into a new database to restore all your content, users, etc. Assuming you’re using a MySQL database and you have a database user already created, you can use one of the following to do the import:
-
Lastly, you’ll probably need to make some adjustments to your settings.php file, including:
-
Check the permissions on your site—?if you have a different username when you extracted your site’s files (and you probably do if it’s another hosting account), you won’t be able to modify any files or directories, and you may not even be able to view your site.
-
Adjusting the URL and/or port where your site(s) live.
-
Change the URL, username, and password where the database for your site lives.
-
Once that’s complete, you should be able to visit your home page URL and see your site just as you left it…? only, we hope, on a more resilient host.