codinghorror.com loses it's blog to a hosting failure

Everyone’s tweeting about codinghorror’s data loss today. I’m not sure exactly why their hosting provider lost their blog, but I’m prepared if mine ever does. In my case, it’s easy – I email myself a dump of the WordPress mysql database nightly.

$ crontab -l
0 7 * * *  /usr/bin/mysqldump -u root -psecret --all-databases |bzip2 > /tmp/dbbackup.sql.bz && (printf "\%b" "Subject: db backup for `date`\nTo: jonathan\n"; /usr/bin/uuencode /tmp/dbbackup.sql.bz all-databases.sql.bz) |/usr/sbin/ssmtp jonathan@example.com

That command runs once a night, dumping the structure and contents of my mysql database, compresses it, and formats the file as an email attachment and sends it to me using ssmtp. You can substitute sendmail, or your favorite MTA (Mail Transfer Agent).

Every morning, I hit “y” on that message in gmail, and that’s a fine tradeoff for sleeping soundly.

UPDATE: the same technique can be used to backup your entire www directory, saving images and site tweaks. This cron task runs once a week, emailing my my entire WordPress install for all sites hosted on this slice.

15 7 */7 * *  cd /var/www && tar zcf /tmp/www.tar.gz * && (printf "\%b" "Subject: www backup for `date`\nTo: jonathan\n"; /usr/bin/uuencode /tmp/www.tar.gz www.tar.gz) |/usr/sbin/ssmtp jonathan@example.com

As you can imagine, the files can be uploaded to another host via scp or sent to Amazon S3 instead of emailed.

<code>svn revert file.rb</code>

In git, you don’t add that file to your staging area for commit. To make your changes go away forever, you checkout a new copy of that file from HEAD.

<code>git checkout — file.rb</code>

If you omit the –, it will still work, as long as you don’t have a branch named the same as your file. Thanks to Jonathan Dance at norbauer.com – one of the few blog entries I found describing this technique.

2009-04-28 UPDATE – err has a great git cheatsheet that includes this trick under Fixing Mistakes.

So there I was, with my ruby model code happily sending out SNMP traps….or was it? For development (and test and qa) I set up the yaml file to send SNMP traps to localhost (port 162 is the default). I just needed a way to recieve them.

Enter snmptrapd.

Yes! A command line tool to catch the traps and log them the stdout! This turned out to be pretty easy on my MacBookPro – net-snmp is already installed.

The hardest part is setting up the authorization model. Do this: Create a file called snmptrapd.conf in the current directory. Add the line “disableAuthorization yes” to it. Heheh. No need for security – we just want to see them.

Now run the snmptrapd in the foreground, logging everything to stdout:

sudo snmptrapd -f -Lo -c snmptrapd.conf

Done. Now your messages will show up in that console window. This was not as nearly as painful as I expected!

So in the yml file, I will configure the snmp_trap_destination to be localhost for all environments except production. If there is no daemon running, they will quietly be ignored (UDP rocks). If there is one running (debugging qa, development) then they can be logged. Life is good, even when working with a 20 year old protocol.

(and thanks to atlantageek for one of the only blog posts out there about snmp and ruby!)