We just did something similar to this last week:
- We run TSM server 4.1.6 on OS390 preparing to go to TSM 4.2
- We were keeping 30 version / 30 days of the 'system objects' for some
200+ NT clients.
- Created a new management class with 7 version / 7 days for 'system
objects'
- Added this to the client options set on the server side
Here's what happened / is happening:
-Recovery log for TSM 4.1.6 has a limitation of 5GB.
-We blew out the recovery log and had to recover TSM (much pain the
first time). This was caused by all of the rebinding plus the expiring
(I'm assuming).
-Some backups got finished, a lot did not before TSM crashed.
-Set retention in new management class to 28 days to reduce the
expiration and just try to get the rebinding done.
-Again, recovery log filled up and we had to recover TSM...a little less
painful but, still very painful.
-And, again, not all backups completed so, we spent the next day running
these backups 5-10 at a time to get through all the rebinding and
finally did.
-We are now decreasing the versions one at a time and are down to 26
versions (one day at a time is getting the recovery log to approximately
65% full so, we don't want to go any further than that).
-Obviously this could be less painful in 4.2 with a larger recovery log
but, want to get cleaned up prior to that time.
Anyway, just a heads up...and, welcome any ideas to reduce this pain.
Thanks,
Cinda
Ascension Health ISD
>>> [EMAIL PROTECTED] 11/06/02 04:15PM >>>
Todd,
may I correct you. In TSM it is called "rebinding":
- you have several backups made using one class (be it default or not)
- somehow (dsm.sys/dsm.opt, optionset) you change include/exclude list
and
a object (in TSM terms - file, TDP stream, SystemObject, etc.) is now
bound to another class
- TSM server on first backup after the change "re-binds" ALL versions
(retro-active) of that object
- on next expiration new class' vere/verd/rete/reto settings are
honoured
Example 1:
previous class was with 60 days retention, new class is with 7 days (as
in
Kevin's case):
- system objects back to 60 days ago
- after Wanda's suggested change system object is rebound
- next expiration ought to remove all system objects older than 7 days
(disclaimer: on version without System Object expiration bug)
Example 2:
old class with 5 versions, new class with 12 versions
- 5 versions are kept and each 6-th old is expired
- a file is rebound to new class
- new backup will notify server about rebind and will create 6-th
version
- until 7 new versions are backed up (for total of 12) no version will
be
expired despite the fact the oldest versions were created when limit was
only 5.
I hope this helps
Zlatko Krastev
IT Consultant
Todd Lundstedt <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
23.10.2002 20:11
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: System Object / Mgmt. Classes / Policy Sets
/ Backup Groups - - Wh
at's the best way??
Correct me if I am wrong, but this will only change the management class
for the backups after the changes are made. All of the other
systemobjects
that exist in the database that are managed by the old management class
will be retained for their 60 days. In order to facilitate the move to
the
new management class, you will want to rename the systemobject filespace
on
each server (for instance, systemobject.old), then perform your backups
for
8-9 days, making sure the new systemobject only has data stored for 7
days,
and only in the new management class. Then, it will be safe to delete
systemobject.old, and recover that database space prior to your upgrade.
Todd
|--------+-------------------------->
| | "Prather, Wanda"|
| | <Wanda.Prather@J|
| | HUAPL.EDU> |
| | Sent by: "ADSM: |
| | Dist Stor |
| | Manager" |
| | <[EMAIL PROTECTED]|
| | T.EDU> |
| | |
| | |
| | 10/23/2002 11:48|
| | AM |
| | Please respond |
| | to "ADSM: Dist |
| | Stor Manager" |
| | |
|--------+-------------------------->
>----------------------------------------------------------------------------------------------------------------------------|
| |
| To: [EMAIL PROTECTED] |
| cc: |
| Fax to: |
| Subject: Re: System Object / Mgmt. Classes / Policy Sets /
Backup Groups - - Wh at's the best way?? |
>----------------------------------------------------------------------------------------------------------------------------|
Hi Kevin,
Most people have only 2 policy sets for each policy domain - the acitve
and
the inactive one.
I suggest you make a new management class:
* In the NOCODOM policy domain, create a new management class, for
example call it SYSOBJ_MAN
* Edit the BACKUP COPY GROUP for that new management class to set
your
retention to 7 instead of 60.
* ACTIVATE the policy set for that domain; that makes the changed
version active.
* Pick a Win2K client in the NOCODOM domain to test.
* In the dsm.opt file of that client, put an include statement to
cause TSM to bind the systemobject to the new management class:
include.systemobject SYSOBJ_MAN
* Start the backup client and backup the system object
* Now pretend you are going to restore the system object:
start the client
click RESTORE
expand SYSTEM OBJECT
click on one of the components (like registry)
scroll to the right, you should see the time and
management
class of the last backup
if it says SYSOBJ_MAN instead of DEFAULT, it's working
* Now you have to figure out how you are going to make this happen
on
ALL the clients in the NOCODOM domain.
* You can either use sneakernet and add this to the dsm.opt file
of
all the affected clients, or
create a clientoptionset on the server with this include
statement
(certainly easier to do!)
-----Original Message-----
From: Thach, Kevin [mailto:KThach@;COVHLTH.COM]
Sent: Monday, October 21, 2002 3:54 PM
To: [EMAIL PROTECTED]
Subject: System Object / Mgmt. Classes / Policy Sets / Backup Groups --
Wh at's the best way??
Hi,
I've been designated the TSM administrator here at my workplace, and I'm
trying to educate myself as I go without making a mess of things. Our
IBM
partner came in and installed the server and a few clients, and handed
it
over to me. I now have about 200 Win2K clients, 40 AIX Clients, and
about
5
Linux Clients.
My question is this:
The person that installed our environment basically set up 6 Policy
Domains:
Colodom, Exchange, Lanfree, MSSQL, Nocodom, and Oracle.
99% of the clients are in the Nocodom (non-collocated) domain, which has
one
policy set, and one management class which has one backup copy group
with
retention policies set to NOLIMIT, 3, 60, 60.
So, my problem is this. It turns out that in trying to upgrade from
4.2.2.3
to 5.1.X we ran into the problem with System Objects BIGTIME. We are
retaining 60 days worth of System Object files for about 200 Win2K
clients,
which translates to about 29,000,000 System Object files, and about 55%
of
our TSM database (36 GB).
What we've decided to do before upgrading to 5.1.X is to upgrade to
4.2.3
and lessen the retention for the System Objects. However, I have no
experience in setting up Mgmt classes, policy sets, etc, and I'm not
sure
what I need to do in that arena.
What I'd like to get to is this:
1) System Objects retained for 7 days
2) Everything else retained for 60 days
How do I set up an additional policy set for just the System Object
stuff?
Thanks in advance!
-Kevin
This E-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
only
for the use of the Individual(s) named above. If you are not the
intended
recipient of this E-mail, or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that
any
dissemination or copying of this E-mail is strictly prohibited. If you
have
received this E-mail in error, please immediately notify us at (865)
374-4900 or notify us by E-mail at [EMAIL PROTECTED]
NOTE: This e-mail message may contain information that may be privileged,
confidential, and exempt from disclosure. It is intended for use only by
the person to whom it is addressed. If you have received this message in
error, please do not forward or use this information in any way, delete it
immediately, and contact the sender as soon as possible by the reply option
or by telephone at the telephone number listed (if available). Thank you.
