Hi,

You can increase the target sessions value for the drive.  If, for example,  you have a savegrp parallelism of 6 for the group backing up to the pool and the target sessions is set to 7 for the tape drive, then there will never be too many streams for the device and it will not move onto the other tape until the first tape is full.

-Bobby

You can increase the target sessions on your devices so that backup streams will continue to go to one drive until that value is reached after which it will then use an additional drive.

osk,

David and coganb are correct. Increasing the sessions will help resolve this issue.

It may take a couple of adjusments to get it to the correct level, so dpn't give up if it doesn't work the first time through.

Mark

ok thank you guys!

The only thing that may trip you up is if you have more sessions than your target session which will mean the next tape will get mounted in another drive.  If that may happen it would be necessary to take a broader overview of your configuration to decide the best way to tackle this.

How about modifying your pool properties called "max parallelism"

Man page on nsr_pool explains this parameter:

max parallelism (read/write, hidden)

This attribute can be used to impose an upper limit for the number of parallel sessions saving to a media belonging to the pool. Fewer parallel save session written to media reduces the time required to recover data from a saveset. Value of zero imposes no limit on number of parallel save sessions written to media belonging to this pool.

So...  if I set the device target session=12 and the pool max parallelism=12, then networker will only use one tape at a time from that pool.

Never tried it... but I think it sounds right ... 

The Max Parallelism attribute is there to prevent Networker multiplexing too many savesets to one tape (and thus taking longer to read data in the event of recovery), probably not what we want in this case.  The target sessions is the minimum number of data streams (savesets) sent to the device before diverting new streams to another device.

In the suggestion you make Wallace, the first device will accept savestreams until it is receiving 12 streams of data; at that point we are at our target session value so Networker will choose to direct the 13th stream of data to another device (if one is available).  We have also reached the max_parallelism limit so that parameter would also act as a limiting factor, the difference being that when all the devices have reached their target session value any new savestreams will be shared out amongst the drives (assuming we haven't also set the max_parallelism), so the amount of savesets to the device can exceed the target sessions value (but only when all devices in the system have reached their target session value).  In the event of the max_parallelism being set, when all devices reach that limit savesets will queue until other savesets complete backing up.

Hypothetically, you got a group that has x number of savestreams to backup.

So savegrp starts, which tells nsrd to choose the pool with the max parallelism=12.

There is a tape mount request for that pool.

The tape is mounted.

Savestreams are channeled through the nsrmmd to the tape drive.  The initial number of savestreams channeled cannot be higher than the device target sessions value, and also cannot be higher than the pool's max parallelism.

If all the savestreams are processed at this point, then the backups will only use one tape a a time.

If target sessions=max parallelism, then if there are more streams, then they have to wait because max parallelism prevents any new backup savesets from being processed.  Because of this limit, there is no need for NetWorker to load another tape.  Again, only one tape will be used at any time.

Using my example of target sessions=max parallelism=12, the 13th stream cannot be processed on that pool because only 12 streams are allowed because of max parallelism.

Now I agree that this is not the ideal solution because you are hard coding the target sessions on the drive, and this is not necessarily optimal in general.

The only other alternative is to change the pool properties so that it only can use one backup device; then this ensures that only one tape can be loaded.  However this can also cause problems if other pools are allowed to use that same drive too.

Hi guys

Well today the backup ran and networker used only one volume of the two in the pool. Still i noticed that it used

the volume that was empty, and not the one that has information on it.(it's at 75% of use). Why networker chose the empty

volume(this volume is newer than the other one) instead of the one that still had space on it for doing the backup?

thanks!

Networker will use appendable volumes in the same pool first, if I remember correctly if there are several appendable volumes available it will choose the one with the lowest mounts value (I think there is a knowledge base article on this so you could try doing a search on it as I don't have access).  Since the empty tape has been labelled into the pool and is thus appendable it can also be mounted.