Are you restoring from a non-collocated copy storage pool into a
collocated primary storage pool?  This can be pretty slow because
the restore essentially has to sort all the files by node to collocate
them in the target primary storage pool.  If this is your situation,
you should be able to greatly accelerate the process by restoring to a disk
storage pool and then allowing the files to migrate into your sequential
primary storage pool.  The reason for this is that files in a disk storage
pool are "presorted" in the database to facilitate migration.

If this is not what is happening, it is possible that the restore is simply
trying to locate the files that must be restored.  If they are widely scattered
over many copy storage pool volumes, there could be periods of apparent
inactively, but I would not expect these to last for hours.

I would be willing to discuss this with you to try to determine what is
happening and to see if your restore might be accelerated.  However, I have
been having problems with outbound e-mail during the past couple days.  If
you would like to discuss this, send me an e-mail note with your phone number
and I will give you a call.

Dave Cannon
ADSM Development
------------------------------- Referenced Note ---------------------------
Does anyone have any experience with the 'restore volume' command?  We just
Does anyone have any experience with the 'restore volume' command?  We just
recently lost a tape (the DLT2000XT swallowed the entire tape then broke it
off inside).  We have completed an offsite backup with the 'backup stgpool'
command, so I brought the tapes back and issued a restore volume on the
tape that was 'destroyed'.  The restore volume has been sitting for hours
doing nothing.  It has only restored 5MB out of 26GB lost on the tape in
about 10 or so hours.

Is this normal?  Does this process usually take this long?

Bob