Exchange GRT and DD Restore Fails

[Richie913]

Hi,

I have followed the very helpful guides on this community to successfully perform an Exchange GRT backup and restore to a BasicDisk (did take a while though getting everything right!)

I then tried to perform the same backup to our DataDomain appliance, using the OpenStorage disk type. The backup was successful but I cannot seem to perform a restore.

I can drill down to view all the mailboxes within a certain DB but when trying to expand an individuals mailbox I receive an "ERROR: socket open failed" message.

I have found similar posts in this community, but they seems to be for users that have never had GRT backups/restores working and normally offer answers in the way of the set up guides.

I am just wondering if anyone could shed light as to why a backup/restore works fine for a Basic Disk but the exact same configuration fails a restore for DataDomain? 

My first point to check was the DD OST Plugin version, which we are running 3.0.3, and which I have seen is compatible with Exchange GRT backups/restores. This plugin is installed on our master and media servers that connect to DD. The DD appliance is a DD640 running OS 5.2.2.4, and the 2010 Exchange servers are 2008r2 boxes. 

Could anyone suggest any known issues or possible solutions to getting this working? Or whether I have missed out a load of important information!

Thanks in advance!

[RiaanBadenhorst]

Hello 

What you could check if you have more than one media server with access to the data domain.

Make sure that the server used to perform the backup is doing the restore (browse) operation. With DD and having multiple servers with credentials, you might end up having media server X or even the master server, trying to do the browse when the backup was done by server Y.

You can set the USE_BACKUP_MEDIA_SERVER_FOR_RESTORE setting https://www.veritas.com/support/en_US/article.TECH124885

Also make sure that the brwose client has the NFS services installed.

[Marianne]

There are also some guidelines WRT Fragment size for the STU. (Will see if I can find it...) The fragment size should be made smaller than the default.
Bear in mind that the image needs to be NFS-mounted in order to browse for individual items. 
Too big fragment or NFS issues will prevent the image mount.

[Richie913]

Hi Riaan,

Thanks for your post.

I made the change to force the media server and now getting a slightly different error - again only when performing the restore from DataDomain. The restore from BasicDisk still works fine.

Now when trying to expand a users mailbox in the BAR application, the application seems to freeze for a good 4-5 minutes then I receive an error stating "ERROR: file read failed"

Not sure if this helps indicate another potential issue?

I can also confirm that the clients have the NFS services installed and running.

Thanks

[Marianne]

What is the fragment size in the STU?

[RiaanBadenhorst]

Where are you browsing BAR from? Master or client? Is the NFS service installed?

[Richie913]

Hi,

Riaan, I get the time out issue when browsing BAR from the Master, and when browsing via the Client I am getting the original Socket Open Failed error. The NFS service is installed.

Marianne, the maximum fragment size is set to 524288MB - is this too big for DataDomain? If so, would changing this effect other back ups using this storage unit? When the GRT backup is done to BasicDisk and restores are successful, the fragment looks like it is default as the "Reduce fragment size to" checkbox is unticked?

Thanks

[Marianne]

The recommendation that I have seen for GRT with dedupe storage is 5000MB. 

This is a recommendation for GRT - not DD in general. 

Yes, the value will be applied to all backups using the STU.

Bear in mind that BasicDisk writes entire image to a single tar file. 
Dedupe storage writes changed blocks and stores the info about the parts that make up the image in a separate db.
Restore request will now need to go and find all the bits and pieces that makes up the 524288MB tar file and present that as NFS mount.

I have not personally tried it, but smaller fragment size for GRT on dedupe storage makes total sense to me....

[Marianne]

Similar issue that never got resolved: https://www.veritas.com/community/forums/grt-restore

Weird thing is that GRT backup and restore to different DD model worked fine: 
https://www.veritas.com/community/forums/grt-restore#comment-9743871 

Probably best to log a call with EMC and Veritas...

[Richie913]

Thanks Marianne,

I will let the weekend jobs run through and try running another GRT job on Monday with the STU set to 5000MB. If it fails then I think you are right and I will have to go down the route of logging a call with both.

If it goes that way, I will post any fix we find!

Thank you again for taking the time to reply to my issue :)