Instead of using a SELECTIVE backup which you need to specify what to backup,
just change the management class(es) used for the
weekly/monthly/yearly backups to MODE=ABSOLUTE. Then you backup schedules are
just INCREMENTAL using the existing DOMAIN, but
actually FULL backups each time.
You also might want to persue with management about excluding things, like the
System Object if a full BMR on the Windows server
won't be required.
You also may want to look at a separate instance for the weekly/monthly/yearly
backups. Seeing as how you're backing up each object
every month your TSM DB usage is gonna grow like crazy.
You can implement it as 3 instances on the same server. That way even if it's
SCSI attached tape, you can still do library sharing.
You should also look at what your disaster recovery requirements are....having
this ever growing weekly/monthly/yearly backup data
in the TSM database along with the daily backups will make your recovery all
that much longer. Usually for D/R you will be restoring
to the latest possible time and having the weekly/monthly/yearly data is not
immediately required.
I'm going through a split of a TSM database that is now 350GB and growing 5% or
more per month due to FULL monthly backups. I figure
that the daily data in the DB is only about 1/4th or less of the total and
right now my DBBackup runs 6+ hours.
It would be easier to just setup another instance to start with using a
different TCPPORT than to realize that you need to split it
out later.
I'm not sure what the licensing requirements are if you will be running
multiple instances on the SAME box.
Bill Boyer
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Scott, Brian
Sent: Friday, September 15, 2006 9:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Weekly, Monthly, Yearly Selectives
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.
|
