Peter Wagner is an IT consultant who lives in Garching, Germany. This is his first article for TechRepublic.
What happens if you lose your Microsoft Exchange 2000 server, you have only an offline backup of the database, and nobody knows anything about the environment because the two people formerly in charge have been let go?
One morning several months ago, my cell phone rang at 6:00 A.M. A systems administrator of a company we had work with said, “My Exchange server blew up a couple of hours ago, and folks are going to show up in less than an hour. Please come here fast!”
My client was a small software company with about 100 users. They were running a Windows 2000-based environment with one Exchange 2000 server responsible for all e-mail traffic. This server had suffered severe hardware damage that night when water hit its rack and destroyed the machine and most of its hard disks. To make things more difficult, there was no Exchange backup, only a file copy of the database file and a few log files taken while the server was online. Here’s what we did to get the client back in business.
Restoring Exchange becomes complicated and unpredictable when there is no decent backup. Exchange Server must be backed up using a tool with a Microsoft Exchange module that can save the database, the log files, and information on how to put everything back together while the server is online.
Seagate’s backup exec or the built-in Windows 2000 Server backup tool will do the job if configured correctly. However, in this case, we had neither. The administrator had included only the database and stream files (priv.edb, priv.stm, pub.edb, pub.stm) and the folder with log files in his file backup.
What we needed was a precise plan. You cannot expect a database to mount if restored out of a plain file backup, because every transaction in the Exchange database is written to log files first before being sent to the database file. Then, file access to the database is restricted while Exchange Services are running. This results in inconsistent or corrupt database files if a copy is made while Exchange is in use.
We were also unsure how long the repair of the database would take and how much data would remain intact by the time the database was returned to a consistent and mountable state. We decided it would take about two hours to set up a new server with Exchange 2000 and integrate it into Active Directory. Then the 20-GB file restore would take at least three hours. On top of that, we estimated three to four hours for the database repair plus some time for configuration of the new system.
We decided we needed a messaging system much more quickly, so we would have to set up a temporary system to handle mail traffic. Instead of just pulling up a server to be trashed after restoring the original system, our plan was to set up a new Exchange server with all the features the old system had but with a blank database. We would create new mailboxes for the users and therefore give Exchange functionality back within a few hours. We would pull up another system on a test box and not connect that to the LAN to use as our restore environment.
Using this setup allows you to restore the Exchange Server database with less time pressure, export the mailbox data you retrieve into .pst files, and import these files into the mailboxes in the new live environment without causing any more significant downtimes.
Prerequisites for recovering Exchange data
Setting up a new Exchange server with blank databases wasn’t a big deal. We disconnected all users from the mailboxes that had resided on the old machine using the Active Directory Users And Computers MMC and created mailboxes on the new server for everyone.
All users had an Exchange environment but none of their old data. We assisted the laptop users who had their offline storage configured in starting up their computers with no connection to the network, opening Outlook, and exporting the offline copies of their mailboxes to .pst files. This way, users could reimport the .pst files to the blank new mailboxes when connected. All of these users had their entire Exchange information recovered in less than 30 minutes.
Next, the fun of restoring the original database could begin. When rebuilding an Exchange server to mount a database from another server, you have to watch out for several things. The server must have:
- The exact Fully Qualified Domain Name of the old Exchange server.
- The same Exchange organization name—all Exchange servers in one environment usually belong to one Exchange organization. The name of the organization is configured during setup of the first Exchange server there. Every Exchange server belongs to one organization, even if it is the only server and there is only one organization.
- The same site name. An Exchange Site is a group of Exchange servers usually in one physical location. Again, every server must belong to a site.
- The same service packs and security patches for both Windows and Exchange installed.
Once you have installed such a server, you might try and mount whatever you have left of your original database. If you’re lucky and the database is in decent shape, your work ends here.
If not, you’ll have to use Exchange command-line tools like Eseutil and Isinteg to analyze and repair your database.
This was the case in our situation. We had configured a test server to exactly match the original system and restored the databases, stream files, and log files we had from our tape. In our next step, we replaced the blank databases that are created during setup with our restored files and tried to mount the database. As we had expected, neither the public nor the private store mounted successfully, because our database was inconsistent.
Restoring the database
When this happens, your first step should be to try a restore of the database with the Eseutil tool. This command-line tool is placed in C:\programs\exchsrvr\bin on standard Exchange 2000 installations. (You can find a description of this tool in Microsoft’s Knowledge Base.)
By running Eseutil with the parameter /g, you can start a repair of the database. After running this command, you should run Isinteg, which is in the same directory. (You can find detailed information on Isinteg on Microsoft’s Knowledge Base.)
If you have enough information—log files, chk file—you should be able to repair your database without running Eseutil /p. The parameter /p should be your very last option because it initiates a hard repair of the database, which will most likely result in a loss of data.
That day, we ended up trying all options explained in the Knowledge Base articles listed above, but did not succeed. The databases would not mount. So we had no choice but to try Eseutil /p.The hard repair was successful, but our loss of data was approximately 5 percent. At that point, we were satisfied that we had a database that would mount.
With a running database on a test system, you can easily use the Exmerge tool from the Exchange installation CD to export the restored mailboxes to .pst files. These files can be imported into the new mailboxes on the new live server. The process of moving our recovered data to the live server with this procedure took between three and 15 minutes per mailbox depending on size.
At the end of the day, it seems we chose the right strategy. Instead of rebuilding the live system with all options and data and leaving a business without a messaging tool for a day, we took off a lot of the pressure by offering a system that would supply the environment with the most important functionalities. Of course, no user is happy to be without Exchange data for a day, but most users appreciate your effort to give them what they need to survive. And that gives you enough time to do the real job—restoring business-critical information—correctly.