commvault.com commvault.com
Solved

Migration of Indexing v1 to v2 for multiple pseudo-clients targetting the same VCenter

  • 15 July 2021
  • 4 replies
  • 1589 views
L
Rank
Userlevel 6
Badge +15

Hello !

There are many helpful links and docs about VSA Indexing v1 to v2 migration, requirements and post-migration tasks.. 

But as of now, I have not yet found the answer to my question regarding my environment.

 

 

We have a single VMWare VCenter, lets call it VCENTER.

This single VCENTER server manages multiple locations, like USA, CANADA, INDIA, etc.., where each time we have a corresponding VMWare Datacenter, with ESXes, VMs we need to backup, and MAs.

 

In our Commvault environment so far, for internal reasons, I have created a VMWare Pseudo client for each location, like :

VCENTER-USA

VCENTER-CANADA

VCENTER-INDIA

 

Each point to the same VCENTER, but the VSA configuration for proxies, SPs and target VMs to backup are different as they’re pointing to the servers for each location.

They were all created using indexing v1.

So far I can only migrate using the indexing v1 to v2 workflow.

My question is, is it possible to update only 1 of those pseudo client, like VCENTER-INDIA, AND to not affect the other VCENTER clients ? Or would the upgrade affect the real Vcenter and then all pseudo-clients will be upgraded ?

 

I do not want to have to reconfigure the schedules of all the other countries, but migrate them one by one, carefully, at least.

 

Thanks for any feedback you would provide :wink:

icon

Best answer by Laurent 15 July 2021, 17:25

View original

4 replies

MichaelCapon
Rank
Userlevel 6
Badge +14

Hi @Laurent ,

 

The upgrade process would be performed per Virtualisation Client “PseudoClient”, so I believe that this should not affect the other VMware Virtualisation clients if you only run it for one of them.

 

Best Regards,

Michael

A
Rank
Userlevel 2
Badge +3

@Laurent Whats your reasoning to move to vsa v2? Are you facing any issues with VSA v1? 

D
Rank
Userlevel 4
Badge +8

Hello @Laurent 

To determine whether you would be a good fit for v2 indexing can you answer the following questions?

 

1. Do you have an backup or auxiliary copy issues with your VMware, Amazon or Azure VSA backups today?
(i.e. backups not completing, aux copies not completing)
2. Do you utilize Synthetic Fulls today, and if so are they completing within your required nightly backup window?
3. Do you perform granular file/folder recoveries for your VMware, Amazon, or Azure VSA backups today?
4. When performing granular file/folder recovery do you opt to index during backup time (i.e. tape environments, collect metadata) - or do you utilize Live Browse?
5. Do you send any of your backups directly to tape or cloud archive storage libraries?


For a comparison between V1 indexing and VM Centric operations (V2) [CLICK HERE]

 

Should I transition to VM-Centric Hypervisors?

"If you give a man a fish, you feed him for a day. If you teach a man to fish, they will probably burn your spot"
L
Rank
Userlevel 6
Badge +15

@Laurent Whats your reasoning to move to vsa v2? Are you facing any issues with VSA v1? 

Well mostly the multi stream restore ability per vmdk is the point that would encourage me to move to indexing v2. In normal conditions, I would not really care, but I let’s say I had to face a massive lot of VMs to restore, and with v1 it took way too long (always too long in such case), with big VMs with lots of VMDKs  each.. Indexing v2 should provide ability to speedup those restores with 1 stream per VMDK instead of 1 stream per VM.

Weekly Synthfull jobs of huge VMs with many VMDKs are also running long.

Also, not to blame/name people, I would say that in a report audit lead by an external company, it was mentionned to use indexing v2 instead of v1. When top managers read this, they won’t know the technical of functional points beyond the change. They would just ask for me to follow this recommendation..

So, I wanted to make sure that I could implement this in a part of my environment without affecting the rest of the environment, managed by the same hypervisor server, to check the behaviour and results.

 

Hello @Laurent 

To determine whether you would be a good fit for v2 indexing can you answer the following questions?

 

1. Do you have an backup or auxiliary copy issues with your VMware, Amazon or Azure VSA backups today?
(i.e. backups not completing, aux copies not completing)
2. Do you utilize Synthetic Fulls today, and if so are they completing within your required nightly backup window?
3. Do you perform granular file/folder recoveries for your VMware, Amazon, or Azure VSA backups today?
4. When performing granular file/folder recovery do you opt to index during backup time (i.e. tape environments, collect metadata) - or do you utilize Live Browse?
5. Do you send any of your backups directly to tape or cloud archive storage libraries?


For a comparison between V1 indexing and VM Centric operations (V2) [CLICK HERE]

 

Should I transition to VM-Centric Hypervisors?

 

  1. No.
  2. Yes, sometimes Synthfull, but I would not consider it as an issue yet. Maybe more as a potential speed improvement as with our growing environment it could affect our global performance.
  3. Yes, from my primary and secondary online copies (frequent), and sometimes from a copy to AWS S3-IA (rare) or even from Glacier (very rare) 
  4. Live browse is used, as when we backup we want it to be as fast as possible.
  5. Never directly yet. Disk is always used as primary and (mostly) secondary. Only 3rd copy is Tape or/and Cloud then Cloud Archive(Glacier).

Thanks to all of you ! I know it’s a bit tricky, and not a black/white topic as there are pros and cons depending on the environment and usage.

 

The list of Knows issues here is a bit scary, I’d say, from my understanding.. But I need to practice (and your advices/experiences :wink: ) to get into it and know how it behaves..

Reply


Terms & ConditionsCookie settings