Paul,
I think it would be easier to implement than the current archive workaround
where you need a schedule for each filespace, and you end up with a larger
database which takes longer to backup, and larger storage pools, which take
longer to backup too, etc., plus the symbolic link issue.

With admin schedules it should be easy to put in the snapshot commands for
quarterly or annual snapshots.  As for educating users, don't!  These
snapshots are restores of last resort, mandated by business rules or
external requirements, e.g the IRS.  Users need not know much about the
snapshots except that they are there and provide a warm-fuzzy.  Restores
should be rare and adhoc, and with the 3.1.0.6 client level, which provides
the admin web b/a client, you can drive the restore!

I first proposed this on a v1 server; since then the v2 & v3 servers have
added enough features to make administering snapshots fairly easy, IMHO.

Bill

In <3.0.2.32.19990201144856.00fdd6a8 AT postoffice3.mail.cornell DOT edu>, on
02/01/99
   at 02:48 PM, Paul Zarnowski <vkm AT CORNELLC.CIT.CORNELL DOT EDU> said:

>Bill,
>I like your idea.  It, or something like it, would address the needs of
>some of our users.  While it's true that you can implement snapshots with
>Archives, it would not be nearly as efficient.

>I don't know about the actual implementation specifics (e.g., "snapshot"
>command), but the idea of keeping track in the database that a file is part
>of a Point-In-Time backup image (e.g., Quarterly, etc) seems powerful to
>me.  The downside of this would be that it adds additional complexity, both
>to understand, explain to users, and to implement.
>..Paul
>--
>At 12:45 PM 1/29/99 -0500, you wrote:
>>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
>>C. S. Draper Lab
>>Cambridge, Ma.
>>bcolwell AT draper DOT com
>>--------------------------
>>
>>
>>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
>>

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================