Hi,

do your homeworks and isolate what is
slow in your *SM solution.

Maybe the CPU is your constraint?
Upgrade it or move to AIX.

Maybe the tape technology is slow in seekeing?
Consider 3575 as backup medium.

Maybe your DB is too large?
Divide your serevr to smaller ones.

etc. etc.

What is actual and what is your requiered restore performance?

What are the expenses of evaluating and 
implementing another tool?

Can you using maybe 50% of this budget substantially improve your
current installation?

What performance improvement can you avait 
from another tool/backup approach at all?

Is performance required realistic through network at all?

Is performance required realistic with 
an incremental backup approach at all (keep tape seek times
in mind which just a_n_y incremental tool has to cope with)

Is performance required realistic with your clients at all?
(do you have small files? How quickly can your client create files?)

What is backup safety, redundancy etc. worth for you?

Create much more such questions,
do ask yourself different things,
and you will find answers.

There had been different discussions 
on this forum about *SM performance,
search in this forums backup on the web.

We here on "my" site have an HP-Omniback as well,
and if you only consider speed,
this is definitely much quicker tool (*),
as long as you use the "always full backup" approach.
*mainly because it supports tape media local to client.
Not so fine for incremental backups.



We in this forum 
can better help you with more exact and narrowed questions.


Good luck,
and let us know later what your results will be!

Juraj Salak 

KEBA AG
Softwareentwicklung Bankautomation
Gewerbepark Urfahr 14 - 16
Postfach 111
A-4041 Linz
Österreich

Tel. ++43/732/7090-7461
Fax ++43/732/730910
e-mail: sal AT keba.co DOT at
www.keba.co.at