Hi Commvault People,
I have a tidying up exercise to do, which will ultimately involve this:-
1 - Decommission two MA’s currently working as partitioned dedupe (lets call, them MA3 and MA4)
2 - Migrate workloads to remaining MA’s, also with their own partitioned GDSP configs.
Lets call them MA1 and MA2.
3 - Noting that Storage Policies on MA1\MA2 versus MA3\MA4 have very different retention.
I know that generally speaking, you can easily reassociate to another SP and away you go, but that’s only useful if you have matching retention.
The issue I have is that my MA3 and MA4 Storage Policies (whose ma’s I want to retire) are set to Infinite retention. The Storage Policies on the remaining ma’s (MA1\MA2 are not).
So If I want to migrate the workloads away from MA3 and MA4, is it possible to somehow keep the Storage Policies in tact that were previously associated with MA3 and MA4. I would prefer to keep them in tact to avoid yet more legacy and historical SP’s clogging up the environment. And given that the retention is infinite, they will be around forever.
I suppose what I night need to do, is add a second library to the MA3\MA4 GDSP, which is the same library used by MA1\MA2. Therefore when the MA3\MA4 library is decommed the SP will continue to write to MA1\MA2.
That raises two questions:-
1 - Is that possible? Can I add a second library to an existing GDSP.
2 - What do I do about DDB migration?
Question 2 “What do I do about DDB migration” is also very interesting.
Not being satisfied with wanting my MA3\MA4 Storage Policies to remain in tact, I also don’t want to bring across the MA3\MA4 ddb’s. And the reason for that, is that the extra workload from the MA3\MA4 jobs can easily be accommodated in the MA1\MA2 DDB’s.
Similarly, if I bring across the DDB’s from MA3\MA4 it means I need to find volumes to host them, and it will almost certainly have a negative impact on the MA1\MA2 DDB’s and their Q&I times.
My closest solution so far is to:-
1 - Associate MA3\MA4 clients to the MA1\MA2 Storage Policies.
2 - Create a new Copy on one of the MA1\MA2 Storage Policies and assign infinite retention
3 - Assign MA3\MA4 clients to new SP Copy.
4 - Migrate the DDB’s from MA3\MA4 but only select “change config only”.
I think this would take it pretty close, however, there are a couple of things I don’t like:-
1 - Once you have a “selective” copy on a Storage Policy, no clients are ever added to any of the copies in future. This is a big gotcha for the unsuspecting and I have been backups without a copy for this reason. It is far more practical to leave Storage Policies which add all clients to a secondary copy automatically.
2 - Impact on migrating the GDSP DDB’s from MA3\MA4 but selecting “change config only”.
I know we don’t need the DDB’s for restoration purposes, but is there any downside to this action?
Soz for such a big question, but if anyone has had a similar situation or maybe one of the Commvault people could chip in then that we help a lot.
Best answer by Vaidotas TamasauskasView original