We recently had a scenario where an administrator had tried to restore a full and an incremental backup. He escalated the problem to us when he couldn't see the data from his incremental backup. It turned out that a hard recovery was ran after his full backup restored. Oddly enough, most vendors have the hard recovery process run by default after every recovery. On Backup Exec, for example, this process is identified as a check next to the box labled 'Commit Logs.'
A hard recovery is the process that brings a restored database back to a consistent state (administrator intervention is required). A typical hard recovery of a database is the restoration of a full backup or a full and differential backup of the information store. During the recovery process the administrator manually begins log file replay either through the ESEUTIL /cc command or the backup program interface (‘Last Backup Set’ in NTBackup). ESEUTIL /cc must be run from within the folder where Restore.env resides (eseutil /cc {restore.env path}). ESEUTIL /cc looks for instructions in the Restore.env file. Prior to beginning a hard recovery of a database, make sure that all database files and transaction logs have been backed up. If backups are not completing successfully, then it may be necessary to shut down the information store and copy the database and transaction log files to an alternate location. This way, if the database is damaged in any way, it can be restored to the same state it was before.
Once a hard recovery is performed, the database header is changed and all other log files will be useless. The hard recovery process changes the header information on the database and only the log files from this point forward can be re-played. For this reason, it is critical that the stores not be mounted until you are sure that there are no other restores that need to take place. If, after mounting the database, you find you need to restore other log files, you will have to restore the backups to an alternate location and EXMerge the data into the production database. Otherwise, you risk further downtime by re-running your restore process and loosing the data that was written to the database(s) once the stores were mounted. Once a satisfactory restore has been performed on a database, a full backup must be run.
