Skip to main content
Solved

Migration to Commvault V2 Indexing - Seeking Advice and Best Practices

  • December 2, 2024
  • 2 replies
  • 92 views

Forum|alt.badge.img+1

Hello Commvault Community,

We are planning to migrate to the latest Commvault version, which no longer supports V1 indexing. As we prepare for this transition, I would like to gather insights and advice from those who have already gone through this process.

Questions:

  1. What are the essential steps to ensure a smooth migration from V1 to V2 indexing?
  2. What are the critical considerations to keep in mind during the migration?
  3. Are there any known issues or pitfalls that we should be aware of?
  4. What best practices can you share for managing the migration effectively?

Any detailed experiences, tips, or documentation links would be greatly appreciated. Thank you in advance for your support and guidance!

Best answer by Wasim

Hi ​@Jakub.K,

 

Good day,

 

Whenever installing or reconfiguring a MediaAgent, ensure proper index cache sizing by verifying that the volume hosting the index cache has sufficient disk space. The following table shows recommended minimum system and hardware requirements for the MediaAgent

https://documentation.commvault.com/2024e/expert/system_and_hardware_requirements_indexing_version_2.html

 

If there are clients in your CommCell environment that were installed prior to Version 11, then you can migrate the associated subclients to Indexing Version 2 using the Upgrade to IndexingV2 workflow.

Note

  • During the migration process, the last cycle of backup data is converted to Indexing Version 2. Therefore, you can continue running incremental backups on subclients after migrating them to Indexing Version 2 (that is, you do not need to run a full backup as your first backup job after the migration).

 

File System Clients

Indexing Version 2 is enabled by default when you add a new file system client in a new Commvault deployment. However, you can use this workflow to migrate any clients that were installed during a previous Commvault release.

Clients will continue to use Indexing Version 1 until you migrate the agent software to the latest version.

 

Virtualization Clients

There is a separate workflow used to migrate virtualization clients and VSA. For instructions about updating virtualization clients, see Migration of Virtualization Clients to Indexing Version 2.

 

Database Clients

For PostgreSQL agents, Indexing Version 2 is enabled by default for newly installed clients in Feature Release 11.20 and more recent versions.

For an IntelliSnap or a block level enabled PostgreSQL client, before migrating to Indexing Version 2 run a backup copy of all IntelliSnap or block level snap jobs.

 

Supported Agents

For a list of agents that support Indexing Version 2 for new and the Upgrade to IndexingV2 workflow, see Agents that Use Indexing.

 

Limitations

The Upgrade to IndexingV2 workflow cannot migrate a client computer to Indexing Version 2 if it meets any of the following conditions:

  • There is no valid license for a client.

  • A backup set on the client computer does not have a schedule.

  • The client is deconfigured.

  • For PostgreSQL agents, the following conditions must be met:

    • The CommServe must use Version 11 SP14 or a later version.

    • Installing Commvault Platform Release 2024 (11.34) or above on the CommCell Console environment will upgrade PostgreSQL agent from Indexing Version 1 to Indexing Version 2.

    • The PostgreSQL client cannot have any currently running jobs. If it does, the workflow will skip the client, and the client will not be changed to Indexing Version 2.

https://documentation.commvault.com/2024e/expert/migration_of_clients_to_indexing_version_2.html

https://documentation.commvault.com/2024e/expert/migrating_clients_to_indexing_version_2_on_command_center.html

https://documentation.commvault.com/2024e/expert/migrating_clients_to_indexing_version_2_on_commcell_console.html

 

Best Practices (Indexing Version 2)

https://documentation.commvault.com/2024e/expert/best_practices_indexing_version_2.html

 

FAQ (Indexing Version 2)

https://documentation.commvault.com/2024e/expert/faq_indexing_version_2.html

Regards,

Wasim

 

View original
Did this answer your question?

2 replies

Forum|alt.badge.img+7
  • Vaulter
  • 90 replies
  • Answer
  • December 3, 2024

Hi ​@Jakub.K,

 

Good day,

 

Whenever installing or reconfiguring a MediaAgent, ensure proper index cache sizing by verifying that the volume hosting the index cache has sufficient disk space. The following table shows recommended minimum system and hardware requirements for the MediaAgent

https://documentation.commvault.com/2024e/expert/system_and_hardware_requirements_indexing_version_2.html

 

If there are clients in your CommCell environment that were installed prior to Version 11, then you can migrate the associated subclients to Indexing Version 2 using the Upgrade to IndexingV2 workflow.

Note

  • During the migration process, the last cycle of backup data is converted to Indexing Version 2. Therefore, you can continue running incremental backups on subclients after migrating them to Indexing Version 2 (that is, you do not need to run a full backup as your first backup job after the migration).

 

File System Clients

Indexing Version 2 is enabled by default when you add a new file system client in a new Commvault deployment. However, you can use this workflow to migrate any clients that were installed during a previous Commvault release.

Clients will continue to use Indexing Version 1 until you migrate the agent software to the latest version.

 

Virtualization Clients

There is a separate workflow used to migrate virtualization clients and VSA. For instructions about updating virtualization clients, see Migration of Virtualization Clients to Indexing Version 2.

 

Database Clients

For PostgreSQL agents, Indexing Version 2 is enabled by default for newly installed clients in Feature Release 11.20 and more recent versions.

For an IntelliSnap or a block level enabled PostgreSQL client, before migrating to Indexing Version 2 run a backup copy of all IntelliSnap or block level snap jobs.

 

Supported Agents

For a list of agents that support Indexing Version 2 for new and the Upgrade to IndexingV2 workflow, see Agents that Use Indexing.

 

Limitations

The Upgrade to IndexingV2 workflow cannot migrate a client computer to Indexing Version 2 if it meets any of the following conditions:

  • There is no valid license for a client.

  • A backup set on the client computer does not have a schedule.

  • The client is deconfigured.

  • For PostgreSQL agents, the following conditions must be met:

    • The CommServe must use Version 11 SP14 or a later version.

    • Installing Commvault Platform Release 2024 (11.34) or above on the CommCell Console environment will upgrade PostgreSQL agent from Indexing Version 1 to Indexing Version 2.

    • The PostgreSQL client cannot have any currently running jobs. If it does, the workflow will skip the client, and the client will not be changed to Indexing Version 2.

https://documentation.commvault.com/2024e/expert/migration_of_clients_to_indexing_version_2.html

https://documentation.commvault.com/2024e/expert/migrating_clients_to_indexing_version_2_on_command_center.html

https://documentation.commvault.com/2024e/expert/migrating_clients_to_indexing_version_2_on_commcell_console.html

 

Best Practices (Indexing Version 2)

https://documentation.commvault.com/2024e/expert/best_practices_indexing_version_2.html

 

FAQ (Indexing Version 2)

https://documentation.commvault.com/2024e/expert/faq_indexing_version_2.html

Regards,

Wasim

 


Forum|alt.badge.img+1
  • Bit
  • 2 replies
  • May 15, 2025

Hi Jakub,

We also did this recently for a couple of VSA clients that were still on Indexing V1.

Th initial attempt to run the Commvault provided “VSA V1 to V2 migration” workflow failed because of a cryptic authentication error.

The only clue as to what the failed authentication might relate to was that when we attempted to manually create new V2 Indexing VSA clients from scratch with different names, the backup account reported some missing permissions when the credentials were entered into the new VSA client VMWare instance configuration.

I captured the warning about possible missing permissions for the VSA backup account and had them checked and these were indeed found to be new and therefore missing from the backup accounts permissions. 

After the missing permissions were added, I retried the “VSA V1 to V2 migration” workflow and this time it completed and so I could then retire the old “_V1” named VSA clients.

Spot-checked the new V2 VSA clients and subcleint configurations, and these seemed mostly right, but I think there was one or two settings that didn’t get migrated which I manually corrected, so please do spot-check everything.

Only thing is that you lose the backup history of the previous V1 indexing VSA backup subclients, so you have to be aware that for browsing backups of your VMs older than the date of the migration workflow being run you need to refer to the original “_V1” client that you will retire, and then refer to the new V2 instances for the latest backups.

Also confusing is how each VM backed-up by your VSA subclient gets a unique Backup Job ID in addition to the master backup job for the subclient so that takes some getting used to.

I only had a small number of file iData clients on V1 indexing that also needed to be upgraded using the original “Upgrade to IndexingV2 workflow”, and from memory that workflow completed without issue so I was able to run a first Full backup of the file subclients afterwards to baseline the indexes.

That said, I don’t know for sure from the online documentation if the V1 indexing of file and other iData agent workloads prevents upgrading Commvault, but the VSA client definitely are not supported on the latest LTS release so they had to be migrated before the upgrade.

Since the new VSA V2 clients effectively become new clients with a clean backup-history, the first scheduled backup of them should default to a first baseline Full backup, so do be aware of the time/impact of this to your VM and backup window.

Good luck,


Michael

 

​​​​​​


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings