WE have a Optimised Deduplication setup
CAS - Jobs are setup and run from this server to local storage
MMS - Local storage
CAS manages all jobs, Backups run on MMS server to local dedup storage, then duplicates to CAS deduplication storage.
SDR files are located on both servers
When attempting to convert to Virtual we are requested to restore from CAS or MMS, CAS is selected.
When the communication between the CAS and MMS is established, all convert jobs run successfully.
When communication is dropped, these converts fail.Inside the job setup, the Conversion settings options dissapear (ie, CPU, mem etc....)
Strange though this never worked in SP1,SP2. Worked fine in SP3, but after upgrade to SP4 this stopped working again.SP4 was required as SP3 was unable to restore GPT drives.
The reason we doing this and have this setup is for DR purposes, so if the client premises were to burn down wee have all the backed up data sitting at a DR site. In this scenario, the MMS sserver would no longer be available.
Appreciate any assistance.
If you're trying to run this job on the MMS and designated from the CASO, the job (and it goes for ANY job) will stall with no comms between the MMS and the CASO.
This is the danger when centralising your catalogs and data on the CASO. Any other setup (Localised/Replciated) should see your jobs go through.
That said, you're able to change the connection speed on the MMS so that it is seen as connecting across a slower link. Go to the MMS in question and make this change and then try again.
Noted on this..so you have two backup servers one on your DR site and on the HO.
If you are using SDR, so you are using restore from a backup exec server?
We running the job on the CAS server.All Catalogues are on the CAS server.I have killed the link to the MMS on purpose so we can test the DR ability. This is when we discovered the issue.We need to prove that if the HO was to dissapear we could still reccover the data, thus severing the link to the MMS and HO.
Yes we have 2 BE servers, 1 at HO and other at the DR site.We trying to restore from the DR site, as though the HO was no longer there.
...just to add...with the comms down between the MMS and the CASO there is only 1 way to make sure jobs will run on the MMS and that's to edit out the CASO from the MMS's registry. Check below on how to do so:
* regedit.exe --> HKEY_LOCAL_MACHINE --> SOFTWARE --> Symantec --> Backup Exec and
* look for a key called Database Server.
* Change the server name in there from your CASO to the MMS.
* Restart the MMS services thereafter.
As always, make a backup of the registry BEFORE doing anything.
OK, so it is probably trying to make some sort of contact with the MMS. Have you tried to disable communications with the MMS from the CASO?
Thats exactly what we have done. This is when the problem occurs.
When these communications are up, everything works fine.
I can see the job is definetly using the CASO server and storage to do the convert, but it seems to want this communiation for some reason.
As you could imagine, in a DR situation, this communication would be gone.
...I assume that SP4 is also installed on the MMS?
If so, then I'd recommend opening a call with Symantec as this might be an issue with SP4 having possibly changed the behaviour of restores.
Karl: If this is still not resolved I'd recommend contacting 1 of the SYmantec employees on this site. Send them the support call # and ask them to escalate.