Redundant Dedupe Partitions re-baselining with partition offline

Last post 06-04-2017, 11:32 PM by AUBackupGuy. 0 replies.
Sort Posts: Previous Next
  • Redundant Dedupe Partitions re-baselining with partition offline
    Posted: 06-04-2017, 11:32 PM

    Currently if a dedupe partition goes offline, you can recover the data happily.  However while backups can still run (redundantly = good) they don't run exactly the same as if the offline partition was still available (I'd describe that as *fully* redundant

    Backups or DASH copies targeting the partition have to write a lot more data, basically re-baselining all data on the offline partition onto the existing partition. This is particulary important if the partition is offline for an extended period of time eg. stuck pruning 300 million pending deletes before allowing the parition back online - which can take a weekend..

    For larger partitions this can quite easily blow through your available space (I've seen 30tb+ over a weekend) and then you have to accomodate the excess usage until the data ages and really hope it's not the end of month fulls doing extended retention or you'll be waiting months to get that space back.


    Shared lun disks in clustered is probably out as SAN SSD wasn't fast enough for us, local SSD is the best thing for larger stores (~1PB).

    A secondary copy of each MA paritions DDB may do the trick, you could probably use slower speed disk as you'd still be doing remote lookups via network just keeping a copy of the other MA partitions DDB locally.  Even copying this once or twice a day as a sync task would probably suffice to prevent 95% of re-baselining.  You could keep the secondary DDB in a read-only state as the reconstruct DDB job would take the offline partition back to that state.

    Note - this is assuming the following setting is enabled.

    If the Allow jobs to run to this copy while at least [ ] partition(s) are available option is enabled, and if one of the partitions goes offline, sealing and start of a new DDB is prevented, and the backups continue to other active partitions.



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 © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy