ADSM-L

Re: To DirMC, or not to DirMC

2006-07-22 08:50:09
Subject: Re: To DirMC, or not to DirMC
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 22 Jul 2006 08:40:03 -0400
Orville -

Indeed, individual Technotes usually portray a small part of the big
painting, and by the nature of their modest intention do not give a
sense of the whole.

Few customers use DIRMc, and depend upon the default behavior of
storing directories with the longest management class Retonly value.
That works well for most of us.  But, then, we've seen the postings
where retention policies have changed over time and directories are
now missing such that the GUI is blocked in pursuing a path because
it can't resolve that element.  A missing directory entry is also not
a good thing for rich data structure directories as found in Windows
and Novell: while Restore Order processing will plant a skeletal
directory in order to progress, that minimal entry is not what was in
the file system originally, and may not fulfill needs after the restore.

Another area of consideration in TSM directory storage is disaster
recovery.  With default storage, rich directories are "all over the
place" in TSM storage.  In disaster recovery, you may want to get one
rich-directory client back into operation quickly, and in such case
you may want to have its data set on a known, limited set of media.
And, in any case, you don't want a restoral to go on for a protracted
period, mounting tape after tape to locate directory entries within a
larger collective.

It is good that the evolution of the product has reduced the need for
DIRMc; but we should be mindful of the circumstances which underly
its purpose so as to not be blindsided when a high-profile recovery
is needed.  The mantra in our data assurance realm is "Plan for
recovery".

  Richard Sims

<Prev in Thread] Current Thread [Next in Thread>