Hello Klaus,
Storage Pool can’t be changed after creation on a copy however you can delete the primary snap copy then recreate it with the correct storage pool.
Hi Jon,
not quite, what I’m looking for.
If I delete the snap primary, all exsiting backup (snapshots) are aged / deleted as well.
In my case this holds ~1800 VM Snapshots / day for 7 days.
I don’t want to delete them, but change the data path for the meta data of new snapshot backups.
If I was able to add additional data paths, I could simple mark the current as readonly and after 7 days, I could remove them.
Hi Klaus,
Do you have a backup copy you are offloading these to?
It is not possible to change the pool. If you have a pool with multiple libraries, you could change it.. but that doesn’t apply in this case.
Hi Jon,
yes, I do create backup copies of these jobs.
But the snapshots should be maintained.
If I’m not able to modify the data paths of a snap primary, I’m not really able to migrate my backup hardware.
The initial Storage Pool will remain active as long as I have a snap primary active.
While primary copy and secondary copy can be renewed without any problems at any time.
My fault obviously has been to use the same Storage Pool for snap primary as for primary copy
This also happens when you create a plan. Once created you never get rid of it without starting from scratch.
This means, the only way is:
- to create a new Storage Pool (nonDedup),
- to create a new Storage Policy pointing to my
- currently used storage pools for primary and secondary copy
- the non dedup pool for the snap primary. (since this has no DDBs, I could easily migrate)
- to change Storage Policy assignment for all associated subclients and continue to backup into the new storage policy. To meet retention expectations, I need to to this on the day of the monthly full.
- after only one year (extended retention on monthly backups), I’m able to clean up and delete the currently used storage policy.
all this is only possible, if the java gui is still available by then.
Otherwise I don’t see, how to achieve all these steps ……
Hmm…
We can always give you access to the java gui if you open a support ticket. I have not heard any definitive timeline when it will be removed completely from the product. It won’t be until all functionality is available in Command Center.
I tested this in staging and only way I could do it is either delete/recreate snap copy or new storage policy.
I thought if you could sync the snapshots to the backup copy completely you could simply remove and readd the primary snap copy , taking new snapshots after. If you can’t do that then only other way is new SP.
Thanks Jon,
I think I have to accept, that the current version(s) of Commvault software allows less flexibilty as previous releases, when it comes to Storage Pools and Plans, compared to Storage Policies and Schedule Policies.
While it is easy to change the destination for Backup/BackupCopy and Secondary copies by adding a new secondary and promote it to primary, this is not really possible for the meta data of Snap Primary and Snap Secondary within a Storage Policy.
Just adding additional storage to the (dedupe) Storage Pool, automatically selected when creating a plan, does not help me to get rid of the DDBs associated with the Pool. I’m also not able to convert the dedupe pool in a non dedupe pool, which in my case would also be a valid solution.