topic Failed to get volume mount point from file path - Snap Manager for SQL Server in Data Protection

Failed to get volume mount point from file path - Snap Manager for SQL Server

weaverrw — Wed, 04 Jun 2025 22:07:05 GMT

I have a three node Windows 2012 cluster. Nodes 1 and 2 host one SQL Server Instance (INSTANCE A) and Node 3 hosts a seperate SQL Server Instance (INSTANCE B).

Snap Manager for SQL Server 7.2 is installed.

Whenever I try to run a backup on INSTANCE A for example, I get the following errors:

[13:10:12.902] [SERVER] Getting SnapInfo directories configuration...

[13:10:12.908] [SERVER] Error Code: 0x80070002
The system cannot find the file specified.

[13:10:12.908] [SERVER] Failed to get volume mount point from file path. Using default drive...

[13:10:12.908] [SERVER] Error Code: 0x80070002
The system cannot find the file specified.

[13:10:34.342] [SERVER] Failed to create SnapInfo Directory.
[13:10:34.342] [SERVER] Failed to get SnapInfo directory from registry, please re-run the Configuration Wizard.

If I run the Configuration Wizard against INSTANCE A, the backup runs successfully. But then if I try to run a backup against INSTANCE B, I get the same SnapInfo Directory error. If I run the configuration wizard against INSTANCE B, the backup succeeds but then I get the same error on INSTANCE A.

Can you please provide guidance as to how to fix this issue? I'm stumped.

Re: Failed to get volume mount point from file path - Snap Manager for SQL Server

georgevj — Tue, 16 Feb 2016 05:08:28 GMT

Did you try "Moving multiple SnapInfo directories to a single SnapInfo directory" from page number 57 of the SMSQL Admin guide available at https://library.netapp.com/ecm/ecm_download_file/ECMP11658050 ?

Re: Failed to get volume mount point from file path - Snap Manager for SQL Server

weaverrw — Tue, 16 Feb 2016 13:44:54 GMT

Thanks for your response. I'm unable to move them to a single SnapInfo directory because even though it's a single cluster, INSTANCE1 has storage that is only visible from nodes 1 and 2. And INSTANCE2 has storage that's only visible from node 3. This is by design.

We have AlwaysOn configured where INSTANCE1 is the primary replica and INSTANCE2 is the secondary replica.