Oh No! A Quick Guide to Drupal Backup Strategies
Many of us have been there – we walk into the office on Monday morning, go to the break room to grab a cup of coffee before we sit down to our workstation, intending to ease in to the day. Our email client is started up and immediately a flood of emails marked “urgent” work their way into our Inbox. Oh. No. It seems we weren’t “easing into” the day after all…
ARE WE DOWN?
WHAT’S WRONG WITH THE SITE?
I CAN’T GET TO THE WEB PAGE!!!
No worries, right? We’ll just go in and restore the database backup on our Drupal site from last night, right? I mean, we’re sure it was working each and every night…
About that time, we log into the web server and find that some obscure Apache / IIS / Tomcat zero-day exploit has been executed on our server, and the entire directory is corrupted and/or gone.
Drupal Backup Strategies
We have all heard that a site needs to be backed up “offsite,” but how many server admins have actually implemented such practice? In my experience, we either tarball the entire web directory and store it elsewhere on the web server, on another server in our network, or even a cloud server. There are a plethora of handy backup assistant bash / Perl / Python scripts out there, often involving an intense rsync command and potentially some logic that keeps a set number of backups and deletes the older ones.
Those of us who do a lot of development and hosting on cloud servers may take advantage of Amazon EC2′s snapshots, saving them into S3 buckets, but this strategy can add up in cost.
Rsync and crontab require a certain amount of server administration experience, something not all developers possess.
For those who haven’t heard, NodeSquirrel was recently acquired by Pantheon and started offering FREE cloud backups for Drupal users! One receives 5GB of storage for one site for the grand cost of zip, zero, nada, nichts. This handy backup is unreasonably easy to get up and running on your Drupal site, within minutes, right now. Not only does it back up your database, it will also back up your entire code base. What? Yes, you read that correctly! Theoretically, if one’s server crashes or is compromised, one could have the entire site up and running again after downloading the tarball from NodeSquirrel, extracting it, importing the database, and copying over the Drupal .htaccess file!
Get NodeSquirrel Running
First, download, install, and enable the latest version of Backup and Migrate, which actually includes support for NodeSquirrel by default.
Next, sign up for a free NodeSquirrel account, and note the Secret Key.
Log into your Drupal site and head over to admin/config/system/backup_migrate/nodesquirrel. Add your Secret Key to the NodeSquirrel Credentials section:
Next, you’ll want to go configure the Backup Schedule:
Here I’ve elected to backup the Entire Site, including the code, files, and database, to the NodeSquirrel cloud. Once per day, the whole site is backed up, and the old backups are deleted!
Finally, run a backup and make sure that everything is Ok – it should run via Drupal’s cron since it will be quite large. I gave it a day to run at around midnight before checking the page again in order to verify that my backups were working (NodeSquirrel is differential it seems, and will not back up your site if no changes have been made.)
That’s all there is to it! Happy backup-ing and you may now rest easy with the knowledge that your site is completely backed up into the cloud!