Hi @Kayser 

Thank you for the question.

Reading through ticket history for similar errors, the MA might be playing a part.

Since this is probably a Microsoft Windows VM, restoring a SQL DB, please ensure that the MA used to perform the restore is a Windows MA, which should be able to mount the windows volumes during restore.

This issue can occur if a unix MA is selected to perform AppAware SQL restores for a Windows VM.

Thanks,

Stuart

Hi, Stuart.

Thanks for your answer.

All the medias here are Windows. I have opened a case and the support team is working now and the focus is on index cache problem at the media server.

I´ll post here as soon I have a confirmation of this…

Thanks.

Hey @Kayser !  Do you have a case number I can track?

Yes.

Incident 210701-6

Thanks.

Adding a partial update from the incident as this seems like it might be resolved:

Started a new restore (*From copy precedence 1, rather than from snap; though VM was still from snap*) which is now running. No further OS mount or 3dfs port binding errors seen.
]

-Kayser then tried an out of place restore from SQL side, with name change. This is not supported from VSS.

-Therefore we started it again without the name change and restore is running.

The restore has run with success.

Thanks.

Glad to hear it!