Richard Sims wrote:
> >But a symbolic link is a directory entry, a self contained entity so to
> >speak.
> >Therefore by following the link, rather than merely acknowledging it, ADSM
> >is NOT providing a true copy of the data.
>
> Bob - You're completely missing the point about Archive: it is intended to
> back up DATA. No one who knows what a symbolic link is would agree with you
> that it is data - it is just a *reference* to data. A symbolic link
> IS NOT DATA. Without its target data file, a symbolic link is nothing more
> than a lost pointer.
>
I think it is unfair to imply that Bob does not understand what a symbolic link
is. A symbolic link allows you to access/call/reference one and only one copy
of a
piece of data by two or more names. The fact is, there is only one instance of
that data. Changing one changes all. In your scheme, the retrieved data breaks
this link, creating two or three versions of the piece of data which are now
independent. That is hardly what I would call preserving the data properly.
>
> It deeply disturbs me that customers are trying to get IBM to corrupt the
> purpose of the Archive operation so that it will do what customers can do
> now with Selective Backup. This is a bad thing to try to do.
> Please... Lean on them to improve the flexibility of Backup.
> What you really want is Backup, not Archive, for what you're trying to do.
> I strongly encourage you to pursue that rather than Archive, as it will
> be far less frustrating for you.
>
> Richard
Richard,
I think you do use the dishonour of not thinking that we've thought long and
hard
about what ADSM is designed to do and what we need.
Selective backup will not provide what customers want. The problem is that
customers need retention on multple different timescales (versions as often as
needed daily for several weeks or months, versions no more frequent than monthly
retained for longer, say a year, and versions no more frequent than a year
retained
for several years). This would require that versions younger than others be
expired when their certain of their elders are not , breaking the unbroken
sequence
that ADSM currently keeps (if you want a version from 11 months ago, you have to
allow for vere=340 and rete=340, yet clearly you don't want all versions of a
file
that changes daily).
Someone (Bill?) had suggested a command (snapshot) which marks all active
versions
to be marked as exempt from regular expiration (a second rete-like parameter
would
be needed). I can see that causing problems when the snapshot command isn't
run on
the right date.
My scheme of having a second node (thus license) for each node called, say,
<hostname>-monthly and doing monthly incrementals to a mgmtclass with a
copygroup
with a vere=13 & rete=365 or 400 would work (& frequency=28), but what if you
want
a yearly retained for 3 or 7 years? Yes, companies do want that. A third
nodename
<nodename>-yearly with vere=3 or 7 and rete=1100 or 2600? Actually, I rather
like
this scheme, since it is extensible to multple timescales. However, can
everybody
afford to double or triple their per-node licensing cost?
Cheers...
Bruce
--
Bruce Elrick, Ph.D.
Bruce Elrick, Ph.D.
belrick AT home DOT com
http://members.home.net/belrick/
|
