Unsolved
This post is more than 5 years old
1 Rookie
•
110 Posts
0
2134
November 28th, 2012 01:00
NW 8 & NMM 2.4 - file backup problem (0KB size)
Hi all
I have a strange problem when doing file backups using NMM 2.4
NWServer:
NW 8.0.0.4.204
Client:
Windows 2008 R2 x64
NW 8.0.0.4.204
NMM 2.4.0.375
Running:
Exchange 2010 SP2
SQL 2008
Problem:
When doing file level backups the backup completes without error but the size of the backup is 0KB
Have tried both full drive and subfolder backups.
I have checked that schedules and directives are ok.
I have reinstalled NW on client.
vssadmin list writes report no errors.
SQL and Exchange backups run without issues.
Unsure of how to proceed, any tips ?
(attached is log of running group "testsnap" backing up c:\tmp (550mb) on the affected server.)
Thanks
Eivind Antonsen
.........................................
0 events found


Bebo2k
544 Posts
1
November 29th, 2012 19:00
Additionally please follow the steps described in the following KB:
https://solutions.emc.com/emcsolutionview.asp?id=esg110691
Waiting your updates,
Ahmed Bahaa
Bebo2k
544 Posts
1
November 29th, 2012 19:00
Hi Eivind,
I can see from the log you had attached the error : couldn't get volume Info on e:\. Error Code = 3
I had seen this issue before and it was solved in NetWorker 7.6.2.4 as per the following KB article:
https://solutions.emc.com/emcsolutionview.asp?id=esg123851
But as now you NetWorker is 8.0 (which should include this fix ) , I recommend the following :
1- Stop NW services on the client including Replication Manager service.
2- Rename /nsr/tmp on the client
3- Start services on NW client, including RM service.
4- Manually delete the shadows on the client using diskshadow (explained below).
5- If possible reboot the client.
6- Run a new backup and check the results.
To delete snapshots or shadows in Windows 2008 and 2008 R2:
c:\>diskshadow
DISKSHADOW>delete shadows all
DISKSHADOW>exit
Re-run the backup and provide us with the details,
Hope this helps you,
Ahmed Bahaa
eivinda
1 Rookie
•
110 Posts
0
November 30th, 2012 00:00
Hi
Will try
The thing is, the client does not have an E:\ drive….
Kind regards
eivinda
1 Rookie
•
110 Posts
0
November 30th, 2012 05:00
Hi
I may have found the cause of this. (test backups now run as excpected)
First, I wrongly stated the client to be 2008 x64, it's actually a SBS 2011, my bad.
The cause is a SharePoint service pack which was installed in July, why it took so long for it to affect the backups, I have no idea.
See these links for information:
http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/fd0f8dfd-d6d5-403f-b1d4-3f92e7859e26/
http://blogs.technet.com/b/sbs/archive/2011/05/24/you-must-manually-run-psconfig-after-installing-sharepoint-2010-patches.aspx
I will let the scheduled groups run during the weekend before I say it's solved.
Regards
Eivind
Bebo2k
544 Posts
0
December 3rd, 2012 13:00
Hi Eivind,
How does the scheduled backup goes in the weekend ? Hope that the issue has been solved and backups are running successfully. Waiting your updates.
Thanks,
Ahmed Bahaa
eivinda
1 Rookie
•
110 Posts
0
December 3rd, 2012 23:00
Hi
My test backups of for example only "C:\" runs fine.
But, when I try saveset "All" the backup of the drives fail, and the group never terminates.
Error message:
52051:nsrsnap:Printing savecmd=nsrsnap_vss_save after parsing
79549:nsrsnap:[nsrsnap.c 1907] Invoking command: "nsrsnap_vss_save -A optype=conventional -A "NSR_SNAP_TYPE=vss" -A "NSR_VSS_FORCE_SYSTEM_PROVIDER=yes" -A "NSR_IGNORE_MISSING_SYSTEM_FILES=yes" -A NSR_PARENT_JOBID=320001 -c client.domain.local -g "Snapshot File" -LL -m client.domain.local -s nwserver.domain.local -a "DIRECT_ACCESS=No" -t 1354528746 -o RENAMED_DIRECTORIES:index_lookup=on;BACKUPTIME:lookup_range=1354528746:1354528746; -l incr -q -W 78 -D9 -A snap_sessionid=1354561222 -A NSR_STRICT_SYNC=0 "SYSTEM COMPONENTS:\ F:\ C:\ A:\
Internal error.
I'm currently working on this issue with EMC support
Bebo2k
544 Posts
0
December 4th, 2012 02:00
Hi Eivind,
I highlighted the "RENAMED_DIRECTORIES:index_lookup=on" in your command, which means that the "Backup renamed directories" attribute in Client resource is Enabled, as if it is disabled, it should be like "RENAMED_DIRECTORIES:index_lookup=off" in the command.
Please double check again that option and ensure it is turned off, and from the client side, stop the NetWorker Services and rename the tmp directory under the /nsr , rename it to tmp.old and start the NetWorker services again. Afterwards run the backup to test. I will be waiting your updates.
Thanks,
Ahmed Bahaa
B4FQqUoIrW12094
60 Posts
0
January 20th, 2013 10:00
NMM Supported scenarios:
1)DB and logs are on the same LUN and in different directories.
2)DB and logs are on different LUNs and mounted on the same drive in different directories.
3)DB and logs are on the same LUN, using the same mount point, and DB and logs are in different directories.
NMM Unsupported scenarios:
1)DB and logs are on the same path (same directory).
2)DB and logs are on the same volume where one component is using physical paths and the other is using mount points mounted on the same drive(volume).
3)DB and logs are on the same LUN using different Mount points on the same drive.Possible Workaround: Disable Consistency check.