How NOT to backup your Drupal site

Blog-Shmog.com - Drupal Explodes!
Blog-Shmog.com explodes!!
An error in Blog-Shmog.com's auto-backup script sends its database down in flames...

One of the "gotcha's" that comes with any database-driven website such as Drupal (or wordpress or moveabletype) is that you essentially have TWO content sources to backup: your database and your webroot. Lose either and be prepared to spend lots of late nights doing emergency repairs!

Blog-Shmog.com explodes!!

A few weeks after upgrading to Drupal 6, my blog exploded (pow!) because of a small but disastrous mistake. Back when I first started the upgrade process, I duplicated my database and set up a development environment (as stated in the upgrade instructions). Once the update was complete, I copied everything back to my production server but I forgot to update my auto-backup script to reflect the new Drupal 6 database name. This meant that every week, my backup script was still backing up the old, unchanged (and outdated AND INCOMPATIBLE) drupal 5 database! I discovered this fatal error one day when I decided to roll back my database to fix a small development glitch. I unpacked my latest tar file, cleared my database and restored from backup... Oops. My blog exploded!

I instantly lost over 5 weeks of content, comments and edits- everything since the Drupal 6.x upgrade. All thanks to a missing "_6" in my backup script. grrrr!!

Yelling, Screaming & Restoring

After pouring myself one, two, a buuunchokaywhatsyourproblemimgrumpyletmedrinkjeez stiff drinks, I went to work rebuilding: I threw my old Drupal 5 webroot back online, loaded up my old database and went about upgrading to Drupal 6... again.

Restoring the Drupal core and contributed modules actually went a lot faster than I expected. I guess I learned a few tricks during my first 6 upgrade that served me well the second time around, but I knew that getting the framework back was only the easy part. --- And then it hit me -- Google probably cached my website! ...Sure enough, by searching for specific keywords relating to my missing pages, I brought up Google's cache of Blog-Shmog.com (only 4 days-old, by the way) and copy/pasted everything back into Drupal. The process was simple, but reeeaaaaally slow. Each comment had to be re-entered manually. one by one. in the proper order.

I manually re-entered a few dozen comments, 3 new pages, a user profile and a custom contact form, all thanks to Google's cache! Try THAT pre-Google (sorry waybackmachine, no cookie for you.)

Lessons Learned

No0Oo0Ooo!!!
No0Oo0Ooo!!!

Learn from my misfortune.

Back the truck up!
Obviously, this applies to more than just your website. But you already knew that...

Make sure to backup your webroot AND your database.
There are backup modules floating around the Drupal community, but most of them either only backup your database, or have been abandoned since drupal 5. Choose your backup method carefully!

Once your site is backed up, CHECK THE BACKUPS!!
If I had just spent the time to go through my sqldumps more carefully, I would have noticed my Drupal 6 tables were missing. dumb-dumb.

Enjoy your backups, but don't trust them.
If for whatever reason you need to roll-back your database, do a manual backup first, just to be safe. Paranoid: probably. Worth it: definitely.

If you do lose data, GOOGLE-IT FAST.
Don't wait! If you wait too long to check Google cache, it might re-cache your broken website! If you need more time to do the repairs, copy/paste all the Google cache you can get your hands on and safeguard it for later.

Restore cached content IN ORDER
After restoring your content, you can manually adjust each comment's (or node's) datestamp, so you can match it to the original post date. However, you can't re-order your posts once they're created. I found this out the hard way, and had to create a custom Views block to show my recent comments block in the right order.

Manual Backup

If you have shell access to your webserver, you can easily create an instant backup of your website from the command line. sign into your webserver and cd to your webroot, then type:

tar czf webroot-backup.tar ./

This will create a compressed tar file named webroot-backup.tar in your webroot that you can then download via FTP or keep elsewhere on your webserver for safekeeping.

You can create a mysql dump of your database by typing:

mysqldump --user=[USERNAME] --host=[SQL-HOST] --password=[PASSWORD] --add-drop-table [DATABASE-NAME] > database.sql

This will create a database dump named database.sql. (If you don't change directories between the two backup commands, this file will also be located in your webroot) It's a very bad idea to leave the backups in your webroot, so make sure to either download & delete them, or move them elsewhere, outside your webroot, mmmkay?!

Shmackup v1.0

Download Shmackup.sh - Blog-Shmog.com
Shmackup.sh v1.0

click to download...

After adding a stupid underscore and a stupid 6 to my auto-backup script, everything was up and running again, and my site was being backed up as it should. In case anyone is looking for a command-line backup script for Drupal, I present to you: Shmackup.sh 1.0. Shmackup will export your webroot and DB and pack them into a tar.gz file with a date-stamped filename. Nothing fancy!

Configure and upload Shmackup.sh to your server (outside your webroot, dumdumb!), chmod +x it, and schedule a cron job to run it at a your desired backup interval. I usually set it to perform weekly backups for normal use, and daily backups when I'm doing development or playing with settings. Just play with the cron settings to suit your needs.

No matter which backup solution you decide to use, always double triple check your backups before ever blindly accepting that your content is safe. And if you don't (yet) have any backup methods in place for your website, at the very least, sign into phpmyadmin and export yourself a fresh database dump.

The single most important thing to remember is: if you DO lose your data, don't panic. Head over to Google and immediately re-download your data from Google cache. It won't do much to restore deleted files from your webroot, but it can help you rebuild your database!

Good luck!

8 Comments

Minor error in tar command above

Note the tar command above wont create a compressed backup file, just a backup file. For compression use:

tar czf webroot.tar.gz ./
and to extract if you have to restore
tar xzf webroot.tar.gz

Forbidden trying to download?

Forbidden trying to download schmackup.sh. Can you send it to me or grant access please?

Hosted by Network Solutions without shell access. Will cron be able to make your script work, if I can get cron working?

Thanks, Mark

Test your backups

An additional tip from me:

ALWAYS TEST YOUR FILE BACKUP BY PERFORMING A TEST RESTORE

It could happen at some webhosting providers that hidden files (e.g. .htaccess) are not shown. You may think your file backup is complete but it may not be the case.

Add new comment