"Postpone creation" function for SLP disappears after setting

[MasterBlaster]

Hi,

First I would like to thank you all for this forum: you saved my day so many times during last years!

This is however my first post, and it's regarding an odd behaviour of SLP definition and processing for wich I haven't found any related report.

As many other customers I'm using NetBackup v 7.7.2 on a Windows Server 2008 R2 cluster environment (as Master) with two Windows Server 2008 R2 hosts as Media and a third Windows Server 2012 ad another Media with dedicated backup pools.

Associated with the two "main" Media Servers are two MSDP disk pool sized about 20TB each, serving as a temporary stage area (from a minumum of 3 to a maximum of 8 days) before defined SLPs duplicate the backup images to tape for the remaining retention periods.

Almost all SLPs are responsible for a second duplication to a separate tape pool for each backup image, in order to copy data for Disaster Recovery purpose.

So the workflow should run like that:

- Take the backup image and write it to MSDP pool with retention time X => COPY1

- Immediately after that, as per SLP window, duplicate the backup image to the DR tape pool with retention time Z (tapes are automatically counted and ejected during the next working day) => COPY3

- After time X, before primary copy expiration, duplicate the backup image to the PROD tape pool with retention time Z => COPY2

During the past few years (and incarnations) of NBU this strategy worked well, as intended: every SLP had the flag set on "Postpone creation of this copy until the source copy is about to expire" for every COPY2 duplication type.

Recently I noticed that all COPY2 duplication types, inside all defined SLP, had that flag unsetted.

Thinking of someone's misleading action, I personally flagged that option again (only for the COPY2 duplication job types).

After about ten minutes, I checked SLP definitions, and all those settings were gone... I repeated the "flag" operation again, and after some time the setting was gone again.

The worst thing is that this is not only a "display" issue, because SLP are not working as intended too: without the "Postpone creation of this copy until the source copy is about to expire" option, duplications for COPY2 starts in conjunction with duplications for COPY3, immediately after production of COPY1, resulting in higher SLP backlog and drives/tapes workload.

Attached is a screen of one of those odd-acting SLPs, with evidence on the option property that simply refuses to stay flagged...

Any suggestions?

Thanks again and sorry for my bad english ^^'

M.

[Marianne]

@MasterBlaster

There's absolutely nothing wrong with your English.

Thanks for a detailed description of your issue.

My guess is that nobody here has seen or experienced this issue, mainly because hardly anyone I know is using the 'postpone' function.

I am wondering if this issue is caused by the same Java bug as per this TN:

Unable to edit backup window on calendar based schedule in Java GUI 
https://www.veritas.com/support/en_US/article.000109333

[MasterBlaster]

Hi Marianne and thanks for the feedback, valuable as always :)

I seem to recall we've already experimented that inconsistence when editing the window of a calendar based schedule with Java GUI, maybe something like a couple of years ago, just after the 7.7.2 upgrade (that was solved with the EEB if I remember well).

By the way, I opened a case in the meanwhile because the disk pools were nearly saturated: I'll update the results as soon as I have some news.

Bye!

M.

[mph999]

You should have some news soon, as I was talking about this with the TSE who has the case.

What I would like to see, is what is happening with the NBDB, which is where the 'Deferred Duplication' setting is held.

What is needed

With the 'Postpone creation of this copy until until the source copy is about to expire'  (also known as Deferred duplication) NOT set for a SLP secondary operation, save the output of:

nbdb_unload c:\tmp\nbdb_output_before    <<<< output should end up in this dir

Next, set the 'Postpone creation of this copy until until the source copy is about to expire'  feature and if possible grab a screen shot of this.

Immediately run:

nbdb_unload c:\tmp\nbdb_output_deferred_set

Wait the required time for the issue to occur and then run this command:

nbdb_unload c:\tmp\nbdb_output_after

This should create three dirs, with three nbdb_unloads, which will show what is hapening in the DB during the issue.