commvault.com commvault.com

Reinstalling / Moving / Migrating Commvault to a new Domain & Hardware

  • 14 October 2021
  • 7 replies
  • 2424 views
B
Rank
Userlevel 1
Badge +7

Hi!

I am looking for any advice, tips, pitfalls to avoid, things we should consider and such, with regards to plans for getting from the current commvault installation, to a planned new commvault installation.

 

Current Installation:
5+ year old (but updated) installation, with 1 virtual commcell, and 4 physical media-agents, 2 in each datacenter. Physical HW for both the media-agents and the storage are reaching their EOL in 2022 and needs replacing.
The Commvault environment is currently in the production domain.

 

New Installation (planned):
New installation, with 1 virtual commcell (or possibly clustered?) and 4 virtual media-agents, 2 in each datacenter. 
The Commvault environment and the underlying virtualization servers for the Commvault CS/MA VMs should be in a completely separate domain from the production domain they are taking backups of.
New storage will be 25Gbps iSCSI (or NVMeoF or NVMe/TCP) based. 

 

Now, the question is i guess, what would be the most sensible way to get from A to B.

 

I am tempted to start with a clean slate, and install a completely new Commvault environment, and then "move" backup clients, 1 at a time, by stopping/disabling the schedule/jobs in the old environment. 
Then uninstalling the agent(s) & reinstalling the agents on a client and point it to the new solution, then make/define new jobs/Schedules for each client moved over. This will move the client to the new environment, but as i've understood it, we could still
do restores in the old environment, aslong as we restore to a different location/target.

Then move clients over one by one until all clients are controlled by the new installation.

Does this sound like a sensible plan, or are there other ways of doing this that would be better ?

Any advice, tips and such are welcome.

7 replies

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Hey @Bjorn M !  Thanks for the post!

Why not just move the CS database to the new environment as per the docs?

https://documentation.commvault.com/11.24/expert/4739_commserve_hardware_refresh_overview.html

Moving one by one, and maintaining 2 CCIDs is going to be a hassle when you need to do a restore and need to figure out which CommCell has the data you need.

From the client’s perspective, as long as the CS has the same name, is accessible, and has the database restored, they won’t know any different and life goes on.

You can then perform a name change across if you need to for setting a different domain:

https://documentation.commvault.com/11.24/expert/7022_changing_commserve_computer_name.html

 

Here’s one regarding moving to a cluster if you decide to do so:

https://documentation.commvault.com/11.24/expert/4788_move_non_clustered_commserve_to_microsoft_failover_cluster_setup.html

https://www.linkedin.com/in/michael-struening
B
Rank
Userlevel 1
Badge +7

Honestly, i have not decided on any way yet, currently just looking at different options, and trying to come up with a bunch of pros and cons for the different alternatives.

And perhaps just migrating the old commcell into a new VM/OS/Domain on new hardware, then add new VM-based media-agents, and “retire” the old physical media-agents is the easiest way to do this.

The environment is not a huge one, only about 200-300 VM’s and some physicals servers as virtualizations hosts or DB hosts and such, so keeping track of which installation has which data should be easy enough, and once the basic installation is in place, it should be fairly quick to move things over from old to new.

 

I guess the main reason i thought about setting up a “parallell” installation for a period of time before killing off the old one, is because i “inherited” the current installation, and there are a little bit of “clutter” in there, and i think it would be a nice learning-experience to start with a blank slate and configure everything from scratch, while also making some proper documentation about how & why things are configured the way they are.

 

One question with this idea as well though, is if something like that is allowed license-wise. 

 

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

I can definitely understand the issue with ‘clutter’, especially when it is inherited.  Perhaps a solution would be new Storage Policies, etc. but within the same CCID?

You hit on another valid point about licensing.  you can’t have 2 installs of the same license with the intent of having 2 prod environments, so that would be tricky as well.

https://www.linkedin.com/in/michael-struening
B
Rank
Userlevel 1
Badge +7

I can definitely understand the issue with ‘clutter’, especially when it is inherited.  Perhaps a solution would be new Storage Policies, etc. but within the same CCID?

You hit on another valid point about licensing.  you can’t have 2 installs of the same license with the intent of having 2 prod environments, so that would be tricky as well.

You mean move/restore it like described, then start making new policies and such, and slowly move things over ? I guess that is also an option. Would still have to clean up the old clutter one piece at a time then. Alternatively, get the new media-agents up and running on the old commcell, then do the move/restore perhaps. Many possible options & choices. 

 

As for licensing, the intent is not to have 2 production environments, as in, once everything is moved over, and retention has ran out, the original commcell servers would be permanently decommissioned. But for a short period, both would be running, though any client would only ever have active jobs/schedules on one install.

 

But yeah, that might be an issue with regards to licenses ? One option could be to use one of those 30 day trials, and then move the license once the trial is close to running out. Would be a bit shorter than the longest retentions, but i think i could get permission from management to bypass some retention during this processes.

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

You have it right.  Basically do a hardware refresh (so your db is one and the same), then slowly create new Storage Policies, etc. for your clients as you see fit and remove the old stuff as data prunes off.  It’s cleaner, and easier.

For the licensing, you could ask your Account Rep to split it out so you’d be able to share out the pieces, though I am not sure what is involved in making that happen AND balancing old and new.

I would just go the above route.  That way you can take your time with one pane of glass :nerd:

https://www.linkedin.com/in/michael-struening
B
Rank
Userlevel 1
Badge +7

Hi, looking at the description, and since the VM running the commcell would be a new VM in a new domain, the FQDN would be new, though the hostname/computername itself could probably be kept. Keeping the IP would have to be discussed with the networking guys, but i’m guessing it might have to change.

Now, by “Host Name” described below, are we talking FQDN, or just the computername ?

  • Hardware uses a different IP and Host Name for the CommServe host: Install the CommServe software, and then restore the database

    This method requires that you install the CommServe software, and then restore the database by using the CommServe Recovery Assistant tool.

    Use this method if the new hardware uses a different IP or host name than the old CommServe computer. Remember that the CommServe client name must be the same as the old CommServe client.

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

The FQDN, since that’s how clients and MAs communicate to the CS (by default).

https://www.linkedin.com/in/michael-struening

Reply


Terms & ConditionsCookie settings