Original records were on a DDboost device and expired some month ago but seems that doesn't switch to cloned instance.
I tried also browsing the same instance on anoth MSSQL server that uses a newer version of Networker agent and NMM module: it has the same behavious, I can browse the same date range.
If you do mminfo for the records, what do you see? In theory, you should only see records which are not on DD but on tape (I guess) - so which are not expired and belong to clone pool only. On the other hand in some version policies have changed so they are unique across so I'm not sure what mminfo will give you here, but if there is still reference to DD records that might explain why it might try to use those. In theory, marking such ssids suspect will make NW revert to clone instance automatically.
Maybe I have a similar problem because clone job has a flag only on full level threfore metadata save set were not cloned. I guess there's no way to restore MSSQL DB without these metadata. Is correct?
SQL Meta data / logical saveset is created per backup, for example when we take SQL instance level backup of 20 DB’s (database is considered as a component) then we will create 20 entries for actual database backup and 1 extra entry for this logical/Meta data.
To browse / restore the SQL instances data from NW Server this SQL meta savest is very much needed. I think you should be able to restore using command line. But, this needs more hands on of MMINFO and NSRINFO to locate the actual backup.
ble1
4 Operator
•
14.4K Posts
0
September 19th, 2016 01:00
If it is there and if original records is gone, it will automatically switch to cloned instance.
Sbisolo
8 Posts
0
September 19th, 2016 02:00
Original records were on a DDboost device and expired some month ago but seems that doesn't switch to cloned instance.
I tried also browsing the same instance on anoth MSSQL server that uses a newer version of Networker agent and NMM module: it has the same behavious, I can browse the same date range.
ble1
4 Operator
•
14.4K Posts
0
September 19th, 2016 03:00
If you do mminfo for the records, what do you see? In theory, you should only see records which are not on DD but on tape (I guess) - so which are not expired and belong to clone pool only. On the other hand in some version policies have changed so they are unique across so I'm not sure what mminfo will give you here, but if there is still reference to DD records that might explain why it might try to use those. In theory, marking such ssids suspect will make NW revert to clone instance automatically.
Sbisolo
8 Posts
0
September 19th, 2016 04:00
I found this old thread: MSSQL Copy Restore from a clone pool
Maybe I have a similar problem because clone job has a flag only on full level threfore metadata save set were not cloned. I guess there's no way to restore MSSQL DB without these metadata. Is correct?
ble1
4 Operator
•
14.4K Posts
0
September 19th, 2016 07:00
I'm not sure which level metadata is, but you need all.
Sbisolo
8 Posts
0
September 20th, 2016 01:00
I did it: I executed the restore using command line (nsrsqlrc)
ElanC
53 Posts
0
October 31st, 2016 03:00
SQL Meta data / logical saveset is created per backup, for example when we take SQL instance level backup of 20 DB’s (database is considered as a component) then we will create 20 entries for actual database backup and 1 extra entry for this logical/Meta data.
To browse / restore the SQL instances data from NW Server this SQL meta savest is very much needed. I think you should be able to restore using command line. But, this needs more hands on of MMINFO and NSRINFO to locate the actual backup.
Hope this helps!!