commvault.com commvault.com
Question

Moving archive(stub) data from VCS cluster to standalone non-Veritas client

  • 4 April 2024
  • 2 replies
  • 19 views
downhill
Rank
Userlevel 2
Badge +7

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

2 replies

A
Rank
Userlevel 5
Badge +12

Hello @downhill 

If you were migrating from VCS > VCS there might be way to get around rehydrating the stubs but given the fact you are looking to move away from Veritas i do not think there is a way around it.

The action i would take here is to rehydrate first and then do the migration steps and then re-stub the data.

Kind regards
Albert Williams

The best way to learn anything, is to question everything
downhill
Rank
Userlevel 2
Badge +7

@Albert Williams so as I understand it, while stubs can be restored to other systems and those stubs will recall data, the fundamental problem with that idea is that the backing data is captive to the VCS clients which archiving occured on correct? So the only way to seemlessly move all those stubs is if in the case of VCS virtual clients, the hostname is changed to the new hostname, etc. 

But since we’re going from non-VCS to standalone physical, even though the names of the hosts will remain the same, the probability of this working is small? We currently don’t have a way to easily reproduce this as the systems are heavily used, so swapping names on machines even with DNS trickery is risky. 

However, I did look a bit closer and from some support case we worked years ago, I remember them telling me to set the sVCS_SUPPORT reg key to No. 

I believe that disables the cluster plugins or some interaction with VCS if recalling correctly. It makes me wonder if we kept the “shell” virtual clients and simply leave things-as is on the new non VCS client if things would continue working without needing to rehydrate it all, copy, mirror, etc. Basically the applications moving to the new systems would still use the same FQDNs for the VIPs per “the old VCS app groups” but the Veritas parts are gone. Guess I’m wondering out loud if there’s anything really “special” about the virtual clients other than you tell it which nodes are in the cluster? Since the VCS Support key says No and has for years yet things keep working, maybe this won’t require full recalls and all that?

thanks

Reply


Terms & ConditionsCookie settings