A couple people on here had mentioned a good idea that was an
alternative to running occasional archives (which are always full
backups).  Basically you define the client as more than one node (ie.
node/node-monthly/node-yearly).  You then bind these 3 nodes to
different policies, and 3 different schedules.  The "node" gets assigned
to whatever your default retention period is (I'll say 30 versions in
this case).  Node-monthly gets ~13 versions, but only gets run once per
month.  Node-yearly gets ~ 7 versions (for a 7yr retention), and only
gets run once per year.  This way, your "archives" can use the same
incl/excl lists as your backups, and they take less time, as they don't
have to do a full after the 1st run.

I would guess that others doing this have probably setup separate
online & copypools for this data, just to keep it separate.  One thing
to watch out for with this method (differing from archives), is that by
default you're back to getting 2 copies of the data....one in an
onlinepool, and one in a copypool, whereas archives were only one copy.
In general it's better to get 2 copies, but it will take up a lot more
space in your library without preventative measures.  If the 2nd copy of
the data isn't important to you, you could probably forgo creating the
copypool for this long-term data, and just take the online copies out of
the library after each run.  That would be more labor intensive for
reclamation though, as you'd have to manually retrieve the tapes.



>>> pdudley AT ANL.COM DOT AU 9/13/2006 11:25 PM >>>
Can you explain what you mean by:

"Also, as others have mentioned before, there's no need to make these
monthly/yearly backups a selective(full).  You can just make a 12
version & 5 version management policy for the monthly & yearly
backups,
respectively.  All the backups can be incremental this way, and you
save
bookoo tapes & DB entries (not to mention faster backups)."

As I have a similar issue.

Thanks
Paul Dudley


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Troy Frank
> Sent: Wednesday, 13 September 2006 8:06 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Weekly, Monthly, Yearly Selectives
>
> This sounds like a classic request from management that doesn't
> understand TSM works differently from typical backup software, and
> they're trying to shoehorn it into behaving as they're used to.  If
you
> make your normal retention policy 30 versions or more, you can at
least
> get rid of the weekly/monthly full backups.  In our case, we do 60
> versions held for 60 days.  So if/when we do longer term archives,
it
> would have to be at most bi-monthly.
>
> Also, as others have mentioned before, there's no need to make these
> monthly/yearly backups a selective(full).  You can just make a 12
> version & 5 version management policy for the monthly & yearly
backups,
> respectively.  All the backups can be incremental this way, and you
save
> bookoo tapes & DB entries (not to mention faster backups).
>
>
> >>> bscott AT EDS DOT COM 9/12/2006 4:12 PM >>>
> Fellow TSM'rs,
>
> I have been tasked to provide a backup schedule to provide weekly,
> monthly, and yearly full backups for a 5 year duration. The weekly
would
> be retained for a month, monthly for a year, and yearly for 5 years.
> I've created separate policies, nodenames, etc. to keep the policy
> retentions separate. The problem I have is the actual TSM client
> schedule on the server.
>
> How do I keep the weekly selective backup from running at the end of
> the month when the monthly selective is supposed to kickoff? Same
thing
> for the monthly at the end of the year when the yearly selective
will
> kickoff?
>
> I'm running TSM server 5.3.3.0 and BA 5.3.4 and I see the Enhanced
> Schedule capability to provide DAYOFWEEK and WEEKOFMONTH to which I
> can
> set Saturday as DAYOFWEEK and First,Second,Third as WEEKOFMONTH
> but some
> months have 4 weeks while others have 5. Also, I can't set the
weekly
to
> be every Saturday BUT the last Saturday of the month and the montly
to
> be every last Saturday BUT the last Saturday of the year.
>
> Any suggestions?
>
> Regards,
> Brian
>
> Brian Scott
> EDS
> Global Client Engineering-GM
> MS 3234
> 4594 W Nancy Dr.
> Kankakee, IL 60901
>
> ( Phone:+1-815-939-2684)
> + mailto:bscott AT eds DOT com
>
> Confidentiality Notice follows:
>
> The information in this message (and the documents attached to it,
if
any)
> is confidential and may be legally privileged. It is intended solely
for
> the addressee. Access to this message by anyone else is
unauthorized.
If
> you are not the intended recipient, any disclosure, copying,
distribution
> or any action taken, or omitted to be taken in reliance on it is
> prohibited and may be unlawful. If you have received this message in
> error, please delete all electronic copies of this message (and the
> documents attached to it, if any), destroy any hard copies you may
have
> created and notify me immediately by replying to this email. Thank
you.




ANL DISCLAIMER

This e-mail and any file attached is confidential, and intended solely
to the named addressees. Any unauthorised dissemination or use is
strictly prohibited. If you received this e-mail in error, please
immediately notify the sender by return e-mail from your system. Please
do not copy, use or make reference to it for any purpose, or disclose
its contents to any person.

Confidentiality Notice follows:

The information in this message (and the documents attached to it, if any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.