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

Hi

Will try

The thing is, the client does not have an E:\ drive….

Kind regards

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

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

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

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

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.