Changing the management class will cause all ACTIVE files to be rebound the
next time a backup occurs.

It won't cause any massive overhead (you'll get a LOT of entries in the
scheduler log showing the rebinding has occurred, but it looks a lot worse
than it is).  It won't cause additional backups to occur.  But, it won't
cause your existing backup versions to move to new storage pools, either.

You can't do what you want to via reclamation, because reclamation only
occurs WITHIN a storage pool.


> -----Original Message-----
> From: Steven Bridge [SMTP:ccaasub AT UCL.AC DOT UK]
> Sent: Monday, July 03, 2000 12:33 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Colocation and rebinding
>
> >personally I'd use #2
> >where I'm at we can't baby-sit the clients and what if a client adds a
> new
> >file space and forgets to update the inclexcl to bind it to the
> collocated
> >mgmtclass... (trust me it will happen)
> >So your option #2 eliminates any problems from such an event.
> >
>
> Fortunately, my large clients that I'm considering colocating are under my
> control ( wearing my filestore administrator hat ) and the inclexcl file
> is appropriately wild-carded to include any new user areas. So this is
> not such a concern here.
>
> Allen S. Rout has described a procedure ( Thanks for that ) for using
> 'move data' to re-assign pre-change data to co-located storage pools.
> But with between 100 - 400 GB data per node spread over 50 tapes - I was
> hoping for a less labour and time intensive procedure using the
> automatic daily reclaim.
>
> It would appear that switching domains would not allow this option -
> but it is unclear whether switching management classes as in my first
> option also forces me to use the 'move data' technique. Or whether this
> has any other ramifications - the manual implies that the files would
> be rebound to the new management class - but does not give any further
> details concerning the consequences of this.
>
> >> I am considering the possibility of colocating the backups of nodes
> >> that have up to now not been colocated.
> >>
> >> The problem is that I only want to colocate some of the nodes within an
> >> existing policy domain - therefore I cannot simply update the copy
> group
> >> to a new storage pool destination.
> >>
> >> I can see two options :
> >> (1) Create a new management class the same as the existing default used
> >>     but with a different destination in the backup copygroup, and
> update
> >>     the client exclusions files on the nodes that I wish to colocate to
> >>     use the new management class.
> >> Or
> >> (2) Copy the policy domain to a new one but within this change the copy
> >>     group destination within the default management class, and then
> >>     update the nodes that I wish to colocate so that they are
> associated
> >>     with the new domain.
> >>
> >> What I'm not sure of is how either of these changes will affect all the
> >> backups that already exist for those nodes. Will they be rebound to the
> >> new management class ? Will this impose a massive overhead at the next
> >> backup ? Will they still be accessible or will new backups be triggered
> ?
>
> +----------------------------------------------------------------------+
>  Steven Bridge     Systems Group, Information Systems, EISD
>                           University College London
>  email: s.bridge AT ucl.ac DOT uk                   tel: +44 (0)20 7679 2794