Trevor,
        Our configuration is similar (RS6000 model R30 dual processors, 3590's
,etc.)... it takes about 70 minutes to back up our 12 GB database (85%
full).  We've  done one test at our disaster recovery site.  We restored
what was at the time a 10 GB database (80% full) on an RS6000 model 990
with a 3590 tape drive in approximately 50 minutes. I was pleasantly
surprised as I was expecting this to take 2-3 hours.  Not sure why it's
taking so much longer on your database restore... what kind of disk
drives are you using for your database?  Is the 3590 on a separate SCSI
controller ?

Regards...
Tim Pittson
tpittson AT himail.hcc DOT com

>----------
>From:  Trevor Foley[SMTP:Trevor.Foley AT BANKERSTRUST.COM DOT AU]
>Reply To:      ADSM: Dist Stor Manager
>Sent:  Thursday, August 14, 1997 4:02 AM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       ADSM database restore taking a l-l-l-o-o-o-n-n-n-g-g-g time
>
>Hi,
>
>We are currently moving an ADSM environment from one ADSM server to another
>and the restore of the database on the new machines is taking what we
>consider to be unacceptably long.
>
>The original machine is an RS/6000 R40 dual processor running AIX 4.1.5 and
>ADSM 2.1.5.12, I don't have the versions of Atape and atldd handy but they
>are the ones that were required/recommended for ADSM 2.1.5.12. The new
>machine is an RS/6000 R50 dual processor running AIX 4.2.1, ADSM 2.1.5.13,
>Atape 3.1.1.0 and atldd 3.1.0.5.
>
>The backup of the database, which is 12 gb, 60% utilised, takes 40 minutes
>to 3590s on the R40 when unloaded. We have run the restore 3 times so far
>(2 trial runs) and each time has taken in excess of 5 hours.
>
>The command that we are using is:
>
>     dsmserv restore db devclass=atl3590 volume=d90179 commit=yes
>
>For those of you who have done a restore of a database of this size, are
>the times we are seeing surprisingly long (I sure hope so)? Any suggestions
>for trying to shorten this time? We are going to try the restore on the R40
>after the move and compare results.
>
>
>thanks,
>
>Trevor
>