Effect of changing DDB setting Number of days to dedupe against

Last post 01-14-2019, 4:56 PM by Wwong. 1 replies.
Sort Posts: Previous Next
  • Effect of changing DDB setting Number of days to dedupe against
    Posted: 01-14-2019, 5:04 AM

    Hi all,

    I wonder if there is a good way to estimate the effect of changing the setting "Number of days to dedupe against". I'd like to estimate the new usage on disk.

    The base is.

    Current retention is 35 days 1 cycle with weekly fulls. Dedupe against days is unchanged (365 days).

    We looking into do 365 days 1 cycle and change the dedupe against days to 180.

    I thought if it coulde be as simple as do the following.

    Average of all incrementals times (365-52)*2

    Avarage of all Full times 52

    Plus baseline * 2

    Will that give me an estimate that is kind of accurate.

    Anyone done something similar?

    Best regards


  • Re: Effect of changing DDB setting Number of days to dedupe against
    Posted: 01-14-2019, 4:56 PM

    Hi Henrik

    The effect of changing the setting "Number of days to dedupe against", means that after x days (i.e. 180), you will have a new set of baseline writen to the Disk Library. Baseline refers to the first set of data (new and unique) which is usually written during the initial DDB creation phase.

    You can always review the DDB Partition and check the current Baseline Data to have a idea of how much data will be initially written after changing to 180 days. 

    Note - this is a simple method to gauge the space utilization, but you will need to also take into account of Aux Copy (because the Primary Copy will depend on whether the Data is Aux Copied to the Secondary before aging out, even if the Data has met retention) and Data Pruning (speed of DDB and Disk Library). These factors will impact the space usage. 

    So its important to always have more capacity, if you want to re-baseline. 

    Hopefully that helps 

    Thank you 


The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy