Every time the {month/quarter/year/decade}-end discussion starts, it reminds
me of an enhancement request I submitted years ago, which IBM took as a
suggestion.  I still think it would solve this problem, if it can be
implemented.  So I will throw it out again and see if it clicks with anyone,
hopefully someone in Tuscon!

I call it point-in-time snapshots.  The idea is that a new command,
snapshot, would record the object-ids of the active set and mark the active
set file version records to exempt them from deletion if and when they are
inactive and enough time has past or enough new versions have arrived. (I
believe that every record in the database has an object-id.  I don't know
this for a fact, but that is how I interpret the vibrations I get when I rub
the black box.)

These snapshot records would themselves go into a storagepool and follow
management class rules.  When one expires, the server would open it up and
unmark the versions recorded in it, so that these versions can now expire
(actual I would expect the mark to be a count of how many snapshots a
version is in, and when the count is decremented to 0, the verion can be
expired).

To use a snapshot for restore, you would somehow tell the client to not look
at the real activeset, but instead pretend that the snapshot's list of
object-ids represents the active set.  It could probably drive an export
too.

All this processing is in the server, no extra files are sent by the client,
the server storage doesn't grow except to hold the snapshots themselves and
they are small, and the database doesn't grow much at all.  Also you don't
need new managementclasses and the servers use of
managementclasses isn't altered radically.  Expire inventory needs to do one
more check before deleting a version.


--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <199901291510.KAA102626 AT fserv2.bu DOT edu>, on 01/29/99
In <199901291510.KAA102626 AT fserv2.bu DOT edu>, on 01/29/99
   at 10:10 AM, Richard Sims <rbs AT BU DOT EDU> said:

>>It could actually be much worse than that, as we have discovered.
>>The default behavior of Archive is to FOLLOW SYMBOLIC LINKS.

>This is as it should be.  The intent of archival operations is to preserve
>images of data at given points in time, to serve versioning, legal, and
>other needs.  A symbolic link is only an allusion to data and just doesn't
>fit the paradigm.  The purpose of Archive is to capture data at any given
>instant in time, and that's what it does.  It does not capture symbolic
>links or directories (though it remembers the directory structure for basic
>reconstruction upon Recall).

>Customers are trying to use Archive to make archival "backups" outside of
>the Backup function due the the cumbersomeness of Backup retention rule
>sets and because it remains exceedingly awkward to select Management Class
>even in ADSMv3.  But Archive and Backup have different purposes, and as we
>see, customers attempting to use Archive as a backup variant are finding it
>less than satisfactory.  That's not a reflection on Archive so much as in
>the inflexibilities surrounding Backup, which cause customers to resort to
>Archive.  Selective Backup makes more sense, but still participates in the
>backup set version limits, which interferes with retention of the regular
>backups.

>Customers seeking to make backup sets outside of the regular backups need
>to do it with a different management class, where you can specify separate
>rules and limits.  Long-term, we need IBM to make it possible to more
>readily select management class, as on the command line.

>      Richard Sims, Boston University OIT