Doubt about best practice for secondary copy

Last post 02-16-2019, 4:06 AM by mattia-eurosystem. 3 replies.
Sort Posts: Previous Next
  • Doubt about best practice for secondary copy
    Posted: 02-14-2019, 9:28 AM

    Hello, we currently have different DDBs (with Global deduplication policy) for: -email archiving - file system archiving - backups We would like to implement a secondary copy from the archiving systems to the same library (disk library) as backups. Is it suggested to use the same DDB for archiving and backups (so to use the global ddb of the backups for the secondary copy) or do you suggest to create a new share on the disk library and create a new DDB for the secondary copy? I am trying to follow best practices but I can't find any suggestion about that. Thanks

  • Re: Doubt about best practice for secondary copy
    Posted: 02-14-2019, 4:26 PM

    My understanding from the commvault library docs is that you dont need another DDB. 

    https://documentation.commvault.com/commvault/v11/article?p=12663.htm 

     

    "Auxiliary Copy operations will automatically unravel or explode the deduplicated data, if deduplication is not enabled in the copy.

    If the secondary copy is set up for deduplication, then a separate deduplication database gets created for the copy and the associated data is deduplicated for secondary copy.

    However, note that if secondary copy has deduplication enabled but DASH Copy option is disabled, the deduplicated data is always unraveled on the source and then deduplicated on the destination."

  • Re: Doubt about best practice for secondary copy
    Posted: 02-15-2019, 6:28 PM

    Hi mattia-eurosystem. 

    It is really up to the available resources, if you use a GDDB for all the Secondary Copy, this will allow you to write everything to a single GDDB, which can be good for overall Deduplication Saving. 

    If you use separate DDB for each IDA, this will work as well allow more granularity for restores as well as ease of troubleshooting if there are hardware issue (as you will only need to work on the DDB impacted)

    When looking into creating a Secondary DDB or Global DDB, you should always put it on a separate Disk Library (provisioned from a different Storage Array). You should not place it on a share coming from the same Storage Array, as this creates a single point of failure, defeating the purpose of having replication (because if you lose the Storage array you lose your Primary and Secondary Copy data)

    Regards

    Winston 

  • Re: Doubt about best practice for secondary copy
    Posted: 02-16-2019, 4:06 AM

    Hello and thanks for the answer. By the way I am considering that mixing archiving and backup deduplication policy is not a good practice (told also by Commvault support).

    I will do another DDB for the secondary copies of the archiving.

    Thanks for your time

     

    Mattia

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