To get log file Location – Get-mailboxdatabase | fl Name,*path
It should generate a new series of log files and mounting the database gracefully. Removing all the logs files from the logs files location and Mount the database. It couldn’t mount as it’s not able to understand the existing sequence of the log files. Showing CLEAN SHUTDOWN – The database is healthy and it’s in a good shape. There are two results, It may say clean or dirty, will go through both. \eseutil.exe /mh "D:\log files\Mailbox Database\Mailbox Database.edb" Locate to the bin folder to check the health of the exchange database. To check the status of the Exchange database : \eseutil.exe, Default location – cd "C:\Program Files\Microsoft\Exchange Server\V15\Bin"
let’s see how to check the health of the databases. if it’s not gracefully dismounted or disconnected from storage or server or anti-virus removes sometimes hold the log files mistakenly. You got to check the health of the database, Where Exchange cannot connect back to a database again. Before that, There are various ways to get your databases healthy, 5-10 GB per hour is the worst-case scenario. so that even if your repair is interrupted you don’t lose hope, you can copy it again for recovery purposes. if you don’t have a backup always take a copy of the broken databases. If you don’t have a backup, repairing the existing databases takes time approximately 5-10 Gb per hour.
The stability of the databases has increased where the server or storage undergoes an intermittent failure new exchange versions cure themselves in few scenarios when it comes to database copies. Check you can access the storage and bring that back. Still, there are chances where your Database didn’t failover due to a network issue or various other reasons. Some Organizations start depending on DAG. No Backup – Exchange mailbox Databases are down
You may have to take a copy or rename the database file before restoring using the backup software as they can overwrite the database files residing on the existing drives. Then you can create a recovery database and repair the broken databases and merge them with your production. If you have a good backup First Restore from the Backup get the production running. but make sure you have to retain the live data whichever is on the existing drives – As you will lose data from the Backup taken time to the Storage Failure time. The best option is restoring from Backup software like Symantec / veeam / veritas / avamar which is the best option to have minimal downtime. Have tried to include as many scenarios as possible.