Good points, Bob. Some other thoughts: The FORCE option has no effect for additive options such as DOMAIN, INCLUDE, and EXCLUDE. If you think you might want to allow the individual system administrator some flexibility on what to include or exclude, omit it from the list.
Since the "include.systemstate" option was referenced, I also suggest reviewing the following "best practices" link related to backup of Windows system state. https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Storage%20Manager/page/Best%20Practices%20for%20Backing%20Up%20Microsoft%20Windows Regards, Andy ____________________________________________________________________________ Andrew Raibeck | IBM Spectrum Protect Level 3 | [email protected] IBM Tivoli Storage Manager links: Product support: https://www.ibm.com/support/entry/portal/product/tivoli/tivoli_storage_manager Online documentation: http://www.ibm.com/support/knowledgecenter/SSGSG7/landing/welcome_ssgsg7.html Product Wiki: https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Storage%20Manager "ADSM: Dist Stor Manager" <[email protected]> wrote on 2018-06-14 10:39:07: > From: Robert Talda <[email protected]> > To: [email protected] > Date: 2018-06-14 10:55 > Subject: Re: How to set default include/exclude rules on server but > allow clients to override? > Sent by: "ADSM: Dist Stor Manager" <[email protected]> > > Efim is correct, both about the force and about processing order. > I got ahead of myself. We built our client option sets to be as > inclusive as possible, within minimal include and exclude > statements, so that clients could override the behavior with > includes and excludes that got processed because there were no > conflicting server side options. Resulted in a blind spot in my > thinking - we haven’t had a customer need to override the management > classes provided. > > A possible alternative solution: create a separate domain with the > same management classes, but with different retention and storage > characteristics defined by those classes as needed. Then, assign > the nodes as needed to that domain. That is, get to the same > destination - system state information handled in a different manner > - by changing the underlying behavior of the assigned management > class, not the name > > FWIW, > Bob > > (And thanks, Efim, for catching my error!) > > > > Robert Talda > EZ-Backup Systems Engineer > Cornell University > +1 607-255-8280 > [email protected] > > > > On Jun 13, 2018, at 2:26 PM, Efim <[email protected]> wrote: > > > > Hi, > > parametr Force has no affect to include/exclude in cloptset. > > use q inclexcl client command to check resulting (cloptset > +dsm.opt) include/exclude in normal order (from top to bottom). > > You will find that server include/exclude processed first. > > Efim > > > > > >> 13 июня 2018 г., в 16:43, Genet Begashaw <[email protected]> написал (а): > >> > >> Thanks for your response, on the server side it was included by Optionset > >> with force=no, i tried to overwrite in the client side in dsm.optfile with > >> different mgmt class like shown below > >> > >> include.systemstate ALL MC-mgmt-name > >> > >> still did not work > >> > >> Thank you > >> > >> > >> > >> > >> > >> On Wed, Jun 13, 2018 at 9:37 AM Robert Talda <[email protected]> wrote: > >> > >>> Genet: > >>> > >>> For us it is simple: create a client option set with the list of > >>> include/exclude rules with FORCE=NO. Complexity comes from number of > >>> client options sets needed to support different platforms (Win 7, Win 10, > >>> OS X, macOS, various Linux destroys) and determining which client option > >>> set to assign a given node > >>> > >>> YMMV, > >>> Bob > >>> > >>> Robert Talda > >>> EZ-Backup Systems Engineer > >>> Cornell University > >>> +1 607-255-8280 > >>> [email protected] > >>> > >>> > >>>> On Jun 13, 2018, at 8:56 AM, Genet Begashaw <[email protected]> wrote: > >>>> > >>>> Thank you > >>>> > >>>> Genet Begashaw > >>> >
