Hi Commvault people,
I am looking for some advice on a recent volume migration, and Commvault’s behaviour afterwards.
So we basically upgraded a large fileserver. 60 TB of data across several volumes.
The data on “Server 1” is already under dedupe.
When we migrated the volumes to a “Server 2”, although we are obviously creating new subclients, and we have to kick-off new fulls, I was surprised to see these new backups writing large amounts of data.
Previously, we were writing minimal amounts of data, literally a few GB’s, despite the volumes being around 15TB (very small rate of change).
Given that dedupe is in play, and we already have the blocks of data held in the store, then why are we writing so many new blocks? To put this in context, we are writing maybe 30% of the application size, which is a few TB’s, compared to the previous few GB’s.
Hopefully that makes sense. Basically, i am trying to work out why Commvault is not using pre-existing blocks for these new backups.
Thanks
Hi
Can you please confirm if same deduplication engine is used for Server 2 as well ?
Regards,
Suleman
Same SP, same DDB, same everything.
Would it be somehow related to the previous backups being Syn-Fulls whereas you cannot run a Syn-full for the first ever backup of a subclient. Has to be full ….
Hi
Can be a possibility but if Data is same, there should be more savings. Is there a possibilty that the data which is being backed up is different/unique ?
Regards,
Suleman
Are both the old and new subclients using the same “block level” settings?
Thanks,
Scott
In usual scenario, since all the blocks from the volume on “server1” are already available, the new data should be deduped against those blocks.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.