see below in the origional message for my answers...
     We have AIX, SUN (OS & Solaris), Novell, and NT's


______________________________ Reply Separator _________________________________
Subject: ADSM Performance
Author:  ADSM-L at unix,uu/dd.RFC-822=ADSM-L\@VM\.MARIST\.EDU
Date:    8/26/96 12:10 PM


  We are currently running 2 ADSM systems, each consist of  an IBM
  RISC/6000,  Exbyte 480 (80 - 8mm tapes with 4 tape drives each) Tape
  Storage Pool; a Data General Cariion 40Gb Data Storage Pool and a 2Gb
  data base. We are backing up 300 NT servers and 30 Unix servers spread
  out over our WAN. Our ADSM servers are on 2 different FDDI rings and our
  NT and Unix clients are on either T/R 4-16 Mbps or Ethernet 10Mbps.

   Does anyone have any recommendations for hardware/software configuration
  than could meet the following requirements :

  1- We have a need to backup 2Tera bytes of data with growth up to 4 Tb
  within the next 2-4years.
  ==> I've got two servers each taking in 150-225GB/night
  ==> GET OFF OF 8mm tape, the time to accelerate to speed will kill you !

  2- We currently have NT servers with partitioned drives of 20Gb, as DASD
  grows so will our drive  sizes.
  ==> Good start, keep unique areas on the server, my tricks are used
  ==> mainly in Novell but will work for NT's also...

  3- We would like to be able to restore data at a rate of 1Gb/hr or
  faster.
  ==> Multiple restores ! I know this will be a pain in the @$$ but it
  ==> can help... set up management classes for NT's by drive def's
  ==> NTC, NTD, NTE, ... NTn then, to max speed, have your schedules
  ==> run a script to initiate multiple DSMC's one for each drive...
  ==> then if (in the end) you have collocation on and put each drive
  ==> of each machine on a seperate tape then for restores you can fire
  ==> up multiple sessions (as many as you have tape drives) and know
  ==> each one will/should be busy...



  So far the Exbyte is the bottle neck on our throughput once the backup
  process starts. However it has taken up to 2 hours simply to query the
  data base for the list of files that we may need to restore. This data
  base problem and the tape throughput is killing us.
  ==> the db delays are probably (might be) associated with the slow
  ==> nature of the 8mm tapes, not knowing how, when, and how much the
  ==> locks hit the db I can't say for sure but knowing the snail's pace
  ==> of 8mm tapes the migration process might be holding the DB locked
  ==> excessively... or the fact that you are on  10BaseT... GO FDDI !
  ==> also look into max'n out the TXNBYTE, TXNFILES, MOVEMAXBYTES, and
  ==> MOVEMAXFILES (close to the right names, MOVEMAX.. showed up in
  ==> 2.1.0.8) because this directly impacts the db & response times...
  ==> partial sec db updates times 1+million updates = a long time...
  ==> cut the updates in half and save that much time....

  Is ADSM the product that we need to stick with or is there something else
  we should be looking at or is this a hardware/configuration issue?
  ==> I would say your hardware... even with all I've encountered (mainly
  ==> black circles under my eyes from lack of sleep) I still believe it is
  ==> the best on the market... but I'm sitting on 1/2+million $ servers.

  Thanks for any help you guys might be able to provide.
  Stan Efird
  sefird AT dpcmail.dukepower DOT com