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