ADSM-L

Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices

2013-05-07 16:25:29
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices
From: Bill Smoldt <smoldt AT STORSERVER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 7 May 2013 20:23:24 +0000
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 restriction it makes sense to create and populate 
domains specific to common retention parameters so that you aren't stuck with a 
lot of include <mgmtclass> statements.
___________________________
Bill Smoldt
President
www.storserver.com
719-266-8777 x7103


On May 7, 2013, at 1:58 PM, Sergio O. Fuentes <sfuentes AT UMD DOT EDU> 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
>