Skip to main content
Question

Guest files restore taking Primary VSA even browsing from the Secondary Copy and Failing

  • 16 September 2024
  • 3 replies
  • 25 views

Forum|alt.badge.img+6

Hi All,

We have a VM backup with (VMware) VSA Snap. The same job was copied to secondary which was in Azure.

Our VSA was later removed as there is no dependency on it.

We are trying to restore few Guest Files from the VM backup from the secondary copy with Azure Media Agent and Library, but the restore is failing saying that the Old VSA was unable to communicate.

Not sure why it is asking this way, even we are browsing it from Cloud MA which is having VSA installed on it.

Our VM was a Windows Server, Old VSA is Windows and new MA/VSA is Linux.

Any suggestions or idea, why it is taking it even we are giving other MA/VSA?

 

Thanks in Advance..

 

Warm Regards,

Sravan Kondeti

3 replies

Forum|alt.badge.img+6

Hi @backup ,

Good day!

Is the old VSA server Is it being removed completely from the commserv console/Virtual pseudo client instance properties or its only decommissioned?

Guest file is performed for windows or linux VM ?

I would suggest you raise a case with CV support to investigate this further.

Regards,

Sureshkumar S


Forum|alt.badge.img+6
  • Author
  • Byte
  • 16 replies
  • September 17, 2024

Hi @Sureshkumar S ,

Thanks for responding.

It is only acts as a VSA. It is decommissioned and removed from Virtualization Client.

And the Guest File browse we are performing is a Windows machine.

Live mount and browsing are happening with Cloud Media Agent, but while running the restore, it is pointing to old VSA which is already removed.


Forum|alt.badge.img+6

Hi @backup ,

Thanks for the update

We may need to check the logs to identify the cause

I would request you to raise a support case with all logs to proceed further on this 

Regards,

Sureshkumar S


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings