CDR replication settings

Last post 07-20-2010, 3:39 AM by Calippo. 2 replies.
Sort Posts: Previous Next
  • CDR replication settings
    Posted: 07-07-2010, 2:32 PM

    We've been using CDR for a few years now to transfer data from our main site to a DR site.  Recenty the bandwidth changed (lowered) between the two sites and I'm looking at the options for the CDR Replication Set.  I see a "Compression ON" option.  A few questions...

    1) How does this software compression work in the real world?  What type of compression rates are typically acheived? 

    2) Does it consume a lot more resources (processor?) on the source and destination servers to compress and decompress? 

    3) How much does it add to the total replication time?

    4) Any other words of wisdom from real experience using compression with CDR?  Based on the answers I may also try using the software compression on the remote client iDAs as well.




  • Re: CDR replication settings
    Posted: 07-08-2010, 8:54 AM


    Compression just like on a regular job takes a slight CPU hit in order to move less data.  In regards to replication the source will compress the data before it replicates to minimize the amount of data transferred over the link.  When the data hits the destination another slight CPU hit will be acknowledged to uncompress the data.  If bandwidth is your limiting factor this option is recommended as the impact on the CPU is quite minimal. 


  • Re: CDR replication settings
    Posted: 07-20-2010, 3:39 AM


    The amount of compression achieved is really dependant on the data its self. Certain data (such as graphics or binaries) are not gong to show any or much compression advantage at all because these files are compressed natively. Other files such as user data files may compress very well. Data that is ZIPed up or compressed with another tool will probably increase in size by trying to compress again.

    Even with SQL the amount of compression achieved is going to be down to what the data in the database is.

    With CDR or WBA the data being replicated will finish up in the same state as the source (its a replica). So if the data is compressed at the source then it will be compressed at the target. You cant compress one end and have the other end differant, in the current release of the product. Certainly to save disk space at the destination it would be benifitial to compress at the source but your source system will see some CPU hit if the source file system is compressed (see Microsoft KB Article 251186). If you end up compressing the source data dont forget to disable CDR compression.

    BTW... we can achieve approximately the same compression reduction as other software compression such as PkZIP. Cant give you an estimate but I would expect to get 65% on average unless the data is compressed already.


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