For future reference, in addition to your database, keep a plaintext backup that you refresh periodically. (Just write a script to open your dbm, walk the keys and dump it in a plaintext format.)

That way if you are dealing with a problem like this, you have the option of writing a script to take the plaintext backup and recreate the database. Actually you should do this before you run into trouble, and try the dump/undump utility out. (That way you can find that, for instance, your plaintext format assumes no returns in the data, but there are returns...)

And a note for the future. What happened to you illustrates why in a switchover people should ALWAYS do testing (which should have caught that your application had problems) and also keep the old server around (so that people can figure out how to rescue stuff that broke).

Also a random tip. If you are using this in a CGI environment, be warned that the widely used locking technique of calling flock on the dbm does not work. (This used to be the documented approach, and appeared, for instance, in the old Cookbook.) Use either the native locking facilities in BerkeleyDB or use DB_File::Lock instead. (If you are not using locking, of course, then you should. The consequences of not doing so include file corruption and loss of data.)