MSSQL Copy Restore from a clone pool

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility.  Questions written to the users' own "Discussions" space don't get the same amount of attention and can go unanswered for a long time.

You can do so by selecting "Move" under ACTIONS along the upper-right.  Then search for and select: "NetWorker Support Forum".

NetWorker Support Forum

Hm, I'm not clear as to what you are doing.  First, how was initial cloning done?  If using DDBoost, then I assume you used NMM.  If using NW, then I assume older NMSQL.  In both cases, you should had browsable indices.  Or is it that retention for the piece has passed?  If so, and since you use DD, I wonder if you were successful in scanner at all because every 23h NW is doing mdb cleanup and that will also remove ssids from devices (and when they get removed from DD depends on DD setup). But lets assume for a moment that is in place (which is kind of big assumption). You did -S with scanner so natural question is if you did right scan - meaning, how did you know SSID in the first place?  I assume you will say from mdb which confuses me since mdb is cleaned up regulary, but let's assume that you hit right spot.  In that case, next question is did you scan both SSIDs which do get associated with SQL saveset?  Because each SQL save set has 2 created savesets where one is sort of metadata and required for restores as well.

Yes, you can't ssid restore it.  Question:  can you list MSSQL savesets you believe are the ones you need?  Then check for them in mdb.  For example (this is just example on my end to get you an idea):

# mminfo -q group= -t today -r name,nsavetime,ssflags,sumflags,clflags,ssbrowse,ssretent,clretent,nsavetime,client name                            save time ssflags fl clflg browse retent  clretent   save time client MSSQL$TST_DEFAULT:T01TIS_SimpleDemo_Workflow 1387531105 vF cb  12/29/13 12/29/13 12/29/13 1387531105 foo MSSQL$TST_DEFAULT:T01TIS_SimpleDemo_Workflow 1387531142 vF cb  12/29/13 12/29/13 12/29/13 1387531142 foo

I'm not sure what kind of identifier you will use in your case (group, pool, client, whatever) for query, but you will know this the best. What I did was just to query one test group for one DB I knew it run this morning.  Let's imagine this was 1 year ago and I used different -t.  Hopefully, after scanner command, your browse, retention and clretent are in future.  Now, check index in following way:

# nsrinfo -n mssql -t 1387531105 foo scanning client `foo' for savetime 1387531105(Fri Dec 20 10:18:25 2013) from the mssql namespace MSSQL$TST_DEFAULT:/BAR_SimpleDemo_Workflow MSSQL$TST_DEFAULT:/BAR_SimpleDemo_Workflow./PRIMARY MSSQL$TST_DEFAULT:/BAR_SimpleDemo_Workflow./PRIMARY./BAR_SimpleDemo_Workflow MSSQL$TST_DEFAULT:/BAR_SimpleDemo_Workflow./ MSSQL$TST_DEFAULT:/BAR_SimpleDemo_Workflow./PRIMARY./ MSSQL$TST_DEFAULT:/BAR_SimpleDemo_Workflow%/files.1387531105.1387531106 6 objects found # nsrinfo -n mssql -t 1387531142 foo scanning client `foo' for savetime 1387531142(Fri Dec 20 10:19:02 2013) from the mssql namespace MSSQL$TST_DEFAULT:/ MSSQL:$/ 2 objects found

First ssid is data one and second one is sort of meta data.  Now, since you are doing copy restore, I assume this goes to different machine too. There are three possibilities:

1) Your scanner action was not good.  That means that you didn't prepare saveset with nsrmm where you need to change flags like not recycled and similar - this is covered in KB

2) ssid is ok including flags and dates, but there is nothing in index - not sure why that would be the case, but try to scan it again - note that ssid flags and dates have to be ok and in future

3) you can see index with nsrinfo, but issue is that remote client (where copy DB is done) does not have permission to read those (for example, backup is done for SQL server A and you wish to restore it to SQL server B - in that case go to NMC and in remote access of server A client add server B - this will grant permissions to server B to browse index of server A and run restore)

My question exactly ...

Hi and thanks for a quick response.

Scenario is, I have a DD and NetWorker Server 7.6.5.7 with a few SNs.

The client was backed up with NMSQL 5.22 over a year ago. I later cloned the volume containing the SS to another ClonePool Volume with longer retention (on the same DD). The backup Volume does not exist anymore and the browse retention is long gone.

Regarding the Scanner command, I ran it agains all the SSID for this client, a certain date and the device holding the clonevolume. They all show as browsable in "Media > Save Sets" and the indexes are also visable in "Media > Indexes" (as stated before). But the client does not see them and I am not able to do a Save Set Restore for MSSQL save set, true ? (at least I have tried without success).

I also tried running "nsrck -L 7 -t savetime client_name" but it gave the error:

"...File index error: can't find index backups for 'client_name' on server 'nw_server' "

I am stuck and guess I need to escalate it to a EMC SR.

Ah wait, there is something else perhaps too (in theory at least, in real life I never tested it):

4) clone pool has store no index entries setting meaning it reads index from original record - I wonder how this works if original volume is gone and you wish to scan clone pool entry

It is a good question indeed.  I might get some free time to test this during the weekend as I'm interested in this myself.  I never had to wonder about this as I do not use clones with higher retention, but knowing this answer is beneficial for sure.

You should see 2 ssids and not just one.  You can easily verify this against current valid SQL backups.  Here is example of I have for DB backup:

# mminfo -q group=FOO -t today -r name,level,sumsize,ssflags,sumflags,clflags                                        name                            lvl   size ssflags fl clflg MSSQL$TST_DEFAULT:FOO_SimpleDemo_Workflow full 1754 KB vF cb MSSQL$TST_DEFAULT:FOO_SimpleDemo_Workflow incr 3 KB vF cb

The one which is incr is so called metadata ssid which is usually taken always at the end of the DB backup. Same applies to transaction logs - without it you won't be able to restore it for sure.

The SS's have a 'Clone Retention Time' of 7yrs forward (yr2020) in the CloneVolume. It's true that it's not possible to store the indexes for ClonePools and maybe that's the problem?

Could it be that I should have staged the SS's/Volume instead ? That the metadata SSID is missing and therfore unable to build the indexes ? I actually only see 1 SSID for each SS, not 2

But another funny thing is, I also have SS for this client in another BackupVolume and this CloneVolume, with status 'browsable' but the client does not see them.

Regarding permissions, I have given full permission everywhere for this client. It's not the original client, but a new one with same name, OS and SQL server running.

I have also tried directed Copy Restore on another client without success (full permissions given too).

'nsrinfo -n mssql -t savetime client' output was: '0 objects found' :/

BragiJon wrote: I have also tried directed Copy Restore on another client without success (full permissions given too). 'nsrinfo -n mssql -t savetime client' output was: '0 objects found' :/

If this is valid SQL client and valid savetime (and you run this with admin user) - then something is very wrong there.  In such case, you should get support to check it over webex and take further steps (I still believe/hope there is something obvious missed).