Hi,
Why dont you think of backupsets? They do not require database usage and easy
to use?
Just create backupset at the end each of period (year or month) and send them
to
offsite with the volume history file. What else could be missing in that
senario? I think : nothing.
Regards,
Burak
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
16.04.2002 15:53
Please respond to ADSM-L
� � � �
� � � � To: � � � �[EMAIL PROTECTED]
� � � � cc: � � � �
� � � � Subject: � � � �Re: Monthly Backups, ...again!
I only wish I had a way to assign different retentions to active files, I
don't actually have one.
While I'm wishing...I wish I could pick an historical point in time, and
reset the retention for the versions corresponding to that point in time
to an arbitrary value.
_____________________________
William Mansfield
Senior Consultant
Solution Technology, Inc
"Don France (TSMnews)" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
04/13/2002 03:58 PM
Please respond to "ADSM: Dist Stor Manager"
� � � � To: � � [EMAIL PROTECTED]
� � � �cc:
� � � �Subject: � � � �Re: Monthly Backups, ...again!
Bill,
Your arguments are excellent, and I have one large client dealing with the
health
records issue --- they need to save patient records for 32 years; �we are
liking
the export solution, once a year, for those nodes (in order to control TSM
db
size) -- and, continue storing their data in archive storage so we have
access to
all versions generated, then (AFTER THE FACT) deleting extra versions from
each month --- save 2 or 3, delete the rest from archive storage, using a
"smart"
script in concert with the dba's technique of naming the files being
stored.
However I only know ONE (simple) way to accomplish the desired, stated
results ---
month-end snapshot kept for X months
or years; �ie, a backupset of the desired file systems on specific nodes.
The limitation
of this solution is it only captures files in backup storage; �you need a
different
answer for database backups stored in archive storage -- my DBA's love
using
archive storage, and I have no argument against it, as they only care
about
time
(have no need or interest in counting versions, etc), and they must save
daily
backups for 4-14 days, weekly's for 6 weeks, monthly's for 6-15 months,
etc.
If you have a method that allows you "mark" the currently active versions
of
backup
files with a different retention than others, I think it would be new news
to most of us...
please share.
Thanks,
Don
�Don France
Technical Architect - Tivoli Certified Consultant
Professional Association of Contract Employees (P.A.C.E.)
San Jose, CA
(408) 257-3037
[EMAIL PROTECTED]
----- Original Message -----
From: "Bill Mansfield" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 04, 2002 9:55 AM
Subject: Re: Monthly Backups, ...again!
> There is a good reason it keeps coming up: legitimate business
> requirements.
>
> The suits (auditors, IRS, corp counsel, HIPAA, etc) demand to be able to
> be able to reproduce any datum at given intervals for given durations.
> Most often, that translates to restoring files that may change every day
> to "month end" state for somewhere between 1 and 7 years. �Sometime they
> can identify the kinds of data they want, but it is expensive to
> accurately identify the list of all files/directories required, so
usually
> you get a vague wave to "save everything". �And of course, it's their
> data, not yours, they have a right to keep as much as they want. Telling
> them that TSM doesn't support their requirement just invites other
> software vendors in the door since *they* handle this particular
> requirement with ease (on paper).
>
> The number of days you can reasonably keep in an incremental backup
> usually doesn't extend to forever. �Archives sometimes don't cut it,
> either in their traditional form or the instant form. �You can't stand
to
> move that much data or use that many tapes - that's why you went
> incremental forever in the first place. �I really just to do some
> operation that marks the current active version with a longer guaranteed
> retention, without changing the retention of anything else.
>
> I don't want to restart the perennial discussion of truly long term
> archival storage. �It's reasonable to expect a backup system to maintain
> internal compatibility for 7 years, and there are techniques for
migrating
> the data to newer media.
>
> Just my 5 cents worth (inflation).
> _____________________________
> William Mansfield
> Senior Consultant
> Solution Technology, Inc
>
>
>
>
>
> "Mr. Lindsay Morris" <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> 04/04/2002 10:04 AM
> Please respond to lmorris
>
>
> � � � � To: � � [EMAIL PROTECTED]
> � � � � cc:
> � � � � Subject: � � � �Re: Monthly Backups, ...again!
>
>
> This keeps coming up. �It's the hardest thing about TSM, to sell users
on
> the way it works.
>
> Tivoli's Storage Vision whitepaper has a comparison of the benefits you
> get
> by NOT using this Grandfather-father-son technique, but I wish somebody
at
> Tivoli would come up with some better assistance to help us sell the
> incremental-forever -ooops, progressive backup methodolgy - to
non-techie
> users. �(Maybe it's there and I just don't know where to find it...?)
>
> I think Kelly Lipp has a good article on archiving and when it's
sensible
> -
> maybe he'll post that link here again.
>
> Also, maybe some users have specific oddball scenarios they have run
into
> that require surprising policy settings. It would be interesting to hear
> about those. �Like, the user who goes on vacation for two weeks, and
> manages
> to trash here email file the day she leaves, doesn't notice it, Lotus
> touches the damaged file every day so it gets backed up again, and they
> don't keep 14 versions, so she gets back and the only good version (15
> days
> old) has rolled off (expired).
>
> ---------------------------------
> Mr. Lindsay Morris
> CEO, Servergraph
> www.servergraph.com
> 859-253-8000 ofc
> 425-988-8478 fax
>
>
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf
Of
> > Marc Levitan
> > Sent: Thursday, April 04, 2002 8:51 AM
> > To: [EMAIL PROTECTED]
> > Subject: Monthly Backups, ...again!
> >
> >
> > A question was brought up while discussing retention policies.
> >
> > Currently we have the following retentions:
> >
> > Policy � �Policy � �Mgmt � � �Copy � � �Versions Versions � Retain
> Retain
> > Domain � �Set Name �Class � � Group � � � � Data � � Data � �Extra
Only
> > Name � � � � � � � �Name � � �Name � � � �Exists �Deleted Versions
> Version
> > --------- --------- --------- --------- -------- -------- --------
> -------
> > COLD � � �ACTIVE � �COLD � � �STANDARD � � � � 2 � � � �1 � � � �5 30
> >
> > NOVELL � �ACTIVE � �DIRMC � � STANDARD � � � �30 � � � �1 � � �120 365
> > NOVELL � �ACTIVE � �STANDARD �STANDARD � � � �30 � � � �1 � � �120 365
> >
> > RECON � � ACTIVE � �DIRMC � � STANDARD � � � �36 � � � �3 � � � 75 385
> > RECON � � ACTIVE � �MC_RECON �STANDARD � � � �26 � � � �1 � � � 60 365
> >
> > STANDARD �ACTIVE � �DIRMC � � STANDARD � � � �26 � � � �1 � � � 60 365
> > STANDARD �ACTIVE � �STANDARD �STANDARD � � � �26 � � � �1 � � � 60 365
> >
> >
> > UNIX � � �ACTIVE � �MC_UNIX � STANDARD � � � �30 � � � �1 � � � 60 30
> >
> >
> > I believe that this provides for daily backups for over a month.
> >
> > There was a request to have the following:
> > 1) � Daily backups for a week.
> > 2) � Weekly backups for a month.
> > 3) � Monthly backups for a year.
> >
> > I believe we are providing 1 & 2. �We are providing daily backups for
a
> > month.
> >
> > How can I provide monthly backups for a year?
> > I know that I could take monthly archives, but this would exceed
> > our backup
> > windows and would increase our resources ( db, tapes, etc.)
> > Also, I know we could lengthen our retention policies.
> > Also we could create backup sets. (tons of tapes!)
> >
> > How are other people handling this?
> >
> > Thanks,
> >
> >
> > Marc Levitan
> > Storage Manager
> > PFPC Global Fund Services
> >
>
>
> _____________________________
> William Mansfield
> Senior Consultant
> Solution Technology, Inc
