Skip to main content
Solved

Restore Error Code: [32:392]


Forum|alt.badge.img+1

I´m trying to restore a SQL database, but it is in pending state and showing the error:

Error Code: [32:392] Description: Mount Volumes failed : [Failed to retrieve VM information from Index Cache] Source: ELB6620, Process: SQLiDA

Any tips?

Thanks.

Best answer by Mike Struening RETIRED

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.

View original
Did this answer your question?

7 replies

Forum|alt.badge.img+15

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


Forum|alt.badge.img+1
  • Author
  • Bit
  • 4 replies
  • July 1, 2021

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.

 


Mike Struening
Vaulter
Forum|alt.badge.img+23

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


Forum|alt.badge.img+1
  • Author
  • Bit
  • 4 replies
  • July 1, 2021

Yes.

Incident 210701-6

Thanks.

 


Mike Struening
Vaulter
Forum|alt.badge.img+23

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.


Forum|alt.badge.img+1
  • Author
  • Bit
  • 4 replies
  • July 16, 2021

The restore has run with success.

Thanks.


Mike Struening
Vaulter
Forum|alt.badge.img+23

Glad to hear it!


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