Performance limitation of BackupExec - Veritas Backup Exec

This is a discussion on Performance limitation of BackupExec - Veritas Backup Exec ; Is it possible to backup a remote server at the full speed of a DLT Drive or a SDLT Drive? The remote server is Proliant ML 530 with : - a smart 3200 raid controler (a ultra2 controler with 64 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Performance limitation of BackupExec

  1. Performance limitation of BackupExec

    Is it possible to backup a remote server at the full speed of a DLT
    Drive or a SDLT Drive?

    The remote server is Proliant ML 530 with :
    - a smart 3200 raid controler (a ultra2 controler with 64 Mo of
    cache)
    - 1Go ram
    - 1 PIII Xeon 800 Mhz
    - 1 Intel Gigabit Ethernet NIC
    2 Ultra3 9Go 10Krpm in miror for the vol sys:
    7 Ultra3 18Go 10Krpm in Raid5 for the others volumes
    Nw 4.11 with sp8a and accelerated agent

    The Backup server is Proliant ML 330G2 with :
    - 1 Ultra 160 controler for the disks
    - 1 Ultra-Wide controler for the DLT8000
    - 384 Mo ram
    - 1 PIII 1133 Mhz
    - 1 Intel Gigabit Ethernet NIC
    2 Ultra3 36Go 10Krpm in miror soft
    Nw 4.11 with sp8a
    BackupExec with the last patch

    I never haven't better performance than 280 MB/mn for the backup and 350
    MB/mn for the Verify (for the SYS volume) and 380 MB/mn for the backup
    and 510 MB/mn for the Verify (for a 4Gb file).

    The theorical throughput of the DLT8000 is 12MB/s (720MB/Mn)
    The theorical throughput of the Network is 120MB/s (7200MB/Mn)
    The theorical throughput of the remote server drives is 80MB/s
    (4800MB/Mn)

    Where is the bottleneck is it because of the TSA agents, the OS or
    BackupExec ?

    how-to increase the backup speed?

    Pascal



  2. Re: Performance limitation of BackupExec

    Pascal

    > Is it possible to backup a remote server at the full speed of a DLT
    > Drive or a SDLT Drive?


    It's virtually impossible to get the manufacturers stated maximums out of a
    tape drive.
    Specs issued by the manufacturer assuming that *all* conditions are
    absolutely *perfect* (much like car manufacturers quote fuel consumption,
    top speeds, etc..). Those type of maximum speeds are rarely (if ever)
    achieved because of the variety of things that can affect backups in a
    production environment.

    You could always try the Veritas performance tuning document
    (http://seer.support.veritas.com/docs/235036.htm).

    I'd be happy with the figures you're getting!

    Michael



  3. Re: Performance limitation of BackupExec

    Michael,

    OK but the backup speed is less than the half of the theorical speed.

    Do you know if the other users of BackupExec with DLT8000 (or other fast tape
    drives ) have the same performances?.

    For drive manufacturers, if the data stream is not sufficient, the drive start
    to write and stop and restart and so on.
    when it start to write, it repositionne the head, this type of operation reduce
    the life time of the drive and the tape.

    I have read "the performance tuning document", and use it to obtain this
    performance.

    I wish to increase the storage space on this server to 300GB or 400GB and
    backup it with a SDLT.
    If the Backup throughput is not better, it isn't possible to make a backup
    (with a verify) during the night.

    Pascal



    Michael wrote:

    > Pascal
    >
    > > Is it possible to backup a remote server at the full speed of a DLT
    > > Drive or a SDLT Drive?

    >
    > It's virtually impossible to get the manufacturers stated maximums out of a
    > tape drive.
    > Specs issued by the manufacturer assuming that *all* conditions are
    > absolutely *perfect* (much like car manufacturers quote fuel consumption,
    > top speeds, etc..). Those type of maximum speeds are rarely (if ever)
    > achieved because of the variety of things that can affect backups in a
    > production environment.
    >
    > You could always try the Veritas performance tuning document
    > (http://seer.support.veritas.com/docs/235036.htm).
    >
    > I'd be happy with the figures you're getting!
    >
    > Michael



  4. Re: Performance limitation of BackupExec

    Pascal

    > Do you know if the other users of BackupExec with DLT8000 (or other fast
    > tape drives ) have the same performances?.


    I have no idea whatsoever - I was just pointing out that drive manufacturers
    will quote whatever their best ever speed was, whether they get that speed
    20 times in a row, or once in 500 backups - just like car manufacturers -
    they want to sell you the product, and will test their product in the best
    circumstances possible.

    > For drive manufacturers, if the data stream is not sufficient, the drive

    start
    > to write and stop and restart and so on.
    > when it start to write, it repositionne the head, this type of operation

    reduce
    > the life time of the drive and the tape.


    Yes, I understand that - so you also need to look at the type of data that
    you're backing up, whether there's any anti-virus/OFM/compression running at
    the same time, the SCSI card & driver you're using, etc.... remember that
    your remote server backup will also be affected by your network/NIC
    limitiations.

    > I have read "the performance tuning document", and use it to obtain this
    > performance.


    Ok, have you benchmarked it against any other backup software?

    > I wish to increase the storage space on this server to 300GB or 400GB and
    > backup it with a SDLT.
    > If the Backup throughput is not better, it isn't possible to make a backup
    > (with a verify) during the night.


    Seriously, benchmark BE's performance against something like ArcServe - or
    try one of Veritas' other products, like NetBackup...it might be that you
    need a faster software solution, but do the testing first.

    Michael



  5. Re: Performance limitation of BackupExec


    Michael.

    For information, when I control the performance of the backup, I stop the
    anti-virus and I never use the Netware file compression on the file server.
    I have see on the HP web site this white paper :
    http://www.hp.com/products1/storage/...tperfpress.pdf

    Can you read the "Performance Tuning on Netware" chapter they have discover the
    same problem when they have tested the TLO in Netware environnement.

    What do you think of it ?

    Pascal



    Michael wrote:

    > Pascal
    >
    > > Do you know if the other users of BackupExec with DLT8000 (or other fast
    > > tape drives ) have the same performances?.

    >
    > I have no idea whatsoever - I was just pointing out that drive manufacturers
    > will quote whatever their best ever speed was, whether they get that speed
    > 20 times in a row, or once in 500 backups - just like car manufacturers -
    > they want to sell you the product, and will test their product in the best
    > circumstances possible.
    >
    > > For drive manufacturers, if the data stream is not sufficient, the drive

    > start
    > > to write and stop and restart and so on.
    > > when it start to write, it repositionne the head, this type of operation

    > reduce
    > > the life time of the drive and the tape.

    >
    > Yes, I understand that - so you also need to look at the type of data that
    > you're backing up, whether there's any anti-virus/OFM/compression running at
    > the same time, the SCSI card & driver you're using, etc.... remember that
    > your remote server backup will also be affected by your network/NIC
    > limitiations.
    >
    > > I have read "the performance tuning document", and use it to obtain this
    > > performance.

    >
    > Ok, have you benchmarked it against any other backup software?
    >
    > > I wish to increase the storage space on this server to 300GB or 400GB and
    > > backup it with a SDLT.
    > > If the Backup throughput is not better, it isn't possible to make a backup
    > > (with a verify) during the night.

    >
    > Seriously, benchmark BE's performance against something like ArcServe - or
    > try one of Veritas' other products, like NetBackup...it might be that you
    > need a faster software solution, but do the testing first.
    >
    > Michael



  6. Re: Performance limitation of BackupExec

    Pascal

    > For information, when I control the performance of the backup, I stop the
    > anti-virus and I never use the Netware file compression on the file

    server.
    > I have see on the HP web site this white paper :
    >

    http://www.hp.com/products1/storage/...m_tapedrives/u
    ltrium230/infolibrary/whitepapers/ultperfpress.pdf
    >
    > Can you read the "Performance Tuning on Netware" chapter they have

    discover the
    > same problem when they have tested the TLO in Netware environnement.
    > What do you think of it ?


    A *very* interesting document, thanks very much for that.

    Couple of paragraphs that really got my interest were:

    "Assuming a compression ratio of 2:1, these next generations of tape drives
    are capable of
    streaming data at up to 30 MB/sec (108 GB/Hr). The issue lies in whether the
    systems to
    which the tape drives are attached can supply data at this rate. Failure to
    do so can result
    in:
    Misled customer expectations. Longer than expected backup windows lead to
    less than
    desirable system availability at full performance levels.
    Potential reliability implications. Once a drive cannot sustain a transfer
    rate it goes into
    "re-positioning mode" which will cause multiple passes of the head over the
    media,
    therefore reducing media life and increasing mechanical wear."

    and...

    "The net result is that on any NetWare system there is a limit of around
    6mB/sec today using large
    file transfers."

    So, 360mb/min is what HP would expect as a maximum on NetWare? I don't know
    how much the aspi layer has changed in 6.0.... what I do know is that BE9.0
    doesn't use NWASPI anymore.

    Unfortunately, none of this helps you, because you're on NW4.11, it looks
    like you're stuck with that performance level until you can upgrade to 6.0,
    sorry.

    Michael



+ Reply to Thread