Recently it came to my attention that I accidentally committed some sensitive information to my SVN repository. I had already deleted it months ago, but as those of you who use SVN well know, nothing is ever really gone from SVN; any deleted items can always be recovered from the previous revisions in which they were not deleted. What to do?

Well, not surprisingly, I’m not the first person to have this problem. The SVN book describes the solution, and it’s not pretty. I’ll summarize:

• run svnadmin dump on your whole repository
• run svndumpfilter on the dump file to filter out specific path prefixes
• delete and recreate your repository, or create a new one to contain the modified dump
• run svnadmin load on the dump file output by svndumpfilter

If you’re lucky you have a very small repository like I do, and this only takes a half hour or so.

Now that I’m decommissioning my colo box at CI Host, I finally have to move my SVN server over to my Dreamhost account. I tried back in February when I moved everything else over to Dreamhost but I couldn’t get it to work. I tried again this time around and had better luck.

I’ve been diligently backing up bonzo using qdb.pl, my homegrown backup script. bonzo is a very important machine, as he stores my entire digital image archive, my Subversion repository, MySql databases containing Drupal and Gallery2 data, and 24-hour evaluation copies of large software packages. However, I realized somewhat belatedly that my MySql databases were not being backed up as part of my backup regime.

I’ve decided on a two-layer backup approach to backing up MySql:

• First, I’ll backup the MySql ISAM files in /var/db/mysql. Since I only use MyISAM and not the more advanced MySql storage options, this will be sufficient most of the time. However, in the off chance that a backup runs in the middle of a MySql transaction, the ISAM files may be in an inconsistent state. Which leads me to the second layer…

OpenBSD 3.8 was just released. I want to upgrade Ender from 3.7 to 3.8, but first I want to back it up. I have a simple backup script, @qdb.pl@, which I use for machine backups. However, I'm lazy and haven't gotten around to putting it on ender. Right before a life-changing OBSD upgrade is a good time to do so. It is at this point that the yak stampede begins. To install OBSD3.8, I have to back up. To back up, I have to get my @qdb.pl@ script. To get @qdb.pl@, I need Subversion (actually I could use HTTP, but I'm trying to be thorough). So, I dutifully go to @/usr/ports/devel/subversion@ and fire off a @make@; no dice, as the subversion port's depenency chain ultimately extends to the X11 libraries.