Making backups in Drupal

Anytime you are upgrading Drupal—single site or multi-site—you should make backup copies of everything Backing up Drupal is done in two stages. First, we must backup the files on the

filesystem, and next we must backup the database.

Filesystem backups

Generally, it is best to backup the directory that contains Drupal, rather than just subdirectories inside of that directory. With a multi-site configuration, backing up the main Drupal directory will give us one large backup file containing the following:

• The main Drupal code

• Each of our sites/ directories

• The files stored in the files/ directory under each site

Complex installations that use file sharing systems like NFS, Gluster, or network directories may handle the relationship between directories in complex ways. For example, the files directories may be mounted on different drives or even servers. In such situations the simple command here will not work for those. But unless you or your system administrator has done something like that, we can run a basic UNIX command to backup the entire directory.

In a graphical file browser it is often possible to generate a compressed archive of a directory with a few mouse clicks. The following process, though, uses the command line.

Either process will work.

Here I am using the Vagrant image discussed in the first few chapters. On a manually installed environment you may need to adjust the initial path.

$ cd /vagrant/public/drupal

$ tar –zcf drupal-backup.tgz www/

$ cp drupal-backup.tgz ~

In the first command, we simply change into the correct directory. We just want to backup the www/ directory in which we placed Drupal in Chapter 2, Installing Drupal for Multi-site.

Second, we run the tar command. This creates a single file called drupal-backup. tgz and then compresses all of the data from www/ into this file.

The name TAR is short for Tape Archive. Originally, this program was intended for copying data onto a tape backup system. By default, TAR archives are not compressed. You use the –z flag to tell tar to zip the file, too.

The process of creating this file might take a few moments, and the resulting file may be surprisingly large. The simple site we have constructed is 5.5 MB on my filesystem. Production sites routinely grow to hundreds of megabytes.

The third command illustrates an important point: Once you have created a backup file, move it somewhere safe. The command just moves it to the user\'s home directory (represented by ~). That is a decent place. But leaving the file near Drupal is dangerous, as that is the place where we will be upgrading things. Accidentally overwriting or deleting our backup file could be disastrous. Now we have our file system backup.

Database backups

Backing up the files can be done all at once. But backing up the database is a little more complex. We have three databases that need to be backed up, namely, books_local, cooks_ local, and looks_local. While it is tempting to back all three up into the same file, that is typically not the best idea, for it leaves us in a situation in which we must either restore all three databases at once or manually break up the backup file into pieces. The former could cause data loss, and since database dump files may be hundreds of thousands of lines long the latter is impractical. Since the databases are actually upgraded one at a time, it is more likely that only one will fail at a time. For that reason, it is better to simply make three backups, one

for each database.

The Drupal module called Backup and Migrate can ease and even automate the process of generating database backups.

We will be creating our backups on the command line, though most MySQL graphical front-ends can also do this. Graphical Front-ends For MySQL Popular Open Source MySQL front-ends include the web-based phpMyAdmin and the Mac OS X client Sequel Pro. Each of these has its own way of generating backups.

To generate a backup you will need to be able to connect to the MySQL database, and you will need to be able to authenticate as a user with permissions to run a full backup. Both your MySQL root user and your Drupal user should have sufficient permissions. Here we will use the root account:

$ mysqldump –h localhost –u root –p \\

books_local > books_local_backup.mysql

The command has been broken into two lines for readability, but typically it is run on one line.

The command connects to a host (-h HOSTNAME) as user root (-u root), asks for a password prompt (-p), and then specifies the name of the database to dump (books_local). Using a shell redirect (>), we tell the shell to write the output of the command to the books_local_backup.mysql file. As it stands, the resulting file will be an uncompressed plain text file full of SQL statements. Essentially, it is all of the SQL commands (in order) required to rebuild the database one statement at a time.

Should you ever need to restore the database, the typical way to do so is to issue a command like mysql –h localhost –u root –p < books_local_backup.mysql. This essentially does the reverse. It reads back in each line, executing it with the mysql program.

Repeat the dump for each database, storing the results in separate files:

$ mysqldump –h localhost –u root –p \\

cooks_local > cooks_local_backup.mysql

$ mysqldump –h localhost –u root –p \\

looks_local > looks_local_backup.mysql

Again, it is safest to place these files far away from the directory in which Drupal resides. We don\'t want to accidentally lose our backups.