Now, I have read that the new retention settings would only have taken
effect when the files were actually being incrementally backed up and thus
the client would see that they no longer existed them and expired them with
the new retention settings.
Farren,
As your situation stands now, you are correct. Inactive objects without a
corresponding active version can not be re-bound to a new management class.
There are a couple of possibilities to release the relocated data, but they
all have the end result of deleting historical data for the client
prematurely. Think about how much storage is really being
"hogged". What is the auditoccupancy of the node in question? Is your
server really so constrained that you can't afford to let the data expire
"naturally"?
If you choose to act on any of these options, be careful of what you are
doing...
### *** Proceed with caution *** ###
### *** Double-check before executing *** ###
It would theoretically be possible to create dummy (zero-length) files to
"stand in for" the old files, then back them up incrementally to re-bind
them to the new MC. Depending on the number of files involved, actually
doing this would probably be prohibitive in terms of the time required.
The other possibility that I can think of is to re-define the policies for
just that node:
1) Create a new policy domain by copying the
policy domain that the node is currently in,
2) Modify the management classes in the *new* domain
to retain the data for however long you wish
3) Activate the updated policyset in the new domain
4) Update the node so that it is assigned to the new domain.
5) Run expiration. The "excess" versions should be dropped.
6) After expiration completes, update the node
so that it is assigned back to the original policy domain
7) Ask your system admins to let you know in advance
before doing re-orgs, so that you can plan how
to handle the old data.
OK, it may not make any difference,
but at least you've spoken up ;-)
-Ted
|
