Exchange 2010 Restore Storage Group - Too many logs prevents RESTORE STORAGE GROUP (RSG) from being created

I have an Exchange 2010 server that I am trying to create a RESTORE STORAGE GROUP on, but it's failing because there are too many log files.   The error that I am getting is:


Failed to connect to target server "MYSERVER1". Error: WMI exception occurred on server '': Quota violation
    + CategoryInfo          : InvalidOperation: (:) [New-MailboxDatabase], InvalidOperationException
    + FullyQualifiedErrorId : 707BD31B,Microsoft.Exchange.Management.SystemConfigurationTasks.NewMailboxDatabase


I have looked into this error, and it is because there are too many logs in the restored EDB and log file bundle.  I need to use ESEUTIL I believe to sync the logs into the database, but I am unsure how to do this.  I've tried "ESEUTUL /r" and "ESEUTIL /cc" but /r fails and /cc does not have a restore.env file to work with.

The files were restored from Barracuda Backup appliance, and I selected to restore to a folder instead of to a restore storage group.  The database restored is about 500GB in size, and the logs were about 300GB more.  The restore takes so long that I really cannot restore again to a storage group directly....I just want to know what is the most efficient way to marry the log files into the EDB file?  They're all in the same folder.

Help is appreciated...thanks!
Who is Participating?
jkeegan123Connect With a Mentor Author Commented:
The answer to the question that I asked is :

Eseutil /r {log base prefix, ie E02} /d {path to restored db} /l {path to restored logs}

This performs soft recovery and patches logs into db, creating a clean Shutdown state.

The command :New-MailboxDatabase -Recovery -Name RecoveryDB -Server MailboxServerName -EdbFilePath D:\Recovery\RecoveryDB.edb -LogFolderPath D:\Recovery\logs

Performs this automatically, but the command fails with quota error because there are too many log files as I first mentioned in this post.

This command that I first entered fixed the issue by patching all logs in.
VB ITSSpecialist ConsultantCommented:
Firstly check if the database is in a Clean Shutdown state by running the command eseutil /mh "database name.ebd"
Barracuda should be Exchange-aware so hopefully your database will be in a Clean Shutdown state.

If it is, create a new logs directory in the folder containing the recovered database and log files.

For example if you have restored the database and log files to D:\Recovery\ then the new logs folder would be D:\Recovery\logs

Next step would be to run the below command in the Exchange Management Shell:
New-MailboxDatabase -Recovery -Name RecoveryDB -Server MailboxServerName -EdbFilePath D:\Recovery\RecoveryDB.edb -LogFolderPath D:\Recovery\logs

Open in new window

Now go mount the database and see if this works.
jkeegan123Author Commented:
The database is in dirty Shutdown, the logs will need to be patched in or eseutil /p will need to be run I think.
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

jkeegan123Author Commented:
Also when I run thst command, I get a quota error due to having too many log files.
VB ITSSpecialist ConsultantCommented:
Sorry, I didn't have access to a computer all day yesterday.

The command I gave in my previous post is only to be used if your database is in a Clean Shutdown state as this would indicate that your backup software is application-aware in terms of Exchange.

The fact that you had 300GB of log files though would indicate that either your backup software isn't Exchange aware (as a successful Exchange aware backup would actually flush your transaction logs), or your backups aren't configured properly for Exchange. I'm quite sure Barracuda Backup is Exchange aware so I would review your current backup configuration and make sure it's backing up as it's meant to.

Otherwise you will have to go through these same steps when you next perform a restore, i.e. replaying the log files to the database to do a restore, not to mention the lengthy restore times.

Glad you got your issue sorted though, my next suggestion would've have been to use the /r switch but we needed to know the state of the database firstly.
jkeegan123Author Commented:
@VB_ITS:  I was also surprised at the amount of log files.  It turns out that this was the result of the SMART BACKUP feature of Barracuda, which does a FULL BACKUP automatically, and a LOG ONLY backup (differential) for 14 days.  On the 15th day, it does another FULL backup, and repeats this cycle.  This of course is configurable, and when I use Barracuda Backup services (which I avoid when I can since it takes SO LONG TO RESTORE no matter WHAT the situation) I usually set this to a 5 day smart backup period.

This organization receives SO MUCH EMAIL that 300GB of log files in 14 days was actually VALID.  

I patched the log files in and was then able to mount the EDB file as a RESTORE STORAGE GROUP.  Yay!
VB ITSSpecialist ConsultantCommented:
Fair enough! Job well done then :)
jkeegan123Author Commented:
This was the answer to the question.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.