John O'Neall was asking how ADSM and AFS would work together. Here is a
short summary of our experience:

We have several AFS file servers and about 100 clients. For backup, we
use two independent methods:

a program called "buta" which is the ordinary AFS backup but modified
  so that it puts its results into ADSM. It is only for AFS administrator
  usage. (weekly)

ADSM on its usual incremental basis. This can be used by the normal
  user as well. (daily)

In case of disk failure, one would reload the latest buta dump and then
restore the files modified since the buta dump by using ADSM. This has
the advantage that AFS volume information is correctly loaded via the
buta interface and that the big bulk of data is loaded from few tapes
(which would not be so if ADSM were alone to do the backup). The
disadvantage is that a file deleted after the buta dump but before the
last ADSM dump will be restored (ADSM uses the fact that it is inactive
for not restoring it, but it does not delete what buta has already restored).

This process is more tedious than what one would expect from a product
allegedly supporting AFS at least under AIX -- but it is manageable. The
most important thing you have to know is that ADSM does not support AFS
at all with the exception that it backs up the ACLs:

No volume information is stored with the data. If you do not
  re-establish your volumes prior to a reload of a dump, ADSM will clutter
  everything into the volume where the root of the reloaded subtree happens
  to be. This is a good reason to use the buta code.

Mount points are not recognised. If you mount a volume from a different
  cell, e.g. CERN, you will backup their data as well. This has already
  prevented ADSM usage at other sites and has been discussed with IBM
  people for more than a year now to no avail. If you want the product
  to behave as described, you should write a DCR. - For us it is
  currently not a problem but will become one when the first user finds out
  that he may mount a remote volume without contacting the admin.

As access to the data stored under ADSM is protected only by Unix user
  name, the additional security provided by Kerberos is undermined.

We are currently investigating how we can migrate to DFS. If IBM provides
a viable solution for DFS, we could live with the current situation as long
as we still have AFS (with the exception of the bug of the last paragraph).

The permissions are not so big a problem. We have an AFS user
"admin:backup" who performs the ADSM backup. By default, admin:backup has
at least rl rights on the home directories and hence on other user
directories unless explicitly denied by the user. This is enough for
taking backups that can be restored by the user. Other restorations (e.g.
after disk failure) must be made by a process with the admin token but
this doesn't happen on a regular basis. - This looks clumsy but isn't a
problem. You could even call it a feature because now the user has an
opportunity to prevent ADSM backups which may be desirable for security
reasons.

I hope this helps.

Best regards,

Helmut Richter

 ============================================================================
Dr. Helmut Richter
Leibniz-Rechenzentrum     X.400:  S=Richter;OU=lrz;P=lrz-muenchen;A=d400;C=de
Barer Str. 21            RFC822:  Helmut.Richter AT lrz-muenchen DOT de
D-80333 Muenchen           Tel.:  ++49-89-2105-8785
Germany                     Fax:  ++49-89-2809460
 ============================================================================