First off, I'll say that my experience has been with the MVS server. But I
expect that AIX will work the same way.

The off-site backup facility (if this is what I think it is you're talking
about) allows you to make incremental backups of your ADSM primary storage
pools. What's a "primary storage pool"? It's the conventional disk and tape
pools you might have set up under ADSM V1 (and V2). However, with the
introduction of ADSM V2, another type of storage pool, called a "copy storage
pool", was added. You can define one or more copy storage pools, and use the
new command "BACKUP STG <primarypool> <copypool>" command to make an
incremental backup of <primarypool> to <copypool>. In my case, I had three
primary pools: BACKUPPOOL, ARCHIVEPOOL, and TAPEPOOL; I also had one copy
pool: DISASTER_RECOVERY. By issuing three commands (which I'd scheduled using
the administrative command scheduling facility):

   BACKUP STG BACKUPPOOL DISASTER_RECOVERY
   BACKUP STG ARCHIVEPOOL DISASTER_RECOVERY
   BACKUP STG TAPEPOOL DISASTER_RECOVERY

I was able to make incremental backups of the three primary pools.

What do I mean by "incremental backups"? Well, with ADSM, the BACKUP STG
command operates on a file-level basis. So let's say that since the last time
I issued BACKUP STG, I backed up 20 files to disk, and 5 of them moved to
tape via migration. I've got a net change to my BACKUPPOOL and TAPEPOOL
storage pools of 15 and 5 new files, respectively. If I was to then issue the
BACKUP STG commands, no files from ARCHIVEPOOL wouuld be backed up (because
there were no new files added), the 15 new files in BACKUPPOOL would be
backed up, and the 5 new files in TAPEPOOL would be backed up. Oh, and when
the 15 files in BACKUPPOOL eventually do go to tape, ADSM will still
recognize the backups taken from when those files resided in BACKUPPOOL, so
they won't need to get backed up again. The net effect is that if you
faithfully do BACKUP STG, you'll have a logical mirror image (i.e.
file-for-file) of all files in ADSM's inventory residing in the copy storage
pool (DISASTER_RECOVERY in my example).

A couple of nice things about this:

1) If you lose a primary storage pool volume, you can use the copies in the
copy storage pool to recreate that volume (up to the time of the last BACKUP
STG command).

2) In the event of a disaster, the volumes in the copy storage pool can be
used directly to restore client data and/or recreate your primary storage
pool volumes.

I also recommend looking into the full/incremental ADSM database backup
facilities (BACKUP DB TYPE=FULL | INCREMENTAL) to protect your ADSM database,
and tie that activity to the storage pool backup activity (i.e. backup your
storage pools, then backup the database - read the Admin Guide for further
detail).

I did a real test restore of an ADSM server using both full and incremental
database backups, and the volumes in the copy storage pool. It worked like a
charm. I was able to restore the database, then I restored the primary
storage pools (I didn't have to do this - I could have accessed the copy
storage pool volumes directly - but I wanted to test it anyway). Following
that, I did a complete restore of a Windows workstation - around 100 MB of
client data. And I can most definitely say: Yes, it does work!

I hope this helps,

Andy Raibeck