We use ADSM to back up 18 AIX systems. We use the standard backup-archive
client to back up ordinary files, and an API client to back up Oracle
databases. We use a copy storage pool without collocation for disaster
recovery. We recently ran a disaster recovery test. It took us almost
8 hours to recover the ordinary files on one client system, mostly
because of the enormous number of tape mounts needed to obtain all the
files.

I have come up with a possible cure for this problem. The proposal is
to segregate Oracle database backups and ordinary AIX file backups into
sepearate storage pools, configure the replacement for the ADSM server
with enough disk space to hold all of the ordinary file backups, and
run two RESTORE STGPOOL commands to copy these backups from the copy
storage pool tapes to the big disk storage pool (one for files that
were in the primary tape pool when the last BACKUP STGPOOL was done,
and one for files that were still in the disk storage pool at that time.
I am fairly sure ADSM would mount each of these tapes only once. Once the
RESTORE STGPOOL operations were done, client restores could be done with
no further tape mounts.

The API client would still have to do its restores from tape. I don't
think this would be a problem. The client works in such a way that all
the files needed for a particular restore operation would have been
written to tape at about the same time.

The only thing that worries me is the performance of the RESTORE STGPOOL
commands. We run daily BACKUP STGPOOL commands that usually move 12 to 15
gigabytes of data, most of it from the API client. This typically takes
about an hour and a half. The last time we added an AIX client the process
took an hour longer than usual. The initial backup of the new client only
added about a gigabyte to the normal workload, but it increased the number
of files to be processed by about 20,000. This suggests that the elapsed
time for BACKUP STGPOOL operations involving large numbers of mostly small
files is controlled by the elapsed time required for all of the attendant
updates to the ADSM database. On the face of the matter, a RESTORE
STGPOOL would seem to require about the same amount of database activity
per file as a BACKUP STGPOOL. At 20,000 files per hour it would take us
over a day to run the pair of RESTORE STGPOOL commands described earlier.
Since our management is thinking in terms of having the administrative
applications on the AIX systems up and running 36 hours after a disaster,
this is a serious problem.

Is there any reason to believe that a RESTORE STGPOOL would take
dramatically less time per file than a BACKUP STGPOOL? Is there any kind
of performance tuning that would dramatically improve the performance
of large RESTORE STGPOOL operations? If the answers to both of the
previous questions are negative, is there any network backup product
whose disaster recovery facilities are actually useful for installations
as big as mine?