NMM application Guide says:

SQL Server VDI recovery fails if database, data files, or filegroup name contains space at the end.

If SQL Server VDI database, data files, or filegroup name contains space at the end, then backup is successful but the piecemeal recovery fails with the following error:

37948:(pid 3908):No logical file named Filename in original database was part of Filegroup specified for recovery

Solution

Perform normal or copy recovery.

Hi!

I'm actually doing copy recovery to another server,

Cheers!

And no, it has no spaces at the end, and its still not working

Can you check what logical name is used?  You can usually see that via nsrinfo in verbose mode.

This is the output from nsrinfo, nuosream1 is the name I gave to the filestream in SQL

MSSQL:/, size=356, off=0, app=mssql(14), date=1372794426 7/2/2013 12:47:06 PM

MSSQL:/nuodb, size=1598436, off=0, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./PRIMARY, size=256, off=1598436, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./PRIMARY./nuodb1, size=272, off=1598692, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./FileStreamGroup1, size=272, off=1598964, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./FileStreamGroup1./nuosream1, size=296, off=1599236, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./, size=300, off=1599532, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./PRIMARY./, size=248, off=1599832, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb./FileStreamGroup1./, size=268, off=1600080, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

MSSQL:/nuodb%/files.1372794423.1372794424, size=456, off=1600348, app=mssql(14), date=1372794423 7/2/2013 12:47:03 PM

Well, record of filestream is there which is good thing.  Do you use NMM or MSSQL and which version?  I don't use filestreams so I can't test it, but to confirm further - are you doing restore to the same server with same user?  If not, permission model, if closed too much, may trigger situation where you don't see backup due to lack of permissions. Next, can you supply fully rendered log for restore attempt from module itself (nsrsqlrc.raw I believe)?

Hi!

NMM is 2.4.1.92

NW is 8.0.1.1.Build.132

SQL is 2008 R2

Windows is 2008 R2

In my test environment I am recovering to the same SQL server

In production I'm recovering to another SQL server, same versions

Thanks!

Hi Fabs,

Have you actually checked nsrsqlrc.raw and XBSA messages under /nsr/applogs on the SQL server?

Thank you,

Carlos

Thanks Carlos!

Same messages on nsrsqlrc.raw, but harder to read:

MSSQL:/nuodb%/files.1372884876.1372884883

29395 1372891516 0 0 0 264 2448 0 winsql (pid2448) NSR info 33 bsGetOpaqueList: returns success. 0

37946 1372891516 5 0 0 264 2448 0 winsql (pid2448) NSR critical 45 No logical file named %s in original database 1 23 9 nuosream1

29401 1372891516 5 0 0 264 2448 0 winsql (pid2448) NSR critical 57 Database file relocation list error. Actual file list is: 0

37947 1372891516 5 0 0 264 2448 0 winsql (pid2448) NSR critical 8     %s = %s 2 23 6 nuodb1 23 16 E:\DB\nuodb1.mdf

37947 1372891516 5 0 0 264 2448 0 winsql (pid2448) NSR critical 8     %s = %s 2 23 7 nuolog1 23 17 E:\DB\nuolog1.ldf

37947 1372891516 5 0 0 264 2448 0 winsql (pid2448) NSR critical 8     %s = %s 2 23 9 nuosream1 23 16 E:\DB\nuodb.DATA

43709 1372891517 1 0 0 264 2448 0 winsql (pid2448) NSR notice 13 Stop time: %s 1 35 25 Wed Jul 03 15:45:17 2013

xbsa.messages : 0 bytes

Cheers!

You have to render the log.

To do it open CMD and go to the C:\Prgram Files\Legato\nsr\applogs path (r wherever you have NMM installed)

Then run:

nsr_render_log nsrsqlrc.raw > nsrsqlrc.log

I'm sure now nsrsqlrc.log looks much nicer

If you get the same messages, with no further info, when starting the restore set Debug=3 and then render the log again.

Thank you,

Carlos

FabsNUO wrote: In my test environment I am recovering to the same SQL server In production I'm recovering to another SQL server, same versions

And the error you reported you get in test or prod env (or both)?  If prod only, I would argue this is most likely due to remote access permissions.

In both, prod and testing

:-/

Try

Stop nsr services on both NW server and client

Rename /nsr/tmp folders (and nsr/res/jobsdb on the server only)

Restart nsr services

Or

The following command syntax can be used for the sql recover.  This will perform a Copy Restore:

nsrsqlrc -s NetWorker_server_name -c source_client

-d MSSQL:CopyOfProject

-C "Project_Data=C:\RelocationPath\CopyofProject_Data.mdF,

Project_Data2=C:\RelocationPath\CopyofProject_Data2.ndF,...,

Project_Log=C:\Relocation\Path\Project_Log.ldF"  MSSQL:Project

NOTES:

1. If the "Relocation path" includes spaces then it needs to be put in single quotes:  e.g. 'c:\program files\data'

The complete -C string still requires double quotes.

2. The C:\Relocation\path should alre

Hi!

I get the same error for both options,

37946:(pid 2996):No logical file named nuosream1 in original database

When I query the database for files:

Thanks !