For protection of the ADSM database, we recommend use of the online
DUMP DB command.  This can be done while the server is up and
performing other operations.  Mirroring is great for media failures
but (as you state) won't help in a disaster.  We recommend database
dumps be done on a regular basis (daily, weekly, monthly?).

Disaster protection of ADSM storage pool data is more of a problem.
There are several approaches currently being employed.

1. do nothing (accept the risk).  This is probably not feasible
for archive data or if your ADSM clients are in the same room or bldg
as the adsm server.

2. use existing backup utilities to backup online storage pool volumes
and tape copy tape stg pool volumes.  This works fine for the
disk volumes but is extremely cumbersome for the tape volumes.  Mgt
of the copies and recovery will be challenging.

3.  Use export on subsets of server data (ie, groups of nodes at a
time and only the active data).  The problem here is export runs
extremely slow for large amounts of server data.

4. Send a 2nd copy of the user data across the network (eg, with
a 2nd client on each workstation) into a different storage pool (or
different adsm server) which is used as an offsite copy.

None of these are ideal.  We are currently developing some very
robust solutions to facilitate protection of the adsm database and
storage pools.  These should be available in the next release.

Greg Tevis
ADSM Technical Support