Inactivity time out: This has to be set to "0" (unlimited) to prevent time outs in the group when the snapshot is being taken. Big snapshots can take long time to be created.
Savegrp parallelism: set to "0" as the parallelism should be set at client level for NMM backups.
Client retries: has to be set to "0" so that there are not more than one call to VSS, otherwise backup will fail as snapshot is already in progress.
You need to provide a little more information like what are the details of the client configured for the backups? You said the exact same configuration is working on 3 other clients but I would assume the other clients are configured for other Microsoft applications which makes it somewhat but not totally that they are working.
The error message stating the module received an abort event indicates a error received to your Networker Server generated on the client.
Can you provide the details for the client configuration? What application are you backing up? I also see Symantec Antivirus in the log? Is it actively scanning the Networker program path? Doing so while running backup is know to cause issues particularly if it is scanning the temp files and index files created while running a backup.
those 3 other clients are running Exchange 2010 and the new clients are for SQL application. IS there any difference since they are now sharing the same module?
I'm not sure about Symantec AV if they are actively scanning the networker path.
It matters in that the reuirements and configuration are different based on the application being backed up. When you run the configuration checker do all the checks pass ok? If a backup is taken manually from the SQL server where you are having issues does it succeed? What if anything is in /nsr/applogs or /logs on the client where the backup is failing?
The errors shown in that output shows that user manually aborted the backup.
Have you ensured that the group configuration has the following values set to "0"?:
- Client inactivity time out
- savegrp parallelism
- client retries
Also ensure that only one backup is ran against those servers at a time, as only one concurrent NMM session can be ran on the same machine.
Anyway check that AV is configured to skip the entire /nsr folder as well as C:\System Volume Information.
Bear in mind that snapshots are by default placed in that folder (in all volumes) by VSS, and I've seen some cases where that folder was not excluded and lead to a failure in the backups or even performance issues.
Thanks Carlos. I need to check on our Symantec server if these folders are already included in exception list.
I'm not sure if setting all these entries to 0 would help, since we have other clients running fine in the same group. but I will try that anyway. Thanks for the suggestion.
Thanks Carlos, backup is now completed successfully. The wierd thing is group failed even though all clients completed successfully. I can see this message in our backup report tools
CarlosRojas
1.7K Posts
0
September 18th, 2012 06:00
Hi,
In fact that is mandatory (check documentation).
The reason behind that is as follows:
Inactivity time out: This has to be set to "0" (unlimited) to prevent time outs in the group when the snapshot is being taken. Big snapshots can take long time to be created.
Savegrp parallelism: set to "0" as the parallelism should be set at client level for NMM backups.
Client retries: has to be set to "0" so that there are not more than one call to VSS, otherwise backup will fail as snapshot is already in progress.
Thank you.
Carlos.
danag2
20 Posts
0
September 13th, 2012 04:00
Iman,
You need to provide a little more information like what are the details of the client configured for the backups? You said the exact same configuration is working on 3 other clients but I would assume the other clients are configured for other Microsoft applications which makes it somewhat but not totally that they are working.
The error message stating the module received an abort event indicates a error received to your Networker Server generated on the client.
Can you provide the details for the client configuration? What application are you backing up? I also see Symantec Antivirus in the log? Is it actively scanning the Networker program path? Doing so while running backup is know to cause issues particularly if it is scanning the temp files and index files created while running a backup.
Aegh
1 Rookie
•
84 Posts
0
September 13th, 2012 05:00
those 3 other clients are running Exchange 2010 and the new clients are for SQL application. IS there any difference since they are now sharing the same module?
I'm not sure about Symantec AV if they are actively scanning the networker path.
danag2
20 Posts
0
September 13th, 2012 07:00
It matters in that the reuirements and configuration are different based on the application being backed up. When you run the configuration checker do all the checks pass ok? If a backup is taken manually from the SQL server where you are having issues does it succeed? What if anything is in /nsr/applogs or /logs on the client where the backup is failing?
CarlosRojas
1.7K Posts
0
September 18th, 2012 03:00
Hi there,
The errors shown in that output shows that user manually aborted the backup.
Have you ensured that the group configuration has the following values set to "0"?:
- Client inactivity time out
- savegrp parallelism
- client retries
Also ensure that only one backup is ran against those servers at a time, as only one concurrent NMM session can be ran on the same machine.
Anyway check that AV is configured to skip the entire /nsr folder as well as C:\System Volume Information.
Bear in mind that snapshots are by default placed in that folder (in all volumes) by VSS, and I've seen some cases where that folder was not excluded and lead to a failure in the backups or even performance issues.
Thank you.
Carlos.
Aegh
1 Rookie
•
84 Posts
0
September 18th, 2012 06:00
Thanks Carlos. I need to check on our Symantec server if these folders are already included in exception list.
I'm not sure if setting all these entries to 0 would help, since we have other clients running fine in the same group. but I will try that anyway. Thanks for the suggestion.
Panwar
79 Posts
0
September 20th, 2012 04:00
Hi
Please refer the KB article given below. Make sure that for filesystem backup configuration is done according the to steps given in the KB article
http://solutions.emc.com/EMCSolutionView.asp?id=esg128989&usertype=C
Regards
Panwar
Aegh
1 Rookie
•
84 Posts
0
October 4th, 2012 04:00
Thanks Carlos, backup is now completed successfully. The wierd thing is group failed even though all clients completed successfully. I can see this message in our backup report tools
=======================================================
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT4321733.xml
libpsvssclnt: C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT4321733.xml level=full, 27 MB 00:00:02 1 file
7167:libpsvssclnt: libpsvssclnt completion time: 10/4/2012 3:35:09 AM
NMM .. Request the PS backup service backup the GUI presentation objects to the NetWorker saveset 'VSS:/'.
NMM .. Delete the temporary snapshot as part of deport
76958:nsrsnap_vss_save:NMM .. successfully completed final processing of replica.
77175:nsrsnap_vss_save:NMM .. completed commit replica with status of true.
80875:nsrsnap_vss_save:NMM snapshot backup completed successfully.
68150 1349314547 2 0 0 9764 5632 0 ch00sem3.eu.mt.mtnet nsrsnap_vss_save 39 nsrsnap_vss_save: Exiting with success. 0
NSR_BACKUP_LEVEL: incr;
NSR_CLIENT: CH00SSL1;
NSR_CONNECTING_DIRS: No;
NSR_DATA_MOVER: ch00ssl1;
NSR_DM_OS_NAME: windows;
NSR_GROUP: D_DD_FS_NMM;
NSR_IGNORE_MISSING_SYSTEM_FILES: yes;
NSR_PARENT_JOBID: 2095198;
NSR_PS_DEBUG_ID: 1349312406;
NSR_SERVER: ch00sm33;
NSR_SNAP_DELETE_ON_CLEANUP: 1;
NSR_SNAP_TYPE: vss;
NSR_STRICT_SYNC: 0, 0;
NSRSNAP_JOBID: 2095257;
optype: conventional;
snap_id_list_1: NetWorker Module for Microsoft Applications,
Microsoft Volume Shadow Copy Service;
snap_sessionid: 1349312410;
NMM .. Starting Backup. This operation may take a long time depending on the size of the data requested.
43705:libpsvssclnt: Save Operations value is ignored on this OS platform.
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43227637.xml
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43223218.xml
libpsvssclnt: C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43223218.xml level=full, 27 MB 00:00:01 1 file
7167:libpsvssclnt: libpsvssclnt completion time: 10/4/2012 3:44:32 AM
NMM .. Request the PS backup service backup the GUI presentation objects to the NetWorker saveset 'VSS:/'.
NMM .. Delete the temporary snapshot as part of deport
76958:nsrsnap_vss_save:NMM .. successfully completed final processing of replica.
77175:nsrsnap_vss_save:NMM .. completed commit replica with status of true.
80875:nsrsnap_vss_save:NMM snapshot backup completed successfully.
68150 1349315115 2 0 0 1264 5028 0 ch00sem1.eu.mt.mtnet nsrsnap_vss_save 39 nsrsnap_vss_save: Exiting with success. 0
N_CLEANUP: 1;
NSR_SNAP_TYPE: vss;
NSR_STRICT_SYNC: 0, 0;
NSRSNAP_JOBID: 2095260;
optype: conventional;
snap_id_list_1: NetWorker Module for Microsoft Applications,
Microsoft Volume Shadow Copy Service;
snap_sessionid: 1349312415;
NMM .. Starting Backup. This operation may take a long time depending on the size of the data requested.
43705:libpsvssclnt: Save Operations value is ignored on this OS platform.
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43219716.xml
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43227637.xml
libpsvssclnt: C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43227637.xml level=full, 34 MB 00:00:02 1 file
7167:libpsvssclnt: libpsvssclnt completion time: 10/4/2012 4:04:58 AM
NMM .. Request the PS backup service backup the GUI presentation objects to the NetWorker saveset 'VSS:/'.
NMM .. Delete the temporary snapshot as part of deport
76958:nsrsnap_vss_save:NMM .. successfully completed final processing of replica.
77175:nsrsnap_vss_save:NMM .. completed commit replica with status of true.
80875:nsrsnap_vss_save:NMM snapshot backup completed successfully.
68150 1349316339 2 0 0 6892 3200 0 ch00ssl1 nsrsnap_vss_save 39 nsrsnap_vss_save: Exiting with success. 0
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43219716.xml
libpsvssclnt: C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT43219716.xml level=full, 27 MB 00:00:02 1 file
7167:libpsvssclnt: libpsvssclnt completion time: 10/4/2012 3:41:31 AM
NMM .. Request the PS backup service backup the GUI presentation objects to the NetWorker saveset 'VSS:/'.
NMM .. Delete the temporary snapshot as part of deport
76958:nsrsnap_vss_save:NMM .. successfully completed final processing of replica.
77175:nsrsnap_vss_save:NMM .. completed commit replica with status of true.
80875:nsrsnap_vss_save:NMM snapshot backup completed successfully.
68150 1349314932 2 0 0 10636 10624 0 ch00sem2.eu.mt.mtnet nsrsnap_vss_save 39 nsrsnap_vss_save: Exiting with success. 0
f5bcdca9-9d97-11e0-b7d8-0050568f7760}\\|d2162bd400001000000000\
00|1|0|0|0|
\\\\?\\Volume{f5bcdca6-9d97-11e0-b7d8-0050568f7760}\\|d5162bd400001000000000\
00|1|0|0|0|";
modified since: 1349226767;
NSR_BACKUP_LEVEL: incr;
NSR_CLIENT: CH00SEM3.eu.mt.mtnet;
NSR_CONNECTING_DIRS: No;
NSR_DATA_MOVER: ch00sem3.eu.mt.mtnet;
NSR_DM_OS_NAME: windows;
NSR_GROUP: D_DD_FS_NMM;
NSR_IGNORE_MISSING_SYSTEM_FILES: yes;
NSR_PARENT_JOBID: 2095198;
NSR_PS_DEBUG_ID: 1349312412;
NSR_SERVER: ch00sm33;
NSR_SNAP_DELETE_ON_CLEANUP: 1;
NSR_SNAP_TYPE: vss;
NSR_STRICT_SYNC: 0, 0;
NSRSNAP_JOBID: 2095261;
optype: conventional;
snap_id_list_1: NetWorker Module for Microsoft Applications,
Microsoft Volume Shadow Copy Service;
snap_sessionid: 1349312417;
NMM .. Starting Backup. This operation may take a long time depending on the size of the data requested.
43705:libpsvssclnt: Save Operations value is ignored on this OS platform.
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT4321733.xml
====================================================
CarlosRojas
1.7K Posts
0
October 9th, 2012 01:00
Hi Iman,
What NW server and client versions are we talking about?
I remember an escalation some time ago for this same issue.
Thank you.
Carlos.
Aegh
1 Rookie
•
84 Posts
0
October 9th, 2012 07:00
Hi Carlos,
Both are using NetWorker 7.6.4.1.Build.1049 Network Edition/195
CarlosRojas
1.7K Posts
0
October 11th, 2012 04:00
Hi Iman,
Actually the fix is already included in that version.
Not convinced with those logs, as I don't see the "finished successfully".
To be 100% sure of the status of an NMM backup please render and check the nmm.raw file within /nsr/applogs folder of each NMM client.
Please take a look at those and let us know what you see in there.
Thank you.
Carlos.