Ridiculously slow/long restore of exchange items

[mcannet]

I am running Veeam 9 on a virtual Windows 2008 R2 server - vmware 6. I'm using Lefthand P4500 G2 storage nodes for backup (yes, I know this is incredibly inefficient - it's what I have to work with at this time). My exchange environment consists of two DAG servers and two CAS/HT servers - exchange 2010. I backup one DAG and one HT/CAS in my backup job. Anyway, I'm trying to restore a users sent items folder that they "accidentally" deleted. - No worries I have Veeam! and good backups. We use archiving rules to move items off to archive after 1 year - SO...I am trying to restore a years worth of sent items to the users mailbox. I'm restoring directly to the users mailbox. I first attempted to restore everything at once - about 6 days into the restore - I felt it was hung - probably I was wrong. I cancelled the restore and started it again, only this time trying to do 1 month at a time. I took 3 days to restore 1 month of sent items - maybe 150-200 emails. Now I am on month 3 - about 3% done with Veeam telling me it will take about 5 days to complete. For one month!

Now I get that I'm not on optimal equipment and that the backups get compressed and all - but this seems crazy how long it's taking. Is there anything anyone can suggest to possibly speed up the restores?

The SANs are in a cluster with 5 nodes * 60 1TB SAS MDL disks - iSCSI.

As I'm wrapping up this post I just checked on the restore and have the following error message:

Failed to wait mutex VeeamXmlLoggerDbSessionID: 4b4bb073-2db3-41d8-855d-aa9d75933880:timeout 40 sec exceeded

Any help would be greatly appreciated.

P.S. There are no other jobs running, backup or otherwise that are running with this restore - which is causing all kinds of potential trouble for me.

[foggy]

Hi Mark, is everything involved local (backup repository, Veeam B&R server, target server)? Have you contacted support with the mentioned error message?

[mcannet]

Everything in my environment is virtual. I have a virtual B&R server, virtual proxies, etc. They are all hosted in same chassis. The storage, is iSCSI. The backup storage is different than the production storage - so not too much local.

[foggy]

Is the backup storage located in the same site, not over a slow link? Once again, I encourage you to contact support for a closer look at your setup/logs.

[mcannet]

ok, i will contact support. That error message I received apparently was not the restore I was trying to get history on another job.

The storage is in same site.

[foggy]

Then it might be related to database performance. Support will be able to check.