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...
Thanks again and sorry for my bad english ^^'
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:
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.
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.