I am running The Financial Edge product on a very old server using MSDE. I am worried that it will fail at some very inopportune moment (When else? :-) so I have commandeered a newer desktop machine and installed MS win2K3 server and installed Financial Edge on it. I do not have it connected to the same lan as my live environment. I want to test my backups on this newer machine. The new server doesn't have the same number of hard drives or the same program file locations. I get the following error when I try to use the "Attach Database" option: "An error occurred trying to restore XXXX_XXXX. Device activation error. The phsyical file name "E:\bla bla bla\FE7Database.mdf may be incorrect.......... Use WITH MOVE to identify a valid location for file." It goes on from there but you get the idea. Any help would be greatly appreciated. Thanks, Chris Petersen

Download and install the Management Studio for SQL Server Express and you'll get a GUI to manage SQL Express (which used to be called MSDE). From the Management Studio, you can attach the database easily. The attach wizard will give you an opportunity to change the name of the db as well as the file paths for the MDF and LDF files.

Chris,

You need to make sure to adjust the file destinations when attempting to restore your backup.  When you are attaching your backup through the Blackbaud Management Console, there is a link above the path to the backup file that says "To adjust file destinations click here".  Click the link and adjust the locations to a location on your new server where you want to database to live.  See step 5 of BB100836 for more information. 

 -David Johnson

David and Ken,

Thanks for your replies!  Both solutions worked great, I appreciate the help.  Do you think I have gone far enough in my disaster planning?  Should I take the existing server offline and try having the users attach to the backup server or am I in good enough shape with having attached the databases (we run two companies from the same office) from the backups?  I am trying to be reasonable about disaster planning without being over the top.

Thanks again.  Chris Petersen

Hey Chris,

Glad it's working. I'm happy to share our Disaster Recovery (DR) plan, but I need to put up a little disclaimer: your data and its protection are entirely up to you, and any advice you receive from anyone about backups/recovery should be thoroughly tested and researched further. Just because it works for them doesn't mean it'll work for you. Server configurations may vary. Contents may have settled during shipping. Do not take with food. Do not puncture; do not use near open flame. These claims have not been evaluated by the FDA, yadda yadda yadda...

Still with me? Good.

Just my opinion here, but if you've got a good backup file that you can restore on another server, that's as far as you need to go. Reconfiguring clients would be extra hassle for them and a headache for you. If you really want to be thorough,  you could restore the database on a different server -- call it Server B -- and then take a fresh machine out of storage (or the dumpster!) and try installing FE from the deploy folder on Server B. That might be something to do once or twice a year, though, and not as part of any regular DR procedures. In any event, I'd be careful not to mess with any user's machine that's in your production environment. 

At my org, we don't use the BMC at all for backups or recovery. We run lots of different databases on different servers for different things, and everything's standardized on a SQL Server 2005 platform. Our Blackbaud databases are only a small piece of a larger database infrastructure. For that reason, we made the decision to back up our Blackbaud apps -- RE & FE for now; NetCommunity currently in implementation -- through SQL Server's backup mechanisms, which fit easily into our existing backup and DR plans. We have a nightly maintenance plan that runs and takes a full backup of our database(s), and during business hours, we're backing up transaction logs every 2 hours. These backups are stored on a separate hard drive (actually a separate volume on a SAN, but same idea). Backups are kept on the disk for a period of 14 days. This backup location is backed up nightly to tape, so if we need to restore a database, and it's been less than 14 days, we can pull it off the disk. If we need to restore a database older than 14 days (like for an audit or something), then we pull it off the tape. There's a whole complicated tape rotation that involves onsite and offsite locations, but basically, we've got nightly backups going back at least one month, weekly backups going back a year, and twice a year (Dec 31 and June 30) we permanently archive tapes as well.

In regards to FE specifically, we do test our backups occasionally. Once a month or so, I'll pull the .bak file for a FE database and try to attach it in SQL Studio with a different name (a "Restore As..."). Once attached, I'll execute a few simple queries against the database and compare row counts of a few tables at random. That's it. At that point, I know the data is good, so the rest of the DR plan is built around getting to a point where we can restore the good data.

If a user accidentally executes a global delete with the wrong parameters, or does some kind of import/update that trashes a bunch of data, I would typically address that by rolling back the transaction log rather than attempting a full database restore. The only time I can think I'd need to restore from a backup is in the event of a catastrophic server failure (hardware failure, database corruption, failed OS upgrade, etc). For that, our DR plan involves first recovering the server, installing a fresh copy of FE, then dropping to SQL Studio and restoring the data from the last backup (whether from disk or tape) into the default FE database. If the rebuilt server name stays the same, and we reinstall the same version and patch numbers, then we won't have to re-map the clients.

Our DR plan is always geared around minimal downtime and minimal impact to our users, even if that means a little extra work for us. Backing up Windows or the FE program files for purposes of restoring them after a failure is, in my opinion anyway, a waste of time. Restoring backups like that is nasty business. I'd rather reinstall Windows & SQL, reinstall FE, then restore my database. Might take a little longer, but it's almost guaranteed to work right the first time, and provides a little more control for me and the other IT guys.

Ken,

Thanks for input.  I will try to take your advice with a grain of salt, under advisement, for what it's worth, with extreme caution, at least one half hour before swimming, and will never ever even think of taking it under the influence of OTC medication or other psychotropic drugs!!!  :-)

I am in general agreement with your ideas.  I do use BMC and I avoid tape backups like the plague.  I have seen too many companies run into trouble with those.  I prefer backup to disk via Backup Exec as well as an offsite backup system such as Mozy.  That way I get 14 days of rotation to disk and an additional 14 via Mozy offsite.  I feel much better knowing that I'm not relying on someone to happen to remember to swap a tape in or out, or bring a tape home once a week in case the place burns down.  Also restoring data this way is a snap.

Thanks again for your help.  I really appreciate it.

Chris Petersen