Source Control¶

If you have your site in source control (you do, don’t you?), that’s a great way to back up your site’s files as it combines all of our backup goals into one tool. However, it’s likely going to leave out some things that can change on the live server, such as image upload directories, or template files if people are changing those on the fly after site launch without going through source control.

But if your entire site is in source control and there are good practices in place to ensure no file edits make it to production without being committed, source control may be all you need to back up the file portion of your backups.

Rsync¶

Rsync is a great utility that is available for Unix-based systems. Its purpose is to sync two directories exactly, and the directories can even be remote!

A typical rsync command looks like this:

rsync -ahvz --delete user@production_server:~/public/ ~/backup/

This command is being run from the backup machine. It’s saying, “synchronize ~/public on my server to my local folder ~/backups/public/”. If you’d rather run this on the server, just swap the source and destination like so:

rsync -ahvz --delete ~/public/ user@backup_server:~/backup/

Before going any further, let’s understand the flags we’re passing to rsync:

• -a: Archive mode, equivalent to -rlptgoD, which does things we want in a backup: backs up directories recursively, preserves symlinks, preserves permissions and ownership data, and preserves modification times.
• -h: Preserves hard links.
• -v: Verbose mode so you can see what’s being copied. You can remove this once you’re comfortable knowing what’s being backed up, or once you start to automate the backups.
• -z: Compresses file data during transfer which can help speed up those over-the-network backups.
• –delete: Delete files on the destination end that have been deleted in the source. This may seem counter-intuitive given we want to protect ourselves from file deletion, but we want to preserve intentional deletions so that if we have to restore a directory, it does not contain extraneous files. As new versions of ExpressionEngine are released, old core files may be deleted, and in some instances it can be problematic if those old files are kept present in newer versions. But we can still protect ourselves against accidental deletions by rotating our backups, which we’ll see later.

This is also a great method for syncing with another public-facing server, such as a load-balanced or failover server.

rsync -ahvz --delete user@production_server:~/public/ ~/backups/$(date +%F)/

rsync -ahvz --delete user@production_server:~/public/ ~/backups/backup_latest/ &&
tar pcvzfC ~/backups/$(date +%F).tgz --same-owner ~/backups/backup_latest .

ls -1t ~/backups/ | sed -e '1,10d' | xargs rm -rf

Cloud Storage¶

If you’d rather not maintain a remote backup destination, an easy place to send your files is a cloud storage option like Amazon S3. There are tools like S3sync that behave like RSync, except S3 can be used as a source or destination. You can use the same snapshotting methods as above, but since you cannot run logrotate or do any other sort of shell commands on S3, you’ll need to perform the archival and rotation locally and then sync, or take advantage of S3’s object expiration to automatically delete old archives.

Dropbox¶

Dropbox is another nice option that combines all of our goals into one tool. Dropbox has a Linux client, so it’s possible to install the client on your web server and get the same instant syncing functionality you get on your personal computer. There are several ways to go about using Dropbox as a backup solution on your server:

• Symlink your document root: Given the Dropbox client is installed on your server, you could create a symlink from your Dropbox folder to the site’s document root, and any change made to a file is synced and revisioned shortly after. You can access previous revisions of a file via Dropbox’s web interface.
• Put archives to Dropbox folder: Tar and rotate the archives of your site as outlined above, then simply move them into your Dropbox folder for upload.
• Use Dropbox API to upload: If you’d rather not install the Dropbox service on your server, there are several scripts available, or you can write your own, which use the Dropbox API to perform simple uploads. Use this in conjunction with compressed archives.

You have an option of choosing not to sync site backups with your personal computer, but if you do and you’re backing up your computer with Time Machine or Backblaze, that’s another welcome layer of redundancy.

Creating the Dump¶

There are a couple common ways of creating MySQL dumps. One is to use mysqldump:

mysqldump -u username db_name > output.sql

The above takes a databased named db_name and outputs it to a file called output.sql. Knowing this and what we’ve covered earlier, you could modify the command to output a file with a name of today’s date. Combine that with tar to compress the file because text compresses very well.

Many hosts have phpMyAdmin installed which also lets you export databases in this format.

Automysqlbackup¶

Manually creating the dump and handling the files as outlined above can be quite involved. Luckily, there is a very handy and popular script for creating backups of your databases and automatically rotating them so you only keep the backups you need.

It’s called AutoMySQLBackup and will backup all databases on your server as you add them, can send you email notifications of successful or failed backups, will automatically compress the backups, and many more configurable options.

With AutoMySQLBackup, you just take a few minutes to set it up, and then simply incorporate the resulting files into your established file backup routine.