Skip to main content

I’ve been tasked with upgrading our Commserve from v9.0.0 R2 to v11.32. Is there any specific upgrade path or can I jump directly to v11.32?  TIA

Look over all your client’s and the agents they run…note them down, note down the OS releases, and start validating which of those wil be able to be upgraded (or not) - as you may have legacy clients that may not be qualified - so those will need consideration before you jump in and start any sort of the process to upgrade your Commserve.

Check the 11.32 upgrade requirements documentation pages also.


This upgrade is something most experienced Commvault practitioners would not touch with a barge pole, and if you are doing it without a support agreement in place with Commvault then I would say you are insane. I say this not to insult you but to highlight the risky and mammoth undertaking this is.

My reasons for saying this are

  1. Commvault V9 went end of life April 1st, 2017, and V 10 December 15, 2017. What you need to remember is that Commvault stopped releasing Major Versions from Commvault 11, so in reality you are jumping a lot more than 2 versions. You most likely won’t have a supported upgrade path and anything you do will be unknown territory. This will be difficult and dangerous.
  2. Your Commserve will most likely require an Operating system, and SQL upgrade before you can do the commvault upgrade.
  3. Once you have upgraded the Commvault infrastructure servers, you will have a number of individual component upgrades to complete :DDB V5, Client V1 to V2 Index, to name but two, these post upgrade upgrades could take a significant amount of time.
  4. Because you are upgrading, you are going to have a number of inefficiencies that would not be present with a fresh install eg. upgrading to DDB5 and enabling horizontal scaling does not optimise the space savings for existing clients unless you remove them from the legacy DDB and readd them.
  5. You are going to spend a lot of time upgrading and configuring client agents. 
  6. You are going to introduce a whole host of new problems with the upgrade that you will need to address. Your production backup environment could potentially be in a less-than-optimal state for months, you may have a prolonged period of no backups.

 

An alternative approach would be doing a brand new CommVault install and migrating your clients to 11.32, (I would suggest staying with this version because going directly to 11:34 means you won’t get the Java console. 

Your existing environment would be kept for recovery only purposes

 

A good exercise would be to review your existing backup data that you keep for long term and identify how much of this must be kept and for how long. This will dictate how long you need to keep the V9 recovery environment. You may decide that it is worthwhile to export this data to another recovery solution so you can decommission the V9 environment faster.

 

Weigh up what benefits you will gain from an upgrade vs that of a new install.

 

 

 

 


This upgrade is something most experienced Commvault practitioners would not touch with a barge pole, and if you are doing it without a support agreement in place with Commvault then I would say you are insane. I say this not to insult you but to highlight the risky and mammoth undertaking this is.

My reasons for saying this are

  1. Commvault V9 went end of life April 1st, 2017, and V 10 December 15, 2017. What you need to remember is that Commvault stopped releasing Major Versions from Commvault 11, so in reality you are jumping a lot more than 2 versions. You most likely won’t have a supported upgrade path and anything you do will be unknown territory. This will be difficult and dangerous.
  2. Your Commserve will most likely require an Operating system, and SQL upgrade before you can do the commvault upgrade.
  3. Once you have upgraded the Commvault infrastructure servers, you will have a number of individual component upgrades to complete :DDB V5, Client V1 to V2 Index, to name but two, these post upgrade upgrades could take a significant amount of time.
  4. Because you are upgrading, you are going to have a number of inefficiencies that would not be present with a fresh install eg. upgrading to DDB5 and enabling horizontal scaling does not optimise the space savings for existing clients unless you remove them from the legacy DDB and readd them.
  5. You are going to spend a lot of time upgrading and configuring client agents. 
  6. You are going to introduce a whole host of new problems with the upgrade that you will need to address. Your production backup environment could potentially be in a less-than-optimal state for months, you may have a prolonged period of no backups.

 

An alternative approach would be doing a brand new CommVault install and migrating your clients to 11.32, (I would suggest staying with this version because going directly to 11:34 means you won’t get the Java console. 

Your existing environment would be kept for recovery only purposes

 

A good exercise would be to review your existing backup data that you keep for long term and identify how much of this must be kept and for how long. This will dictate how long you need to keep the V9 recovery environment. You may decide that it is worthwhile to export this data to another recovery solution so you can decommission the V9 environment faster.

 

Weigh up what benefits you will gain from an upgrade vs that of a new install.

 

 

 

 

I should add. Currently, we are not actively using Commvault for backups. We migrated to another product. The instance we have up is solely for restores.


Reply