Question

"Migrating" a large filesystem subclient to another new client.

  • 6 June 2023
  • 3 replies
  • 107 views

Userlevel 2
Badge +10

Background: I have a few Windows clients that are performing a lot of backups via subclients. Most of these are UNC paths, and some that are pointing to large file shares (some are 10-50 TB each).  We need to “migrate” from the clients being on 2012 Windows OS to 2019 Windows OS, and “just upgrading the OS” isn’t an option we have to stand up new 2019 servers and retire the old 2012 ones.  The storage policies for these subclients are tied to DDB’s for primary copies, and secondary/aux copies.

For each subclient on the old clients we want to retire: I want to just “deschedule” the old subclient, then make a brand new “identical” one with the same name and “path its backing up” on the new client (with all the same storage policies, filters, etc.).  Maybe take advantage of any “new” default settings on the subclient.  I will run a synthetic full at some point on this to make the last backup a ‘full’ to clean up storage.

I have read up a little on NDMP and other types of backups for these (and how some are uch more efficient/performant), but I’m not sure I’ll have time to get new things set up (I have to complete this in a few months, I am not the storage admin) and it would be more desirable to just “set up the new backups like the old ones” and determine a path forward for “new client/backup types” at a later date, afterI’m on 2019 and not under the microscope for OS migrations.

Question: Are there any gotchas for doing this? I don’t want something to “back up another full set of data” and not deduplicte it properly, blowing up a DDB or our storage.  I was under the impression as long as the storage policy was the same, and the “path being backed up” was the same, it didn’t matter which client (or backupset) backed it up it looked the same to the DDB’s and what’s put down on storage.


3 replies

Badge +15

I sort of follow what you are trying to accomplish here and the first thing I would do in this case is to make sure that the clients you are working are running Indexing V2.
There is a report you can use to determine that: https://documentation.commvault.com/11.24/expert/10756_reports_indexing_version_2.html

Aside from that, you can basically clone the subclient  A to client B and retain all configurations: Refer to

As for NDMP, I would spend some time and perhaps look in to backing up using CIFS which in my view is a lot easier and performs better.

Userlevel 2
Badge +10

From the report: The new and old clients are running V2 indexing.

From the link: If I’m reading this right, it appears there are 2 methods to “clone” subclients and their settings:

  1. There is a “Clone Client Data Set” workflow in the commvault store. It looks like this can only “clone” an entire backupset from “client 1” to “client 2”
  2. There is a command line/API using an XML config file. It looks like this can only clone subclients associated to the same client.

This leaves (for me) only option #1 as a potention solution posted to move (well, ok clone) subclients.  However, I did not mention that I’m trying to “split out” the subclients onto more servers (to be able to handle more load), essentially I’m going from 2 clients to 3. Using #1 does not work because it moves “the entire backupset” from client 1 to client 2 , And I want to clone/migrate them seperately to specific clients.

The plan is essentially:

OLD Client

  • subclient 1. Storage policy ABCD
  • subclient 2. Storage Policy HIJK
  • subclient 3. Storage policy WXYZ
  • (about 50 more subclients with these 3 storage policies)

NEW client 1

  • subclient 1. Storage policy ABCD
  • (and all the remaining subclients cloned/moved have this same ABCD storage policy, kept intact/no changes from the OLD client initial settings.)

NEW client 2

  • subclient 2. Storage policy HIJK
  • (and all the remaining subclients cloned/moved have this same HIJK storage policy, kept intact/no changes from the OLD client initial settings.)

NEW client 3

  • subclient 3. Storage policy WXYZ
  • (and all the remaining subclients cloned/moved here have this same WXYZ storage policy, kept intact/no changes from the OLD client initial settings.)

 

So if “cloning” an individual subclient to another client isn't possible, then I may be out of luck.

Additionally: if I DID clone the entire backupset, would this cause any issues on my storage (or DDB) sizes when the “new” cloned subclients run their first “full” backup?  My assumption is ‘no” as long as the storage policy (and the associated DDB) remain the same in the cloned subclient(s) but I hesitate to do a full backupset clone on 90TB of subclient backups if there’s a chance it will cause new storage/DDB growth due to a subclient “clone”.

Userlevel 2
Badge +10

I sort of follow what you are trying to accomplish here and the first thing I would do in this case is to make sure that the clients you are working are running Indexing V2.
There is a report you can use to determine that: https://documentation.commvault.com/11.24/expert/10756_reports_indexing_version_2.html

Aside from that, you can basically clone the subclient  A to client B and retain all configurations: Refer to

As for NDMP, I would spend some time and perhaps look in to backing up using CIFS which in my view is a lot easier and performs better.

“I would spend some time and perhaps look in to backing up using CIFS which in my view is a lot easier and performs better”. I will look into this as well, possibly for a secondary set of ‘cleanup/conversions” in the future.  thanks!

Reply