Are the NMM licenses OK?

You need one license for each Physical server.

Hello Ryan,

This could be for different reasons. I'm thinking of a potential name resolution issue, or a wrong configuration.

Does the SQL instance has the same name as the cluster?

Bear in mind that the nsrsnap_vss_save command has to be ran against the SQL instance name and not the cluster name,

Thank you,

Carlos

I've verified that there are sufficient NMM licenses.  In fact, this was originally appearing during a phase when NetWorker was in eval mode.

Also, we found an issue with the Windows OS that the cluster was running on - the WMI stack was messed up.  When we moved the SQL instance to the other host on the cluster, all those errors in the config checker went away.  So now the config checker comes back clean.

Regarding name resolution - that is typically one of the first places I look as well, since it can be so insidious.  This environment is complex in that there are multiple networks, and the backup server is sitting on all the networks, but with a unique FQDN for each network it sits on.  Name resolution is done via DNS, and always specifying the FQDN of whatever it is being communicated with.  I assumed that with the file system backup using the NMM having been successful, that name resolution is valid, so I didn't go back to thoroughly double check that.  I have had situations with previous NMM versions where there were issues with it dealing with a FQDN that differs from the return value of the 'hostname' command - so I suppose it is not inconceivable that there is something that must be configured uniquely here for the module to work in this environment with SQL.

The thing that is odd is that even when nsrsnap_vss_save runs with -D5 or -D9, everything looks hunky dorey until it just says 'internal error', and then bombs out.  Before that, I can see it doing all kinds of name resolution checks, determining which name to use for data transfer, validating the name of the save set being used, etc.  Then, just 'internal error'.  No indication as to why.  It's so abrupt that I'd think it ran across a bad piece of code or something, as opposed to a misconfiguration that would more gracefully cause it to fail (and presumably with an indication as to what happened).

The name of the client is the name of the SQL cluster, so that is fine - although in my troubleshooting I did attempt the name of the windows cluster, but it bailed out long before the failure seen when specifying the SQL cluster name.

The SQL instance name is different from the cluster name.

I suggest you open an SR with support.

Try to use the backup for SQl and NMM with VDI backup and recovery.

It is supported with nmm.

Stop SQL VSS Writer.

Use virtual IP address for SQL Database - as you have a cluster.

Put for the client as save sets

MSSQL:

Remove all snapshot commands and application information from the client

and all the snapshot information from the backup grup.

Use the backup command

nsrsqlsv -A virtual_short_name

It will work.

Regards.

Hi guy's,

Did you open a sr case?

What was the solutions? Could you share the the sr case? I got the same issue..

cheers,

Do you also use build 92?  As in such case you are far away from latest patch level.

Hi Carlos Rojas,

Thanks for your comments. It's really helpful for me to sort out the issue.

In my case, I have instance which was different from Server host name.

I am not supposed to change instance name as well server host name. Is 't possible to do backup with this?

FYR, Eventhough networker was enabled and able to communicate from Networker server as post owner said.

NETWORK_ADAPTER_STATUS

ERROR: Network adapters which can be used for NMM backup operations, are not detected.

Check if any network adapters are [installed | media-connected | not-disabled].

Thanks Please give suggestion asap.