So, even though I made my change a month or so ago, unless I had actually backed up the file(s) in question they could potentially be in the wrong mgtclass? The rebind wouldn't occur until the file was actually touched?
Joe,
Files/data are not "in" a mgmtclass. It might be helpful to remember that the parameter of the copygroup which governs where the data gets sent during backup or archive is called "destination" and not "location". The destination parameter only affects the data when it is first sent to the server. Where the data goes after it gets to the server is governed by processes like stgpool configuration, stgpool backup, migration, reclamation, etc.
The rebind occurs on the next incremental backup after the updated policyset is activated. Changes in the retextra, retonly, verexists and verdeleted parameters will take effect immediately, but data that is already on the server does not get moved as a result of changing the managementclass to one that has a different destination that the storagepool where the data is currently stored.
To get (all of) the data where you want it to be, two options come to mind:
1) MOVE NODEDATA
(potentially a lot of time spent on the server,
depending on volume of data)
2) Rename the current nodes to <client>_old,
define new nodes with the same name as the original node,
and start off fresh with all of the data going to the
desired stgpool.
This potentially involves a lot of time sending data
across the network.There may be other approaches, but I'm not coming up with anything else at the moment.
HTH,
Ted
