> Alan, yes it would be cool to have a feature like this. This isn't the
first
> time for it to be discussed on the list or to be submitted to IBM; I
submitted it
> maybe 4 years ago and it was discussed on the list last Feb. But don't
let
> that stop you! Pick up the ball and run with it!
>
> Below is one of the items from the last list discussion thread. See them
all
> at www.adsm.org, search on 'snapshot'.
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
> Re: Archive vs. Backup (snapshot
> enhancement)
>
> Forum: Re: Archive vs. Backup (Paul Zarnowski)
> Date: 1999, Feb 01
> From: Bill Colwell <bcolwell AT DRAPER DOT COM>
>
> 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
> C. S. Draper Lab
> Cambridge, Ma.
> bcolwell AT draper DOT com
> --------------------------
>
>
>
>
>
>
> In <009e01bf45b5$ef416260$4b1e989e@oemcomputer>, on 12/13/99
> at 10:03 PM, "Alan R. White" <arw AT TIPPER.DEMON.CO DOT UK> said:
>
> >Wouldn't it be cool if the policy copygroups contained additional
facilities
> >for specifying that a revision of a file which corresponds to a weekly or
> >monthly 'view' of a filesystem should be retained for an alternative
length
> >of time? Expiration would have to get more intelligent (groans) so it
> >doesn't expire these 'views' of data until the specified time.
Reclamation
> >etc would work as normal.
>
> >I'm going to submit this as a request through the usual channels. This
means
> >it won't get done unless everybody hits them with it. Anyone else think
this
> >change would be a good idea?
>
> >Regards
> >Alan
>
> >----- Original Message -----
> >From: Franco Martini <franco.martini AT RAIFFEISEN DOT CH>
> >To: <ADSM-L AT VM.MARIST DOT EDU>
> >Sent: Monday, December 13, 1999 2:18 PM
> >Subject: Archives
>
>
> >> Hi
> >> We have the policy to make every week an archive and every
> >> month one (different management classes).
> >> So we decided to make every saturday morning a week archive
> >> and every first day of the month a monthly backup.
> >>
> >> Now we have the problem that sometimes it happens that saturday is the
> >first of
> >> a month
> >> and so ADSM makes two archives of the same data. :(
> >> Thats a waste of network bandwith and Tapes.
> >>
> >> Is there a possibility to tell the ADSM Server if he makes a monthly
> >archive
> >> we dont want a weekly archive?
> >>
> >> Regards
> >> Franco
> >>
>
>> -------------------------------------------------------------------------
> >> Franco Martini / Systemtechnik Tel. : +41 71 225 8779
> >> Schweizer Verband der Raiffeisenbanken Fax : +41 71 225 8912
> >> Wassergasse 24 Email :
franco.martini AT raiffeisen DOT ch
> >> 9001 St. Gallen
>
>> -------------------------------------------------------------------------
|
