Thanks, guys! I had fallen asleep monitoring this thread and I just now caught
up on it.
Yes, there's a lot of unknowns at this juncture of our re-architecture of the
TSM environment. We're introducing TSM DD as much as possible into the
environment, along with replication between our two
FWIW, here's the characteristics we use to split up our storage pools:
* Backup vs archive - we segregate archives from backups since their
retention (and subsequent reclamation) is so much longer than backups
* Library - obviously we need to have separate storage pool hierarchies
for separate li
AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices
Just my 2 cents :)
One of my TSM worlds consists of several TSM servers and roughly 900 clients
(mix of BA, TDP, etc.).
When the time came for an upgrade the original system was configured
DSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices
Just my 2 cents :)
One of my TSM worlds consists of several TSM servers and roughly 900 clients
(mix of BA, TDP, etc.).
When the time came for an upgrade the original system was configured where
do
ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Prather, Wanda
Sent: Wednesday, May 08, 2013 11:15 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices
Agreed. No reason to create different domains due to platform, TSM doesn
VM.MARIST.EDU] On Behalf Of Bill
Smoldt
Sent: Tuesday, May 07, 2013 4:23 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices
Sergio,
Having developed some of the early training, way before V5, I can tell you that
the rationale for platform d
On 05/08/2013 09:40 AM, Skylar Thompson wrote:
> We've offered labs policy authority, although so far they're all happy
> letting us suffer with managing the entire thing. :P
>
Heh. Well, we've been doing one variation or another on this service
for more than 10 years, so I've had training time.
We've offered labs policy authority, although so far they're all happy
letting us suffer with managing the entire thing. :P
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of
On 05/07/2013 04:32 PM, Skylar Thompson wrote:
>
> We now have moved to a model where the unit generating the
> backup/archive usage is charged per byte per year via a cost center.
We've got a very similar structure here at UF, with the addition that
there are "local admins" designated for each (m
I work in a large research department, with 31 labs that basically
function as autonomous businesses, along with a few institutes and
centers with their own funding. Of those 31 labs, 13 of them have some
form of dedicated computational resources.
We used to have one big policy domain, with one or
Sergio,
Having developed some of the early training, way before V5, I can tell you that
the rationale for platform domains was strictly organizational. In those days,
most IT shops were organized by platform and had retention control over their
own systems.
Free of the organizational restri
Hello all,
Back in the early TSM 5 days, or at least once when I went to training, it was
advised that each individual platform had its own DOMAIN for retention and
destination control. Now, since I'm evaluating a TSM v6 environment, I'm
rethinking whether that is necessary across the board.
12 matches
Mail list logo
