BE 9.1 not using all the tapes - Veritas Backup Exec

This is a discussion on BE 9.1 not using all the tapes - Veritas Backup Exec ; I'm having some problems understanding how Backupexec 9.1 for Netware chooses the tapes it uses for backups. I currently run incremental backups on five Netware 6 servers during the week and a full backup of them on the weekends. I ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: BE 9.1 not using all the tapes

  1. BE 9.1 not using all the tapes

    I'm having some problems understanding how Backupexec 9.1 for Netware chooses the tapes it uses for backups. I currently run incremental backups on five Netware 6 servers during the week and a full backup of them on the weekends. I am running the jobs using scheduled jobs and policies. I have an HP SureStore DAT 40x6 robot with 5 slots dedicated to tapes and 1 dedicated to the cleaning cartridge. I use Maxell HS-4\150s DDS4 tapes which have a 20 GB capacity. The tape drive has hardware compression turned on which, according to HP's manual, usually results in a 2:1 compression.

    Lately when I arrive Monday mornings I get an error from the BE Administration Console asking for blank or overwritable media to do the last full backup job. I cancel that job and check the tapes to see their capacity and get results such as this:

    Slot 1
    Bytes written: 92.4 MB
    Bytes read: 69.0 GB

    Slot 2
    Bytes written: 19.6
    Bytes read: 100.7

    Slot 3
    Bytes written: 1.6 GB
    Bytes read: 121.3 GB

    Slot 4
    Bytes written: 0
    Bytes read: 73.5 GB

    Slot 5
    Bytes written: 18.6 GB
    Bytes read: 68.1 GB

    As you can see there's plenty of space available, not to mention one tape that hasn't even been touched. There seems to consitently be one slot that is not written to for full backups. Usually it is slot 3 but this time it was slot 4. I checked HP's documentation and it seems like they start numbering slots with #1 and not #0, as is printed on the magazine and the LCD display on the robot. In addition I put the tape for the daily incrementals in slot #1, so if it actually started numbering with #0 the dailies would probably produce errors.

    Every time I put in a set of tapes for backup I first Inventory them and then perform a quick erase on them. From what I read recently that should put the tapes in the Scratch System Media category, and thereby fair game for use. What am I doing wrong or missing?

    Matthew

  2. Re: BE 9.1 not using all the tapes

    Hi Matthew,

    I'm interested in what anyone else has to say regarding this as well.

    We have a similar problem with our Compaq SSL2020 tape library. We have to perform a scan and then erase all tapes going into the library every day or else the job will stop part way through asking for an empty tape to be imported. At that stage if we do a scan and then clear the alert the job will usually restart and continue on.

    There seems to be a lot of room for improvement in Veritas' handling of media etc. For the life of me I cannot understand why I cannot do a quick erase on a number of tapes (BENW v9.1) without being prompted, get the tapes erased AND the catalogue updated. If I have erased the tape then what use is a catalogue entry that refers to a non-existent tape. There are a number of other meida issues that also get in the way - BENW says media is in the library when it is not, media that BENW says has not been written to in the Media Stats but the job log says it has x MB written to it etc etc.

    Terry Broad


    >>> Matthew Swenson 05/Dec/2003 07:15:26 >>>

    I'm having some problems understanding how Backupexec 9.1 for Netware chooses the tapes it uses for backups. I currently run incremental backups on five Netware 6 servers during the week and a full backup of them on the weekends. I am running the jobs using scheduled jobs and policies. I have an HP SureStore DAT 40x6 robot with 5 slots dedicated to tapes and 1 dedicated to the cleaning cartridge. I use Maxell HS-4\150s DDS4 tapes which have a 20 GB capacity. The tape drive has hardware compression turned on which, according to HP's manual, usually results in a 2:1 compression.

    Lately when I arrive Monday mornings I get an error from the BE Administration Console asking for blank or overwritable media to do the last full backup job. I cancel that job and check the tapes to see their capacity and get results such as this:

    Slot 1
    Bytes written: 92.4 MB
    Bytes read: 69.0 GB

    Slot 2
    Bytes written: 19.6
    Bytes read: 100.7

    Slot 3
    Bytes written: 1.6 GB
    Bytes read: 121.3 GB

    Slot 4
    Bytes written: 0
    Bytes read: 73.5 GB

    Slot 5
    Bytes written: 18.6 GB
    Bytes read: 68.1 GB

    As you can see there's plenty of space available, not to mention one tape that hasn't even been touched. There seems to consitently be one slot that is not written to for full backups. Usually it is slot 3 but this time it was slot 4. I checked HP's documentation and it seems like they start numbering slots with #1 and not #0, as is printed on the magazine and the LCD display on the robot. In addition I put the tape for the daily incrementals in slot #1, so if it actually started numbering with #0 the dailies would probably produce errors.

    Every time I put in a set of tapes for backup I first Inventory them and then perform a quick erase on them. From what I read recently that should put the tapes in the Scratch System Media category, and thereby fair game for use. What am I doing wrong or missing?

    Matthew



  3. Re: BE 9.1 not using all the tapes


    "Matthew Swenson" wrote in message
    news:3fcf879e@ROSASTDMZ05....
    > I'm having some problems understanding how Backupexec 9.1 for Netware

    chooses the tapes it uses for backups. I currently run incremental backups
    on five Netware 6 servers during the week and a full backup of them on the
    weekends. I am running the jobs using scheduled jobs and policies. I have
    an HP SureStore DAT 40x6 robot with 5 slots dedicated to tapes and 1
    dedicated to the cleaning cartridge. I use Maxell HS-4\150s DDS4 tapes
    which have a 20 GB capacity. The tape drive has hardware compression turned
    on which, according to HP's manual, usually results in a 2:1 compression.
    >
    > Lately when I arrive Monday mornings I get an error from the BE

    Administration Console asking for blank or overwritable media to do the last
    full backup job. I cancel that job and check the tapes to see their
    capacity and get results such as this:
    >
    > Slot 1
    > Bytes written: 92.4 MB
    > Bytes read: 69.0 GB
    >
    > Slot 2
    > Bytes written: 19.6
    > Bytes read: 100.7
    >
    > Slot 3
    > Bytes written: 1.6 GB
    > Bytes read: 121.3 GB
    >
    > Slot 4
    > Bytes written: 0
    > Bytes read: 73.5 GB
    >
    > Slot 5
    > Bytes written: 18.6 GB
    > Bytes read: 68.1 GB
    >
    > As you can see there's plenty of space available, not to mention one tape

    that hasn't even been touched. There seems to consitently be one slot that
    is not written to for full backups. Usually it is slot 3 but this time it
    was slot 4. I checked HP's documentation and it seems like they start
    numbering slots with #1 and not #0, as is printed on the magazine and the
    LCD display on the robot. In addition I put the tape for the daily
    incrementals in slot #1, so if it actually started numbering with #0 the
    dailies would probably produce errors.
    >
    > Every time I put in a set of tapes for backup I first Inventory them and

    then perform a quick erase on them. From what I read recently that should
    put the tapes in the Scratch System Media category, and thereby fair game
    for use. What am I doing wrong or missing?
    >
    > Matthew


    You need to check to make sure that:

    a) You use "Overwrite" rather than "Append" since append may result in
    addition too much for the tape to handle.

    b) If you are using media rotation, is it possible that the media has a
    protection date (i.e. it has not expired so overwriting is prohibited).

    I find myself using partition rather than media pool method. This way I can
    dedicate certain slots for certain day so I never have a question as to what
    tape is in my slot X.

    By the way, don't believe the 2:1 compression. That is the ideal (i.e. 50%
    of the original size). But if your files consist of many executables, dlls,
    digital music, you can forget that compression rate since those files are
    already compressed. You'd be lucky if you can get 1.2 : 1..



  4. Re: BE 9.1 not using all the tapes

    Thanks for the tip. I'll do some reading on the changing that setting from
    "append" to "overwrite."

    We are using a media rotation. The tapes have a media protection date of 3
    weeks after last written to. But shouldn't that date or restriction be
    removed when I erase the tapes?

    Matthew

    "Raoul Watson" wrote in message
    news:3fd01a8e@ROSASTDMZ05....W
    >
    > "Matthew Swenson" wrote in message
    > news:3fcf879e@ROSASTDMZ05....
    > > I'm having some problems understanding how Backupexec 9.1 for Netware

    > chooses the tapes it uses for backups. I currently run incremental

    backups
    > on five Netware 6 servers during the week and a full backup of them on the
    > weekends. I am running the jobs using scheduled jobs and policies. I

    have
    > an HP SureStore DAT 40x6 robot with 5 slots dedicated to tapes and 1
    > dedicated to the cleaning cartridge. I use Maxell HS-4\150s DDS4 tapes
    > which have a 20 GB capacity. The tape drive has hardware compression

    turned
    > on which, according to HP's manual, usually results in a 2:1 compression.
    > >
    > > Lately when I arrive Monday mornings I get an error from the BE

    > Administration Console asking for blank or overwritable media to do the

    last
    > full backup job. I cancel that job and check the tapes to see their
    > capacity and get results such as this:
    > >
    > > Slot 1
    > > Bytes written: 92.4 MB
    > > Bytes read: 69.0 GB
    > >
    > > Slot 2
    > > Bytes written: 19.6
    > > Bytes read: 100.7
    > >
    > > Slot 3
    > > Bytes written: 1.6 GB
    > > Bytes read: 121.3 GB
    > >
    > > Slot 4
    > > Bytes written: 0
    > > Bytes read: 73.5 GB
    > >
    > > Slot 5
    > > Bytes written: 18.6 GB
    > > Bytes read: 68.1 GB
    > >
    > > As you can see there's plenty of space available, not to mention one

    tape
    > that hasn't even been touched. There seems to consitently be one slot

    that
    > is not written to for full backups. Usually it is slot 3 but this time it
    > was slot 4. I checked HP's documentation and it seems like they start
    > numbering slots with #1 and not #0, as is printed on the magazine and the
    > LCD display on the robot. In addition I put the tape for the daily
    > incrementals in slot #1, so if it actually started numbering with #0 the
    > dailies would probably produce errors.
    > >
    > > Every time I put in a set of tapes for backup I first Inventory them and

    > then perform a quick erase on them. From what I read recently that should
    > put the tapes in the Scratch System Media category, and thereby fair game
    > for use. What am I doing wrong or missing?
    > >
    > > Matthew

    >
    > You need to check to make sure that:
    >
    > a) You use "Overwrite" rather than "Append" since append may result in
    > addition too much for the tape to handle.
    >
    > b) If you are using media rotation, is it possible that the media has a
    > protection date (i.e. it has not expired so overwriting is prohibited).
    >
    > I find myself using partition rather than media pool method. This way I

    can
    > dedicate certain slots for certain day so I never have a question as to

    what
    > tape is in my slot X.
    >
    > By the way, don't believe the 2:1 compression. That is the ideal (i.e. 50%
    > of the original size). But if your files consist of many executables,

    dlls,
    > digital music, you can forget that compression rate since those files are
    > already compressed. You'd be lucky if you can get 1.2 : 1..
    >
    >




+ Reply to Thread