How do you order execution of NEW_STREAMS in 6.5?

[BrianK_Sun]

Hi all,

Got an interesting one here.

Have a customer that upgraded from 6.0 to 6.5, and they noticed that the execution behavior of each new stream in the policy changed.   They have a Solaris standard policy with about 9 NEW_STREAMS each picking up an individual path.  In previous versions, they noticed Netbackup would create a parent job and then one child job per stream (as expected), order the job ids  sequentially based on their position in the policy definition (as expected), and then proceed to execute them in that exact same order (as expected). That was working fine.

Now, 6.5 does everything the same way, except that it randomly executes the streams. 1->3->7->2->6 , etc. It does not adhere to any order. I've created a test policy, run it and confirmed this.  It even orders the child job ids correctly all the time. It's just upon actually writing them to tape that it jumps around.

This is unacceptable to them as they need to go in a predictable, consistent order.
They need the first defined stream to write to the tape in entirety, followed by the next defined stream writing to same tape in entirety, etc.

Does anyone know how to enforce the stream execution order?

Symantec has suggested bp_endnotify scripts to tell the parent which stream's job id to kick off next.
The information was pretty vague, and I have a follow-up question into them.

Thanks,

B

[Patrick_Whelan_]

If there is actually a legitimate reason for the sequence, then create seperate policies and give them the corresponding priorities.

[Omar_Villa]

yeah but based on the 6.0 behavior and now this one with 6.5, I think this can be a bug and should ask Symantec to go deepth or at least tell you why of the change, because the answer they give you are not acceptable, if something was working fine and after a patch/upgrade starts failing is because they did something wrong under the development process or maybe they change it to be randomly based on a new algorithm or somthing they havent release yet.

please let us know if you get something new about this.

regards

[J_H_Is_gone]

what I had always been told is the job is based on if one failed or not.  or on which one has NOT been backed up the longest.

job 1,2,3,4

job 2 fails tongith

tomorrow

job 2,1,3,4

at anypoint did jobs fail?

[Dion]

Just a quick Q

Why are you running multiple streams if you want each to run sequentially.  Wouldn't you normally run multiple streams to have the ability to run these streams at the same time, in which case, the order should not matter?  If not, a normal policy with the source folders should suffice.

[Patrick_Whelan_]

Good answer, I wish I'd thought of it.

[BrianK_Sun]

First, thanks for the replies.

The reason they run multiple streams is that each discrete job kicked off by the stream will write its own pre-amble/header on the tape.  This facilitates them locating the data in their custom "fall-back" DR policy.
If it was a simple  sequential include list, you'd get one huge block of data on tape.
I had the same question- why go multi-streaming if the goal is sequential.  They seemed mutually exclusive.
But when you add in this piece of info, it makes sense.

I agree that this is a major change in functionality and could be borderline  considered a degradation.
Certainly Symantec should answer why the change?

-Brian

[Patrick_Whelan_]

Ok, sounds interesting. How do they use this preamble/header? Do they use tar or something to search through the tape? I'm just curious, maybe it's something that could be used by others. If enough people use the idea it could help create pressure on V/S to incorporate it into NetBackup.

[BrianK_Sun]

Yes, they're using a combination of mt to position and tar to read.