>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