Restore of vsphere server running via MMS instead of CASO server

[dgunner]

I have 2010 R3 on 3008 R2 at two sites connected by a WAN.

vSphere servers are backed up on the MMS (Site A) and then optimise deduplicated to the CASO (Site B).

When I run a restore job on the CASO, I can see that the MMS server at site A is connecting to the vSphere server at site B and the data is being pulled from the CASO, to the MMS and then back to site B onto the vSphere server.

The problem seem to be that when I select the server to restore, even though the media location says the CASO at site B, the media server field defaults to the MMS. If I change it to the CASO server the job fails.

I checked catalogs and they are replicated so hopefully not the problem.

Any suggestions to get this on track?

Much appreciated.

[Sameer_Kapadia]

As I understand, the MMS is on Site A and CAS and vSphere server are at Site B. The backup job is created on CAS and delegated to MMS, and restore job is also created on CAS.

I tried to simulate your scenario on my test setup with CAS-MMS, shared B2D and local file backups since I believe this has nothing to do with deduplication folder and vSphere server. I created backup job similar to yours and then created a restore job on CAS, in the media server field I selected the CAS server, just like you did. The restore job ran successfully on CAS server.

Could you provide the error and the job log of the failed restore job when you selected CAS server in the media server field?

In the meanwhile I will try to replicate this scenario with deduplication and backup target as vSphere server.

On a side note, Since vSphere server is at a different site then the MMS site and in the same site as CAS. It would be beneficial to directly backup vSphere server through CAS and not delegate it to MMS.

[CraigV]

Hi,

Where are your catalogs and media information situated? Replicated/centralised/localised? This can have a direct impact on the way your restores are run...

Thanks!

[dgunner]

Hi,

The restore issue is now resolved. There was an underlying issue which a Symantec engineer pointed out which is that restore selection lists can become corrupt so although it looked correct on the screen, it was corrupt in the database.

While the engineer went off to see what else was causing the main issue I managed to solve it. The issue with restoring was due to there not being a user account on the backup server with the same name and password as the one created on the vSphere server. Again, even though in the GUI everything checked out and credentials were validated, BE required a Windows user (member of local admins) to exist on the local server.

 At the main site you can add the backup service account to vCenter and grant permissions. At the recovery site without vCenter you can't do this as vSphere can't have a Windows user account in the format domain\username. Therefore I created a vSphere user and a local Windows user with the same name, problem solved!

All of this is documented BUT it is easy to mistake the vSphere credentials you supply for restore redirection and for BE to browse the vSphere server as being what is required. All that does is connect you to the resources which misleads you into thinking you've done everything correctly. The key is to use the right username, not just one that will connect you to vSphere, it needs to be one that you have created on the BE server to run the services under and also created on vSphere and granted the required permissions - the two are "tied" together. You can create two accounts if you prefer but I don't see the need to.

 Restores are now working as they should be, albeit a bit on the slow side (600MB/min). I will try 2012 and see if the SAN option for restore is there.