I’m going to guess nobody has contemplated this unless they’ve been with Commvault for eons, but here’s the situation and end-state goal:
We have been archiving files on a couple 2 node clusters running on RHEL for years. The cluster consists of multiple virtual clients(each per application group) and the nodes participating in the cluster use the sVCS_SUPPORT reg key to know there’s plugins and such, and to know who owns what. As part of “reducing complexity”, costs, etc., we need or prefer to remove the clustering components.
The HW and OS’s are obsolete so migrating the apps and data to new systems but retaining identical names and IP’s. Archiving works well so want to keep stubs as stub if at all possible.
The new (destination) servers have new OS’s and no Veritas at all.
Rather than rehydrate/recall all the stubbed content, is it possible to simply shutdown old systems, bring up new, and if the new hosts have the same hostname as the old (and obviously the filesystem agent on it), will the previous “virtual clients” still be able to work from a recall perspective or is this impossible?
In the past when we moved from platform to platform, since VCS was in play and the hostnames matched, the migration wasn’t too bad if done right, but I cannot find any sort of pages which explain this type of migration. Avoiding mass recalls is obviously preferred and given the sizes of each subclient being archived, consolidating them down to a “new” client with no per-subclient disk cleanup enabled doesn’t seem feasible at all. Restoring this much content on migration day (say from old backup to new standalone box) would take a day at best, and the app can’t be down for that much time.
There’s more to it than this but the gist of it is that.
thanks