Forum Discussion

mrinella's avatar
mrinella
Level 3
15 years ago

tapes manually put into one pool, but being reassigned to scratch later

Hi, using bar code rules, I am manually assigning some tapes to a particular pool when they are being loaded into my library.  That is working fine, but the next morning, all of the tapes in that pool...
  • Stumpr2's avatar
    15 years ago
    I accidently deleted the wrong thread.

    OK, There is a department called "stingy" that buys a bunch of tapes and does not want to share them with the other departments. Create a volume pool called stingy and a barcode rule to place all of the stingy tapes into the stingy volume pool when they are first injected into the library.Now create the stingy netbackup policies to use the stingy volume pool. When a backup runs it will pull a tape from the stingy pool and write to it. Sometime later all images written to the tape will expire. The tape will become  unassigned and will remain in the stingy pool for future use. At no time in this tapes lifetime will it ever be a member of the scratch pool.

    One day all the stingy tapes have been used and there are no more tapes available in the stingy pool. Netbackup will pull a tape from scratch and place it into the stingy volume pool. This tape is written to but eventually all images will expire and the tape will become unassigned. A decision needs to be made to either keep the tape in the stingy volume pool or to put it back into the scratch pool. Since this tape is not an original "stingy" tape then it should be placed back into the scatch pool. The following entry will accomplish that task.

    RETURN_UNASSIGNED_MEDIA_TO_SCRATCH_POOL="yes"

    Now it seems that the use of the string RETURN_UNASSIGNED_MEDIA_TO_SCRATCH_POOL effects the first scenario tapes? I don't doubt what you are seeing. I would follow Judy's advise and set the value of the string to "no".
    It currently is set to "yes" unless you actively change it to "no".

    DOCUMENTATION: Certain bp.conf entries, vm.conf entries, and touch files are now set using nbemmcmd in VERITAS NetBackup (tm) 6.0.
    http://support.veritas.com/docs/278996

    To see which settings are now configured using nbemmcmd run the following command:
    # cd /usr/openv/netbackup/bin/admincmd
    # ./nbemmcmd -listsettings -machinename <media server>
    The following configuration settings were found:
    ALLOW_MULTIPLE_RETENTIONS_PER_MEDIA="no"
    DISABLE_DISK_STU_JOB_THROTTLING="no"
    DISABLE_STANDALONE_DRIVE_EXTENSIONS="no"
    MEDIA_REQUEST_DELAY="0"
    MUST_USE_LOCAL_DRIVE="no"
    NON_ROBOTIC_MEDIA_ID_PREFIX="A"
    MAX_REALLOC_TRIES="1000"
    DISALLOW_NONNDMP_ON_NDMP_DRIVE="no"
    DO_NOT_EJECT_STANDALONE="yes"
    DONT_USE_SLAVE="no"
    DRIVE_ERROR_THRESHOLD="2"
    MEDIA_ERROR_THRESHOLD="2"
    TIME_WINDOW="12"
    RETURN_UNASSIGNED_MEDIA_TO_SCRATCH_POOL="yes"
    VAULT_CLEAR_MEDIA_DESC="no"


    These values can be changed using either the Host Properties in the NetBackup Administration Console or the nbemmcmd -changesetting <options> -machinename <media_server> command. Setting these options in the bp.conf, vm.conf or by creating touch files will have no effect.