Sometime last July, the Movable Type setup that powered every weblog on our various domains went belly up. All logins failed, password retrievals failed… the database appeared to be empty. But the database was still there, and still flush with all that data. Logging into the web server and running “strings” on the database files showed that all the user accounts and blog entries were still there. So my problem was not that the database was gone – it was that Movable Type somehow couldn’t access the data. I backed up the errant database and went poking around.

I tried re-installing Movable Type from scratch, using the original install files I had stashed away. Still no dice: “invalid login.” I did a new install of a blank Movable Type setup – worked like a charm. That told me I definitely had a database problem, not a problem with the install files. The Oracle of Google told me that others had suffered the same problem:

• http://www.sixapart.com/movabletype/forums/lofiversion/index.php/t25580.html
• http://www.djchuang.com/b2/blog.php/2004/05/18/
• http://www.sixapart.com/movabletype/forums/index.php?showtopic=41725

One of the posts I ran across recommended the MT-Medic plugin. Sounded great – I installed it, then configured and ran it. Same result: no authors, no weblogs. But I knew, having seen the data, that it was all still there. The same post that mentioned MT-Medic also contained the following nuggets of information:

This can be fixed by converting the DB files over to the format used by the new library version; please review the Knowledge Base article on Converting Berkeley DB Files To New Version for more information.

It linked to an entry on upgrading the database version. “The easiest way to convert the DB files is to use the db_upgrade program.” Great! I could just run the “db_upgrade” command. Except… no such program existed on my server! So I then tried the burdensome “dump and reload” method at the end of the article. After laboriously typing in

$ db_dump -f author.db.data author.db
$ mv author.db author.db.old
$ db_load -f author.db.data author.db
$ chmod 666 author.db

…for more than two dozen files, I thought I was ready to go. I fired up the login window… INVALID LOGIN.

Now I was mad. But one guy, Dylan Parker seemed to be having the same types of troubles I was having, and he was equally determined. I re-read his article for clues. Ultimately, I never had to try his solution of upgrading Perl modules, because this paragraph gave me all I needed:

First off, my web hosting site didn’t appear to have db_upgrade, db_dump, db_dump185 or db_load installed. I hunted all over the directory tree and eventually found them in /usr/local/bin but they had the prefix db3_ instead of db_. Be aware your hosting company may have renamed these utilities. Remember… the locate and whereis commands are your friend.

Db3? Locate! Five seconds later, I had found the “db3_upgrade” program that had eluded me while I was searching for its little brother without the 3. Ran it, went to MT-Medic, waited with bated breath for it to load, and magic! The database spilled its guts across my screen: authors, blogs, everything. Moving to the login window, the entire Movable Type installation was back at my fingertips, fully operational.

My next item of business? Export! You’ll soon be seeing some of the old blog entries nestled in new blog homes. Hopefully no other Movable Type users have to go through what I went through, but if they do, I hope this note helps.

Remember, back up your data often.

UPDATE: I’m not the only one.