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:
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