Skip to main content
Solved

question on DDB re-baseline after migrate server to a new hardware


Forum|alt.badge.img+13

Hello Community,

 

We’re going to migrate file servers to different hardware with new hostname, while keeping the same drive letter, data/content.

Subsequently, once these new servers install/config into the Commvault, they will be linked to the identical storage policy that the old servers were associated with. This storage policy with ddb enabled

From my understand, Commvault's deduplication process use a SHA-512 algorithm, which generates a unique identifier for each data block. This identifier is then matched against identifiers of previously encountered data blocks.

 

Questions:

  1. I'm wondering whether, during the initial full backup of the new file servers, the data will undergo a process of re-baselining, or if only distinct data blocks will be selected for backup. This consideration arises from the fact that the same content and deduplication (ddb) signatures were previously backed up or generated from the old servers. Moreover, this inquiry leads to the question of whether the new full backup will make use of the ddb signatures from the old server's data blocks, or if it will generate new ddb signatures/re-baseline, given that this is a new server.
  1. Additionally, is there a method/formula  available to estimate the expected storage space needed for the new file servers when taking deduplication into account?

 

thanks

Best answer by Scott Moseman

Yes, the new server backup will utilize the existing hashes/deduplication.  It’s the blocks of data which get hashed and deduped, it doesn’t matter which server they’re coming from.

Thanks,
Scott
 

View original
Did this answer your question?

Scott Moseman
Vaulter
Forum|alt.badge.img+18

Yes, the new server backup will utilize the existing hashes/deduplication.  It’s the blocks of data which get hashed and deduped, it doesn’t matter which server they’re coming from.

Thanks,
Scott
 


Forum|alt.badge.img+13
  • Byte
  • August 30, 2023

thanks @Scott Moseman 

 


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