Replicating SQL Data

Last post 11-10-2010, 12:02 PM by Vincenzo_Basolino. 4 replies.
Sort Posts: Previous Next
  • Replicating SQL Data
    Posted: 11-02-2010, 2:58 PM

    First off Is anyone doing sql application replication through commvault?

    I have a 20tb SQL Database that we'd like to replicate to an offsite location for Disaster Recovery purpose.

    I assume to make this happen I will need the following:

    2 Media Agent Servers

    2 CDR Licenses

    2 FS Licenses

    2 SQL Agents

    2 Virtual Filesystem Licenses since its a cluster.

    Anything else? Not sure if Recovery points require a license as well.

    What about diskspace do I just basically clone the source on the desintation side?

    Basically just want to know if we create recovery points does that require additional space?

    How easy is it to restore this to a new server in the replication site if the source location is destroyed(fire,bomb,earthquake) ie out of place restore

  • Re: Replicating SQL Data
    Posted: 11-03-2010, 9:07 AM


    Those licenses should be sufficient for replicating the database.  The underlying mechanism for replication of SQL would be VSS, so as long as no technical limitations exists on snapping a DB of that size, replication should be capable of moving the data.  VSS is also leveraged during recovery point creation, so the situation as a whole is hinging on VSS.    Additional space for the shadow storage will also need to be taken into consideration, and this would be based on the amount of time you are keeping the snapshots around and the amount of I/O within the database which would be cached. 

    In the event of a disaster, you would have the live copy available for quick access, or you can mount the snapshot and move the data back to the source side once its available (i cant image performing this option as 20TB is a lot to move). 

    Have you considered using SnapProtect, and leveraging hardware snapshots to protect this data?

  • Re: Replicating SQL Data
    Posted: 11-03-2010, 9:49 AM

    Can my destination be a sql server?

    So that if a failure happens I can just mount the database in my replication source area?(Is this what they mean by live copy?)

    Or are they stored compressed format and you must do a copy?


    "Have you considered using SnapProtect, and leveraging hardware snapshots to protect this data?"

    We're trying to achieve an offsite sync'd copy of the database incase the main datacenter is down. Can SnapProtect be replicated?


  • Re: Replicating SQL Data
    Posted: 11-10-2010, 12:00 PM

    Hi Ipman,

    The quick answer is yes, you can have SQL on the destination machine, it just cannot have the DB's mounted while replication is occuring (CDR needs exclusive access to the files up untill they will be used).

    You can use the Live Copy (the replicated data sitting on the destination disk) or CRP's (Snapshots) of the data if you need to restore to an exact point in time.  There is also the copy back feature, but this may not feasable if you have to copy TB's over the link.

    We do have some documentation about setting up a standby SQL and using CDR to replicate the data here:

    Some additional considerations can be found here:

    Let us know if you have any other questions.


  • Re: Replicating SQL Data
    Posted: 11-10-2010, 12:02 PM

    Yes, the destination can be a SQL server, but the services cannot be start (this will lock the files that replication is trying to write to).

    Can SnapProtect be replication?  Kinda... The snapshot itself will be active on the hardware side which can allow for fast recovery or copy.  I say kinda because if you HW snap and then backup the snapshot with SQL iDA, the backup chunks can be replication to the destination with SDR (or in 9.0 DASH copy) and can then be recovered on the DR Site. 



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