[Veritas-bu] Odd multiplexing result

Environment:      Solaris 2.5.1           (yeah, nearly antique)
            NetBackup 3.2
            STK 9714 DLT7000 library (4 drives, 60 slots)


I am just starting to use multiplexing for backups of 1 class, setting it
up as follows:

      1) Turned on the class attribute "Allow multiple data streams".
      2) Modified the class schedules to set "Maximum MPX per Drive" to 6.
      3) Modified the storage unit to enable MPX and set the maximum MPX
per drive to 6.
      4) In the NetBackup global attributes set "Maximum Jobs per Client"
to 6.

Currently I am using NetBackup to backup only file systems and directories
on this particular machine which are under Veritas HSM (Storage Migrator)
control or contain information relative to HSM. In this context there are 6
paths specified in the "Files" list for the class. These are

      /usr/openv/hsm/vault1         (directory)
      /export/home6                 (file system under HSM control)
      /usr/openv/hsm/vault2         (directory)
      /export/home7                 (file system under HSM control)
      /usr/openv/hsm/vault3         (directory)
      /export/home8                 (file system under HSM control)

I have not used the "NEW_STREAM" directive in the files list. The manual I
am reading indicates that the way I am doing this will result in 6 separate
data streams even without using the  "NEW_STREAM" directive. The job
reports after having run the backups last night support this contention.
There are 6 separate Job IDs from last night, as opposed to 1 Job ID from
before implementing multiplexing, and they all started at virtually the
same time, have overlapping run times, and wrote to the same volumes.

Even so, I have two questions for the NBU gurus in the audience:

1) This is probably very simple to answer and most likely not very
important. There are 6 separate Job IDs from the backup last night, 1 for
each of the paths specified in the files list. But they all have the same
Job PID number. The relationship is

      Job ID            Job PID     path

      1522        17711       /usr/openv/hsm/vault1
      1523        17711       /export/home6
      1524        17711       /usr/openv/hsm/vault2
      1525        17711       /export/home7
      1526        17711       /usr/openv/hsm/vault3
      1527        17711       /export/home8

     Why do they all have the same Job PID? Is it a single process
controlling all of the jobs?


2) This one I don't grok at all. Job ID 1523 failed last night, and there
are 2 relevant entries in the problems report listing. They are

      03:13:30    backup of client exited with status 41 (network
connection timed out)
      03:13:31    backup of client exited with status 196 (backup was not
attempted
                  because backup window closed)

In this environment, the NBU server is backing up local file
systems/directories, there is no network involved. Why should there be a
"network connection timeout"? Besides, another one of the file systems
being backed up started at the same time and ran even longer, finishing
successfully at 04:27. It did not experience a "network connection
timeout". I presume that the second message about the backup window being
closed was the result of a retry for this particular backup which failed.

A final point - I probably am going to use the "NEW_STREAM" directive in
the following manner:

      NEW_STREAM
      /usr/openv/hsm/vault1
      /usr/openv/hsm/vault2
      /usr/openv/hsm/vault3
      NEW_STREAM
      /export/home6
      NEW_STREAM
      /export/home7
      NEW_STREAM
      /export/home8

Is this a reasonable way to use it? The first 3 paths are directories on
the same file system, while the next 3 paths are all separate file
systems/devices.


Jeff Dykzeul
Raytheon Space and Airborne Systems