Skip to main content

Hey everyone, so as the titles states we are running Commvault 11.20.82 on win 2012 R2. Right now we are just considering doing the OS upgrades as 11.20 is still LTS until 2025; but if there is simple way to do them both without breaking anything that would be great.

 

From what I understand this is an agentless setup, with Commvault talking to the hypervisor/vcenter, and the server being a VM itself backing up to netapp storage.

 

Let me know what you guys think would be the best way forward or point me in the right direction.

Hi @ComBak so you are considering an in-place upgrade of the OS to a newer version? Is it a psychical system or virtual? Because, although it is supported to perform an in-place OS upgrade you can never get the guarantee that it will not break anything. So, running it virtually at least allows you to create a snapshot of the VM before starting the upgrade so you have a way to go back easily. 

Not sure how big you environment, but as for running the FR20 LTS release I would strongly consider moving to FR24 or even FR28, who are both LTS. By sticking to FR20 you miss a lot of enhancements and updates, especially when it comes to the support of newer application versions. 


@Onno van den Berg Thanks for your response. It is a VM so we are planning to take a snapshot before the in place upgrade. I was just wondering other than killing all jobs is there anything else I'm missing?

 

We do plan to upgrade the feature release absolutely. I just took over this project so I am familiarizing myself before any big changes so I don’t break anything.

I always welcome any additional comments or recommendations you might have.

 

Thank you.


Hi @ComBak 

When unfamiliar with the upgrade process I would advise to run a test upgrade first to see and learn about what is happening (if time/planning allows it of course).

I would personally:

  • Inventory all packages installed on current Commserve
  • Inventory current Commserve requirements (disk, mem etc)
  • Prepare a new VM on a current OS based on Commserve requirements
  • If needed prepare any infra firewall/network acl/routing changes for the new VM to allow needed CV communications
  • Install current Commvault version on new server with packages defined from inventory performed
  • Halt all backup activity on the current Commserve
  • Make a DR backup on current Commserve
  • Transfer the DR backup to the new server
  • Recover the DR backup using the CSRecoveryAssistant (this assistant will update the imported SQL DB automatically to match the new CV version)
  • Check if all is working as expected
  • If this is the final migration of the Commserve then:

This way you can enjoy the shiny and new:

  • OS version
  • SQL version
  • Commvault version

Then:

  • Update the media agents, and 
  • Update the clients.

If all fails you still have your existing Commserve to fall back to 😉

Hope this helps 🙃


I would also always go for an approach to build it up from scratch instead of performing an in-place upgrade of a Windows Server version that old and thanks to @Jos Meijer for giving a very detailed overview which steps it takes it also shouldn't be a very difficult task ;-) 


Thanks @Onno van den Berg @Jos Meijer. As I mentioned before, I'm really unfamiliar with Commvault and the guy that transferred it to me said it wasn’t very user friendly. I really like the idea of going all the way to the newest version of Win Server and Commvault.

 

The steps you outlined does look simple enough for an experienced Commvault user, but I honestly wouldn’t know where to start so I have to do a bit more reading. This was the reason we were just planning to do an in place upgrade of the VM to keep it as simple as possible, as we have the setup in 4 different instances (although the same config, 2 stage/2 prod). I was going to try it on staging and then go from there.

 

Thanks again for all your help.


Well in all honesty the upgrade path by performing an in-place upgrade does look like the easiest way and fastest way, but it can also lead to unpredictable issues even after some time. Also, if you are not so experienced with Commvault than I would definitely try to make some time/room for yourself to use this migration to become more familiar with it. Having to take over the work from someone else can be very challenging just because you miss all the history. This opportunity gives you the ability to start from scratch and also build the environment with todays threats in mind. 

You can test this migration very easily using a DR copy in an isolated environment. 


@Onno van den Berg that sounds like a good plan. I’m assuming I would follow the steps listed here DR Backup, and then follow the steps you listed above.

So basically

  1. Inventory all packages installed on current Commserve - am I just checking programs etc. to see what’s installed or there is a specific area? it seems most are installed by default anyway Packages
  2. Inventory current Commserve requirements (disk, mem etc) - The requirements should be similar but i’ll double check
  3. Prepare a new VM on a current OS based on Commserve requirements - Should be easy enough in VCenter
  4. If needed prepare any infra firewall/network acl/routing changes for the new VM to allow needed CV communications - This is on a internal network so I'll check how it was setup previously. Is there a process where I can use the same name\ip when I decommission the old one (after I make sure it’s working of course).
  5. Install current Commvault version on new server with packages defined from inventory performed - I’ll download the files as the server is not connected to the internet directly
  6. Make a DR backup on current Commserve
  7. Transfer the DR backup to the new server
  8. Recover the DR backup using the CSRecoveryAssistant (this assistant will update the imported SQL DB automatically to match the new CV version) - CSRAssistant guide?
  9. Check if all is working as expected

Again, I really appreciate all the help.

 


Looks pretty complete to me! Have fun!


Reply