Which NMM module do you run?  For proper AoAG backup, you should use 8.2.1.8.  Also, can you share more details about the config you made and also log from client.

Hello,

Thanks for your reply.

We started with NMM 8.2.1.7 and then uninstalled /reboot and installed 8.2.2. as well.The setup is a 2 node SQL 2014 AoAG .Have given the permissions to NT System Authority/System as per the User Guide.

When trying to use Client Configuration Wizard and specifying the Cluster Name > unable to browse the SQL Instances from the node.So manually created the Client Resource.I have specified Windows Log On account which has full permissions on the DB.

Please advice which all logs are needed to enable me attach.

Fo SQL AoAG backup, at least if you plan to use secondary copy, you must use backup user.  I assume that is what you are referring when you say Windows Log On account?  Or did you start service with that user?  I personally never change service.  The logs you need to supply are on application side in applogs folder - this is where you will find backup log (nsrsqlsv.raw or something like that).

Hi,

did you find a solution for your problem? Because i experienced the excat same behaviour with a new 8.2.2 installation and a MSSQL AG Installation on top of a Windows Failover Cluster. Backup suceeds with 0kB written. Backing up the cluster nodes by themselves, the backup of the system databases suceeds, using the same login account as with the cluster client.

Kind regards

Mario

Hi,

we don't have an additional instance running on the standalone servers. So on the client "clustername.domain" we added MSSQL#SQLAG01 and MSSQL#SQLAG02 as savesets. We also triple checked the settings on both sql nodes, meaning "secondary readable", "prefer secondary" etc.

Here is a sample output (changed the hostnames) from one saveset:

43708:(pid 6980):Start time: Thu Jan 07 11:11:31 2016
43621:(pid 6980):Computer Name:      User Name:
100002:(pid 6980):Processing DATA DOMAIN INTERFACE command line parameter.
104810:(pid 6980):Detected application flag NSR_CONSISTENCY_CHECKS set to FALSE in NW resources for client .
29446:(pid 6980):Local host has following SQL Server online:
37977:(pid 6980):        MSSQL server :
100220:(pid 6980):Saveset [MSSQL#SQLAG01] validated.
96808:(pid 6980):Successfully converted from group id to AG name.
51340:(pid 6980):jobhandler(340): Created Job ID: 357
Save command: "D:\\Program Files\\EMC NetWorker\\nsr\\bin\\nsrsqlsv.exe" -s networkerserver.domain.com -g SQL -y "Thu Jan 14 11:11:06 GMT+0100 2016" -w "Thu Jan 14 11:11:06 GMT+0100 2016" -LL -m -a "device interface=data domain" -a "Data Domain interface=IP" -b VMwareMgmt -l full -q -W 78 -j FALSE -z FEDERATED_SLAVE=true -z FEDINDEX_NAME=MSSQL -z FEDCLIENT_NAME= -N MSSQL#SQLAG01 MSSQL:VUM_DB
97656:(pid 6980):==========nsr/db_apps/bsmsql/sqlxbsacompforsave.cpp(714): Slave backup with job id (357) completed successfully on node : clustername.domain.com: MSSQL#SQLAG01 level=full, 0 KB 00:00:00      1 file(s)
completed savetime=1452161492
43709 1452161492 1 0 0 3120 6980 0 (pid6980) NSR notice 13 Stop time: %s 1 35 25 Thu Jan 07 11:11:32 2016

Unable to find any full backups of the save set 'clustername.domain.com:MSSQL#SQLAG01' in the media database. Performing a full backup

Is your setup also MSSQL$INSTANCENAME#AGGROUPNAME?  Because I was told that AoAG in cluster with $INSTANCENAME is not supported.  In release notes or KB, they suggest to setup failover between cluster nodes and have AoAG between cluster system and standalone system (as secondary replica) and then have backup configured that way.  In current GA of NMM9, this still seems to be the same, but rumors are that SP1 should address it.

I don't see which version of NMM you run in your log, but there is couple of bugs which have been fixed that you might have here - see readme and fixes at ftp://ftp.legato.com/pub/NetWorker/NMM/Cumulative_Hotfixes/8.2.2/

Dear All

I changed the backup preference in SQL AAG to primary.First time it worked for 2-3 days but the job summary was still showing 0KB.However NMM for SQL User in Client was showing the index and data.Even SQL query was returning that the data has been backed up.

However after 2-3 backups ,the backup started finishing in minutes.So we raised a SR with support that how come 80 /100GB DB can be backed up in 3 minutes and show successful.

Best Regards,

Manish Gupta

Hi,

we also did change the backup mode to primary only. The nsrsqlsv command line query in the logs showed the correct node (-m primarynode), but still only 0kB backup in just under 50s. Also the bootstrapindex always gots written successfully the media.

Both client and nmm are version 8.2.2. Can i update the nmm without updating the whole environment?

Kind regards

Mario

Dear Sir

In our case the issue is under investigation and has been escalated to specialist 

Best Regards,

Manish Gupta

StoreTech Systems Inc.

P.O. Box: 18478, Jebel Ali Free Zone

Dubai - UAE.

Tel: +971 4 8819627

Fax: +971 4 8819628

Mobile: +971 50 6505349/ 55 8825473

email: manish@storetechsys.com

URL: http://www.storetechsys.com

Sent from Outlook Mobile

Mario_W wrote: Both client and nmm are version 8.2.2. Can i update the nmm without updating the whole environment?

8.2.2 is not precise enough as you have 8.2.2.x.  However, you can update NMM quite simply - remove existing one and apply new (latest) one.

I did an update to 8.2.2.3 and made some other changes. Still running a sucessful job with 0kB written according to the job log. But in the NMC log i did find entries with "xxxx MB written". So i went to both SQL servers, started "Networker User for SQL" and selected the cluster resource within "Operation > Select NetWorker SQL Server Client" and suprisingly all databases from both availibiltiy groups are listed with the correct backup time.

Still strange, but i think we are close to a satisfying solution.

Hi,

According to EMC support 0KB is an expected behavior for Federated Backups.

We are still checking with them how to ensure backup is done as our backups are finishing few minutes and SQLquery shows backup is successful.

Awaiting procedure to do Directed Restore to check the validity of the backup.

Best Regards,

Manish