Paul,
One way to open up an idea is to kick around the name to find one that is
more discription.  Along the lines of 'mirror the active backup image' I
think a better name for what I see happening and being implementable is
'retain active set'.  I can't see bringing archive into it.  The key issue
for implementing this is to flag all the file versions that make up the
active set so that when some of them are no longer part of the active set
and subject to expiration, expiration is inhibited.  The flipside is to
uninhibit expiration when the retained active set isn't needed anymore.

If someone wants to capture this image to send offsite, a snapshot should be
able to drive an export.

Bill

In <3.0.2.32.19990201165304.00d19698 AT postoffice3.mail.cornell DOT edu>, on
02/01/99
   at 04:53 PM, Paul Zarnowski <vkm AT CORNELLC.CIT.CORNELL DOT EDU> said:

>Bill,

>Yes, I agree it would/should be easier than the current Archive workaround.
> Some thought needs to go into the user/admin interface.  While some sites
>would find the Admin schedule approach a good way of implementing this,
>other sites might want to give more control to their users, so that they
>could control the snapshots more.

>It seems to me that what we're really attempting to do here is to mirror
>the "active backup image" into an archive package, without having to
>re-transmit or otherwise copy the data from the client.  Modulo the symlink
>issue.  Right now, there's a wall between archive data and backup data.
>It's like the two data types are in two distinct universes.  Perhaps part
>of the solution to what we want is to create a portal between the two
>universes  (Ok, so I read too much Science Fiction ;).  When creating the
>snapshot, you could assign the backup package to an archive management
>class, which would then control the retention period.  One problem is that
>the data might/would be in the wrong storage pool.  That would have to be
>addressed somehow (perhaps just be documenting it as a restriction?).

>..Paul
>--
>At 03:37 PM 2/1/99 -0500, Bill Colwell wrote:
>>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

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