1.7K Posts

November 15th, 2012 06:00

Hi there,

Is it me or you left a blank space between the = and the T

Variable has no blank spaces, so it should be:

NSR_SKIP_SIMPLE_DB=TRUE

Thank you.

Carlos.

1 Rookie

 • 

9 Posts

November 15th, 2012 06:00

Hello Carlos,

no there is no blank between, the wizard created it

But it´s funny why are the simple DB not skipped?

Regards Sven

Von: CarlosRojas

Gesendet: Donnerstag, 15. November 2012 15:49

An: Sven Heuter

Betreff: New message: "Skip Simple Database DB - NMM 2.4"

EMC Community Network

Re: Skip Simple Database DB - NMM 2.4

created by CarlosRojas in NetWorker Support Forum - View the full discussion

1.7K Posts

November 15th, 2012 07:00

Hi Sven,

I thought this was going to be an easy one

Then, if variable is ok, could you please share the nsrsqlsv.raw file so that we can take a look?

Thank you.

Carlos.

4 Operator

 • 

14.4K Posts

November 15th, 2012 12:00

palkhr wrote:

The skip functionality will work provided you configure the backups to run at the instance level not at db levels.Pls change the saveset name to instance level eg MSSQL: that should work

Doesn't first post say that is exactly what he is doing?

4 Operator

 • 

14.4K Posts

November 15th, 2012 13:00

Thanks!  Is this variable also present in NMSQL 5.2?

4 Operator

 • 

14.4K Posts

November 15th, 2012 13:00

NSR_SKIP_SIMPLE_DB=TRUE

Btw, where does this variable get set (if not using wizard)?  I was not aware of it, but I can see how handy it could be...

544 Posts

November 15th, 2012 19:00

Hi,

This application information has been added to NMM 2.4 , In the Wizard there is an option which is Skip simple recovery model databases during incremental backup . So when performing instance level backup. If this option is not selected when performing database level backup, the database is not skipped and the simple recovery model database is promoted to full backup. If it is selected or =TRUE , so the  simple database should be skipped.

I recommend you to open a service request with EMC as this may be a bug in NMM 2.4 or environmental problem/ limitation . Please update us for any progress.

Thanks,

Ahmed Bahaa

1.7K Posts

November 16th, 2012 00:00

Sven,

Before opening an SR could you please share the nsrsqlsv.log file to take a look?

Thank you.

Carlos.

1.7K Posts

November 16th, 2012 01:00

Hi Sven,

I guess these are SharePoint DB's, correct?

In that case I was thinking about the known conflict between VDI and VSS.

When you do a backup with VSS (nsrsnap_vss_save) as part of the SharePoint farm backup, then VDI will NOT recognize that backup as full, as unless VDI takes a full backup, VDI won't "find" a previous full hence will promote the DB's to full.

VDI needs to run a full backup in order to perform incremental. All has to do with the archive bit I believe.

So the test I would suggest, before changing the schedules for your backups would be to tun a full VDI backup (nsrsqlsave) for one of the non system DB, then do an incremental and this should work.

If this still promotes the backup to full then we would need to investigate further.

Thank you.

Carlos.

1 Rookie

 • 

9 Posts

November 16th, 2012 01:00

Hello Carlos,

attached you will find the log messages from the last run. I hope it´s enough.

@ the other followers

the client was configured with the wizard. You can hook on " Skip simple recovery model databases during incremental backup" after that you will find in the client configuration under the Application infromation field the entry NSR_SKIP_SIMPLE_DB=TRUE

1 Attachment

1 Rookie

 • 

9 Posts

November 16th, 2012 03:00

Hi, we already do a VDI Backup (Full) in another Group as you can see.

* ul-spqsql01:savefs savefs ul-spqsql01: succeeded.

* ul-spqsql01:MSSQL: Suppressed 121 bytes of output.

* ul-spqsql01:MSSQL:             NSR_BACKUP_LEVEL: full;

* ul-spqsql01:MSSQL:                   NSR_CLIENT: ul-spqsql01;

* ul-spqsql01:MSSQL:            NSR_DIRECT_ACCESS: No;

* ul-spqsql01:MSSQL:                    NSR_GROUP: SQL_1;

* ul-spqsql01:MSSQL:             NSR_SAVESET_NAME: "MSSQL:";

* ul-spqsql01:MSSQL:                   NSR_SERVER: deulmnwserver01.de.teva.corp;

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of QSP_Repository succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPDiagSPQ succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Config succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_Apotheke succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_BT succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_BTtest succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_CA succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_MYSITE_01 succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_MYSITE_02 succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_SHAREPOINT-QA_01 succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_SHAREPOINT-QA_02 succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_Content_SSP1 succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_ReportServer succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_ReportServerTempDB succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_SharedServices1_DB succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_SharedServices1_Search_DB succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of SPQ_WSS_Search succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of WSS_Content_EFB succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of WSS_Content_India succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of WSS_Content_Literature succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of WSS_Content_Migration succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of WSS_Content_VV succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of WSS_Content_ratiopharm succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of master succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of model succeeded.

* ul-spqsql01:MSSQL: 53085:(pid 7600):Backing up of msdb succeeded.

  ul-spqsql01: MSSQL:             level=full,    116 GB 01:36:00     26 file(s)

* ul-spqsql01:MSSQL: completed savetime=1353006682

* ul-spqsql01:MSSQL: 43709:(pid 7600):Stop time: Thu Nov 15 21:47:31 2012

* ul-spqsql01:MSSQL:

  deulmnwserver01.de.teva.corp: index:ul-spqsql01 level=full, 1355 KB 00:00:15   1250 files

* ul-spqsql01:index completed savetime=1353012465

1.7K Posts

November 16th, 2012 03:00

Hi Sven,

Sorry to insist but, are you sure there is no VSS backup in between the full VDI backup and the incremental VDI backup?

I see that full was run on

Thu Nov 15 21:11:31 2012, and incremental on Fri Nov 16 07:08:46 2012

Just want to make sure, otherwise this could be an indexing issue or even a media DB issue.

If possible please set the backup command to:

nsrsqlsv.exe -D3 -A ul-spqsql01

Then please share the nsrsqlsv.log again, after running a full and immediately an incremental. You can test only with one DB instead of all of them.

By the way, does the backup command include a "-a" or "-A"?

I also saw you are using NMM 2.4.0.368, could you please upgrade to NMM 2.4 375? Build 375 is the GA version, and I'm afraid you are running the RA version.

Thank you.

Carlos.

February 21st, 2013 06:00

Hi Sven,

You need to put NSR_SKIP_SIMPLE_DB=TRUE in the application information of all client definitions for that client in the first line. The problem is that the information is not passed to the command nsrsqlsv at start time, but the nsrsqlsv command checks the client definition on the server after it is started. If the first client definition it receives from the server doesn't contain this variable, it will not skip the databases in simple mode.

This is a bug too me, because they should query the group together with the client name to obtain the correct client definition.

If I have time, I will open a SR for this.

Hope this helps

Kind rgards

Felix

1.7K Posts

February 27th, 2013 03:00

Hi Sven,

Felix is right. This seems to be related to NW143793.

Please follow the steps described by Felix and if it doesn't work either let us know or open an SR with reference to NW143793.

Thank you.

Carlos

No Events found!

Top