Hilton Tina writes:
 > Can you describe the "serious weakenesses" you mentioned?  We've been
 > using it since it became available to back up at the file level and
 > haven't noticed any problems.  Luckily, we haven't had to restore much
 > yet, so maybe that's why.  I'd like to hear about the problems you've
 > encountered that are making you consider switching to backing up at the
 > file set level.

OK, I'll jump into it.

The main problem we see stems from what perhaps is somewhat peculiar to our
environment: We have a big number of DFS filesets (about 32000), because
each user has her/his own. Since it does not make sense to define
virtualmountpoints for each of these filesets, we have to define them at
a higher level. This means that we have to allow ADSM to cross mount
points (DFSBackupmntpnt=No). Now, if any user ever decides to create a
mount point in his/her fileset, we will backup whatever is behind it!
And we cannot prevent them from doing so, because every user can do a
"fts crmount".

From the ADSM point of view, our DFS tree consists of about 30 file spaces,
which are mainly quite big (the biggest contains 17 GB / 420000 files).
When we started backing them up, we had problems with the client running
out of memory; we have not seen this problem recently.

We still use ADSM version 2 to backup DFS, because V3.1.0.3 gives me a
mysterious "IOT/Abort trap(coredump)" most of the time. I have not reported
this problem to IBM yet.

Another point: the file level backup has a huge contribution to the size
of our ADSM database. It is an attracting idea, to get rid of it by using
the fileset backup.

Which principal do you use to backup DFS? We have been using root so far,
but root is considered harmfull by DCE experts because of its property of
not having to obey ACLs (it's a leftover from NFS). I heard rumours, that
it might vanish from future DCE releases.

Hope, this helps you. As you can see, the problems are mainly not on the
restore side (although the size of the file space of course has an effect
on the restore). But we haven't had to restore much either.

 >
 > Thanks.
 >
 > Tina Hilton
 >
 > > -----Original Message-----
 > > From: Reinhard Mersch [SMTP:mersch AT UNI-MUENSTER DOT DE]
 > > Sent: Tuesday, May 19, 1998 2:40 AM
 > > To:   ADSM-L AT VM.MARIST DOT EDU
 > > Subject:      Re: ADSM/DFS experience
 > >
 > > Hi,
 > >
 > > well, we are using ADSM and DFS, and some, but probably few, others
 > > also
 > > do. So, what is it you want to know?
 > >
 > > In general, there are two ways to backup DFS filesets with ADSM:
 > > First,
 > > doing file level backup using the DFS enabled ADSM client (dsm[c]dfs).
 > > Second, doing fileset backup using the DFS backup system (bak) and the
 > > ADSM agent program (buta), which replaces butc. The latter is oftenly
 > > combined with cloning filesets and giving the users access to the
 > > clones.
 > >
 > > We are currently using the former approach. It gives more comfort to
 > > the
 > > users (allowing them to restore inactive backups), but has some
 > > serious
 > > weaknesses. We will therefore switch to the latter soon.
 > >
 > > --
 > > Reinhard Mersch                     Westfaelische
 > > Wilhelms-Universitaet
 > > Universitaetsrechenzentrum, Roentgenstrasse 13, 48149 Muenster,
 > > Germany
 > > E-Mail: mersch AT uni-muenster DOT de                  Phone:
 > > +49(251)83-31583
 > >
 > > Larry Rudsinski writes:
 > >  > I have been getting email from ADSM-L AT VM.MARIST DOT EDU for about two
 > > weeks
 > >  > now, and out of the 300 or so email messages only a few said
 > > anything about
 > >  > ADSM/DFS. We are looking for anyone who has had experience with
 > > backing up
 > >  > DFS filesets.
 > >  > Thanks!!
 > >  > Larry Rudsinski
--
Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Universitaetsrechenzentrum, Roentgenstrasse 13, 48149 Muenster, Germany
E-Mail: mersch AT uni-muenster DOT de                  Phone: +49(251)83-31583