Veeam Explorer for Exchange Showing Deleted / Moved Items

[MILJW002]

Hi All,

I’ve got an odd one, and I’ve Googled a bit and not found a solution.

When I look at a mailbox in Veeam Explorer for Exchange, either the most recent or a point in time I keep seeing items in the restore view that shouldn’t be there.

As an example, if I look at the Inbox for the affected user for the ‘latest’ back up it doesn’t refelct the current live view. It’s showing items that were deleted a year ago.

I wasn’t sure if it was an issue with the EDB, so I’ve run ESEUTIL checks on the EDBs in the repository and they all come up clean.

Has anyone else seen this behaviour?

Thanks in advance for any help or hints.

James

[Mike Resseler]

Hi James,

What is your retention range for the repository?

I'm not sure what would be wrong to be honest (or I understand it wrong).

Can you open a support call to let our support engineers have a look at it?
Thanks
Mike

[MILJW002]

Hi Mike,

The rention period for the affected backups is forever, and has data in it dating back to 2000.

Just to expand on the behaviour / symptom a bit. If I browse the Exchange mailbox backup using Exchange Explorer, with the ‘latest’ point in time or other various points in time they all show the same items that were deleted a while ago. It also shows three ‘cluter’ folders at the root that haven’t been in the actual mailbox for ages.

I originally raised this last year with support as 03300017, and was advised it was a known issue and would be fixed with a future update.

So after I installed the most recent cumulative update I tested this again, and didn’t see any differences. This is when I then ran the Eseutil tools to check the EDB files themselves (which look ok).

I’ve just opened a new case (03349526) providing the above context and asking for them to investigate.

From what I’ve observed, it looks like it is related to three specific time periods, as the emails are dated the following three dates.

8/5/2017
22/7/2018
24/7/2018

I have a fairly small installation, so was mostly checking to see if people with larger deployments have experienced similar.

As always, thanks for any help that can be provided.

James

[Mike Resseler]

James,

Thanks for letting me know, did you already install the last cumulative update? (https://www.veeam.com/kb2809)
Please note that you should not install it on a server that has VBR installed on that same server (then wait to update 4 of VBR first)

[MILJW002]

Mike,

Yes, I installed 2.0.0.814 soon after you posted about it in another thread. Nope, this server (and the workstation with Exchange Explorer) do not have VBR installed.

[MILJW002]

Actually, I may be wrong. While the checks were all clean, I get an “Operation terminated with error -1504 (JET_errNullInvalid, Null not valid)” error if I try and defrag. It may be corruption in the database itself.

[Mike Resseler]

James,

Make sure you add that to the support ticket.

Thanks
Mike

[MILJW002]

Mike - yep, ticket updated after I found that.

[MILJW002]

Hi,

Just reporting back. After working with support for the last week I think the EDBs (some of) were actually corrupted. They had me use the ‘CleanRepositoriesSyncVersions’ option and after that I then started to receive more Jet errors. I also spent more time looking at the EDB files specifically and the end result was I didn’t have confidence in their integrity.

So, I made a new repository to replace the corrupted one, and will use the VBR backups for old point in time recoveries if needed.

I assume others are doing the same, but I’m now happy I made multiple backup repositories for different classes of users and user data. So, while needing to make a new respository the curruption was contained. I’ve checked all the other repositories and they are fine.

Thanks as always for your help.

[Mike Resseler]

James,
Thanks for coming back to us. I am a bit surprised by the corruption of EDB (since it can heal itself). And it scares me also.
I'm glad you fixed it now, but honestly, not the type of fix I like to see. I kind of hope we still find what caused the corruption