Thanks to all for your suggestions. Because the new GM data retention
policy calls for true full backups I've elected to use Selective backups
to be scheduled in a weekly, monthly, and yearly fashion. To make
matters worse this is for a cluster server so I created separate client
scheduler, acceptor, and remote client services for the weekly, monthly,
and yearly nodes of the cluster so that I can run these jobs separately
and be able to access via the web browser for any restores. It looks
ugly from a services and Cluster Admin perspective but it works and
allows backups to run even during a failover situation.
Also, I setup administrative tasks on the TSM server that will remove
the nodes from the weekly backup schedule when the monthly backup occurs
in place of the last weekly backup of the month. Then another set of
admin tasks that reassociates the nodes after the backup runs. Same
tasks are created for the weekly and monthly schedules when the yearly
backup kicks off.
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
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Troy Frank
Sent: Thursday, September 14, 2006 8:31 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Weekly, Monthly, Yearly Selectives
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.
|
