The command line syntax for soft recovery with Eseutil in Microsoft® Exchange 2000 Server and Microsoft® Exchange Server 2003 is different from that used in Exchange 5.5. The rules and best practices for performing manual soft recovery with Eseutil have also changed.

• In Exchange 5.5, there is almost never a good reason to perform soft recovery with Eseutil. Each time the Information Store starts, soft recovery is run automatically, and correctly. In Exchange 5.5, the Eseutil soft recovery function was intended mostly for test environments where you might wish to recover a database on a server that did not have Exchange installed.
  
• There is a major risk in running Eseutil /R in Exchange 5.5: After restoring an online backup, running soft recovery instead will usually corrupt the database. An online backup needs hard recovery, not soft recovery.
  
• Only if the following two conditions are both met is it safe to run soft recovery instead of hard recovery in Exchange 5.5 and previous versions:
  
  • The database paths have not changed since the backup was done.
    
  • The .pat files from the online backup set are exactly 8 K in size (meaning, that they are composed of only two header pages, and have no actual database pages in them).
    
  In all other circumstances, running soft recovery instead of hard recovery will corrupt the database in proportion to the size of the .pat files.
  

  Note:
  If you divide the byte size of a .pat file by 4096, and subtract two, that is the number of logically corrupt pages that will be in the database after improperly running soft recovery.

In Exchange 2000, safeguards were implemented that always prevent soft recovery from running when hard recovery is needed.

There is another risk in running soft recovery with Eseutil. This risk still exists in Exchange 2000 or Exchange 2003: If you improperly specify paths to log files, to the checkpoint file or to database files, recovery may alter the database or log files and prevent recovery from being done again.

If existing transaction log files are not found by Eseutil when it tries to run recovery, it will create a new transaction log file, and try to attach the database to it. If the database is Inconsistent or in Dirty Shutdown state, the database will not be made startable. If the database is in a Consistent state, it will be attached and then detached from the new log file.

In either case, you risk making changes to the database or adding log files to the server that will result in the database becoming unstartable or that will confuse further recovery troubleshooting.

Note:
Just because recovery with Eseutil reports success does not mean that the database recovered is in a mountable state. Recovery succeeds whenever all available transaction log data that is currently available has been applied to the database files. Recovery success says nothing about whether the available data was sufficient to restore the databases to consistency.

In Exchange 5.5, you were almost always better off placing files in appropriate locations and then starting the Information Store to accomplish recovery. In Exchange 2003, there are two improvements to the Eseutil recovery functionality that provide important advantages over mounting a database to run recovery on it:

• Eseutil can force recovery to complete even if there is a missing database. This capability is also available in Exchange 2000.
  
• If a storage group is unexpectedly stopped, all databases running at the time will be Inconsistent in a Dirty Shutdown state. Suppose that the reason the storage group stopped was that a database drive suddenly failed, and the drive is inaccessible. In this case, you are missing one of the databases.
  
• If you run recovery while the database is missing, it is possible that you will alter the state of the transaction logs so that if the drive becomes accessible again, recovery will not complete successfully with that one database.
  

  Note:
  If you restore the database from backup, recovery will be able to complete successfully—this scenario only applies to recovering a database that was attached to the current log at the time of the sudden stop.

• If you know that the lost database will not be recovered, you can recover the rest of the databases in the storage group without first restoring the missing database from backup by using the Eseutil /I (ignore) switch.
  

Before using this switch to run recovery on the rest of the storage group, you should first make a backup of all transaction log files, including the current log (Enn.log). By keeping a copy of the current log and all the other logs, you will still be able to recover the missing database if it unexpectedly becomes available. Once you recover the rest of the databases, and thus write more information into Enn.log, you may not be able to recover the missing database using that log file.

Eseutil recovery can recover a database that has been moved to a different path location. This capability is available only in Exchange 2003.

Hard recovery has always been able to finish successfully, even if Exchange databases have been moved to different path locations since a backup was done. But until Exchange 2003, soft recovery could only work if the database files were in the same drive path as that defined in the transaction log files to be replayed.

In Exchange 2003, the /D switch was added to Recovery mode to allow override of the database path hard coded in the transaction log files. This new capability is very useful when restoring offline copies of databases to Recovery Storage Groups, or when recovering a “missing” database as described in the scenario above.

You can now copy a database and a group of transaction logs into any folder you desire, and successfully run soft recovery. Once the database is consistent, you can then move it to any other path desired, and attach it to a different log stream.