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 more management
classes defined for each of the labs. This would allow each lab to
define (more specifically, tell us to define) its own retention and data
placement policies. In the old days, this worked because the department
funded all backups and archives centrally.

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. It
became difficult for us to track which lab a particular node is
associated with. We've since split each unit (lab, center, institute,
central department) into a separate policy domain. We then have reports
that create aggregate data on the policy domain level we use for billing
from the cost center. Whether the node is UNIX, Windows, or something
else has no bearing on the policy domain; the usage from the cost center
perspective is all that matters. The retention and placement policies
from the old days is carried over too.

This got a little tricky for systems that are jointly owned by multiple
units. In these cases, there are specific data volumes that we can
assign to a specific unit. We then create a node in that policy domain
for that volume with its own backup schedule and restricted backup
domain so that we can account for this split in the cost center.

-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 05/07/13 12:58, Sergio O. Fuentes wrote:
> 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.  Sure, it's advisable 
> to have platform domains for TDP or NDMP type nodes, because of the way those 
> platforms handle retention settings for backups.  However, have any of you 
> decided to 'squish' each of the standard OS B/A client domains into one 
> singular domain?  I'm imagining having just one domain for standard B/A 
> client nodes.    (In reality, I'll have many domains for standard B/A client 
> nodes, but that's for other reasons, i.e. different stgpool hierarchy).
>
> Is there any reason not to do this?  Domain definitions have a default 
> management class that defines a copy group with retention, destination and 
> serialization parameters.  I can see serialization getting in the way, but 
> that has only happened ONCE in 8 years of TSM 5.  Other domain specific 
> options like frequency, and mode don't really impact us much.  For Windows, 
> the system state mgmt class is non standard, but since it's not the default, 
> I don't see why I can't just add it as a non-default Management Class.  I'm 
> already moving away from a directory management class, how about moving away 
> from the platform-specific domain?
>
> Thoughts, ideas?  Gotchas, that I might be missing?
>
> As always, thanks,
>
> Sergio
>