Database clean shutdown status Issues with ESEUTIL

Question

hi all i am currently trying to go the process of taking my database backup from a dirty shutdown into a clean shutdown state with ESEUTIL.
a user has lost some items from there sent items folder so i am restoring it for them.
i have checked the state of the database and it shows dirty shutdown so i am running the command below to replay the log files.
 C:\>eseutil /r E00 /l "C:\database recovery\Mailbox Database 1813862868\data" /d "C:\database recovery\Mailbox Database 1813862868\data" -verbose
it begins to process but them comes up with the following error suggesting i use the /a argument, i cant seem to find much information on this wondered if anyone had any suggestions. i ran the -verbose command to help try and narrow it down 
can some one help with what the /a argument does or if they have had this issue themselves a possible way to resolve it.
many thanks
Gordon

Answer 1

Thanks for the information and;
1. I would start with your VSS backup provider Cloudberry since as part of the backup validation it shouldn't have passed if those files were missing and upon restore of the EDB it should have also provided all needed Log files.  Now its possible they
were missing prior to backup and that could be for any number of reasons, i.e. Anti Virus if improperly configured could have deleted or quarantined them etc, however more concerning is that the backup provider called that backup good.  I would look at
the backup logs to see what they reported as its possible they did report an issue during backup.  The other possibility is that the files are within the backup but didn't restore for some reason and for that you would need to do another test restore
to validate.  Also could be that upon restore the logs were deleted by your Anti Virus provider and of course you can check the AV logs and quarantine...
2. Running a /P against a restored backup for item level recovery is not as big of a deal as it would be if you were putting the db back into production.  True you can still lose data with a /P but for what you were doing not an issue IMO especially if
you recovered the needed data.
3. The log loss also was in the middle of the needed log chain which is never a good sign. Sometimes you can get by that issue by removing all logs after the missing log file and just trying to play it up to that point in time.
P.S. If you are missing the log files post backup and want to avoid running a /P on an inconsistent/dirty database the only choices are to;
A: find the logs (Look at AV logs and quarantine or perhaps re restore the files again from backup)
B: do the /P
C: Check out our DigiScope product that can bypass most /P issues by using our Forensic mount to open the database and then extract the needed information to PST or restore it directly to any mailbox on the original or alternate exchange server (even alternate
versions i.e. 5.5-->2000-->2003-->2007-->2010-->2013 etc.)
Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline Exchange Mailbox and Public Folder EDB's and Live Exchange Servers or Import/Migrate direct from Offline EDB to Any Production Exchange Server, even cross version i.e. 2003 -->
2007 --> 2010 --> 2013 with Lucid8's
DigiScope