When databases get a bit wobbly, especially in systems like Exchange, there's a tool that often comes to the rescue: Eseutil. Specifically, we're talking about its soft recovery capability, often invoked with the /R switch. Think of it as a meticulous process of replaying transaction logs to bring a database back to a consistent state. It's not quite a full restore, but rather a way to tidy up the database using the records of what should have happened.
At its heart, running Eseutil /R is about playing those transaction log files back into the database. The most straightforward way to do this involves a simple command: ESEUTIL /R Enn. Here, Enn is crucial – it's the prefix that identifies your transaction log files. For this to work smoothly, you generally want to be in the same folder where these log files reside, and the databases themselves should be in their original locations. It’s like telling the tool, 'Here are the logs, and here's where the database is supposed to be.'
But life, and IT systems, are rarely that simple, are they? Sometimes, your log files might be off in their own dedicated directory, separate from the database files. In such cases, you'll need to give Eseutil a helping hand by specifying the path to those logs using the /L switch. So, instead of just ESEUTIL /R E00, you might find yourself typing something like ESEUTIL /R E00 /Ld:\exchsrvr\logfiles. This tells Eseutil, 'Hey, the logs you need are over here.'
Another detail to consider is the checkpoint file. This file helps Eseutil keep track of where it is in the log replay process. Often, when you're manually running soft recovery, you want to ensure all available logs are replayed, not just a portion. This might mean deleting or hiding the existing checkpoint file before you start. If you're running recovery from a different location, or if you want to control where a new checkpoint file is created, you can use the /S switch. For instance, ESEUTIL /R E00 /Sd:\ could direct the checkpoint file to a specific directory.
What if a storage group has an unexpected hiccup, and one of the databases goes missing or becomes unavailable? Mounting the remaining databases in that group can become impossible. This is where the /I switch comes into play. It allows you to run manual recovery even with a missing database. A word of caution here, though: before you proceed, it's wise to back up all your transaction logs, especially the current one. Once recovery starts, that current log might change, potentially making it unusable for recovering the missing database later if it reappears.
There's also a scenario for recovering a database 'out of place.' This is particularly useful for isolating the recovery process or when working with a Recovery Storage Group. The idea is to gather your database files (.edb and .stm) and all the relevant transaction logs into a single, temporary folder. From there, you can run a command like ESEUTIL /R Enn /I /D. The /D switch is quite interesting here. Without it, Eseutil relies on the database paths stored within the logs. If you use /D without a path, it assumes the current directory holds the database files. If you provide a path immediately after /D (no space), it uses that path. This method offers a clean separation, ensuring the live system isn't directly impacted during the recovery steps.
Ultimately, Eseutil /R is a powerful tool for database maintenance and recovery. Understanding these different switches and scenarios can make a significant difference when you need to get your data back on track.
