Replication to DR site

Last post 06-09-2015, 1:51 PM by isle. 4 replies.
Sort Posts: Previous Next
  • Replication to DR site
    Posted: 05-21-2015, 12:46 PM

    We are a new archive only implementation and we currently only have 1 media agent at our Primary site.  We are running 2 copies on our storage policies with the temporary secondary being at the main site  The plan is to put the secondary at our DR site across a WAN link.   With that being said I am trying to figure out what is the best way to do this.  I was told we should get a second media agent at the DR site and hook storage up to that and then replicate somehow?  Is this the best way to do this?  We do use dedupe databases as well.  Would it be better just to create a target at the remote site and tell the 1 media agent where it is at and not put up the second media agent?  If someone could please advise on this, the thought on the second site is simply for a second copy of the data, no plans at this time to failover to that site.

  • Re: Replication to DR site
    Posted: 05-26-2015, 1:07 AM

    I would recommend simply provisioning a MediaAgent at your DR site with adequate storage then setup a secondary copy in your Storage Policy that points to the second MediaAgent. Then setup a DashCopy to the secondary MediaAgent so your data is automatically copied there every 30 mins (or less). You will need to enable Dedupe on the secondary copy as well so you only copy the changed blocks. If your first MA fails you can just change the copy precendence in the SP and your off and running again.

    If you do want to fail over to the secondary site then that is a longer conversation but we have done this by using workflow's and scripting the changing of the Storage Policy copy precendence and changing all the schedules etc as well as failing over the CommServe to the DR site utilising SQL mirroring and the workflow. No way i could explain all that in here but it is definitely possible and works great.

     

    Hope this helps in some way.

  • Re: Replication to DR site
    Posted: 05-26-2015, 10:26 AM

    Great thanks that is helpful.  I would think my DASH copy should be Network Optimized as well?  Also is there a good way to populate the DR side initially without saturating the network?

  • Re: Replication to DR site
    Posted: 05-26-2015, 4:59 PM

    Sure so you need to seed the data first.

    So you locate the DR MediaAgent on the local network where your primary copy is. Run the first copy to it (full backups is all you need) then you take that over to your DR site plug it in and resume the DashCopies it will just synch the changes.

    If you can't move the DR MediaAgent you can plug in a smaller unit just large enough to grab the full backups just create another Storage Policy Copy pointing at the smaller MA (with Dedupe enabled) then take that over to your DR site and change the copy source of your DR copy to point at your Seed copy and copy the data over then change the copy source back to the primary copy then delete your seed copy. 

    I have found that Disk Read optimized is much faster so long as your disks on the MediaAgent are half decent. Network Optimized seems to be a bit better with very fast networks however we have WAN links ranging from ADSL right up to 1GB L2 links and we have all our Dash's set to Disk Read Optimized we have no issues with copying TB's per day from our customers to us.

  • Re: Replication to DR site
    Posted: 06-09-2015, 1:51 PM
    • isle is not online. Last active: 11-20-2019, 3:07 PM isle
    • Top 25 Contributor
    • Joined on 08-21-2012
    • NJ
    • Adept
    • Points 308

    If the primary copy is deduplicated, Disk Read will most likely be more benefical.

     

    This is due to the way we read the data.

     

    Disk Read Optimized: Read latest chunk meta data and send the signatures to the destination DDB. If the signature is new it reads the information from the chunk data on disk(similar to network read but only when needed).

     

    Network Read Optimized: Chunk Data is read from the disk and new signatures are generated in memory(UseCacheDB 0, 1 would put it on disk which is normally slower as well) to be sent to the destination DDB. As we need to read potentially a larger amount of data. This option will technically verify all the data on your source as it reads it as a whole.

     

     

     

     

    ==========================

    you mentioned seeding the data, there is a document on this which you can review here: http://docs.commvault.com/commvault/v10/article?p=features/deduplication/manualseedingprocess.htm

     

     

    =========================

    lastly, 2 media agents is prefered and I will explain why.

     

    MA 1 holds the primary DB and Disk Library paths

    MA 2 holds the secondary DB and disk library.

     

    The data is dashed copy and MA1 fails like a DR or hardware failure scenario, how do you restore the data?

    MA2 will be avaialble to perform the restores, if you were using just one media agent you would be stuck until new hardware was available.

     

     

    Keep in mind the Commserve still needs to be available so if you are not using a standby CS and the primary site goes down, you will need to restore the DB. 

     

    Here is an additional document on setting up log shipping:

     

    http://docs.commvault.com/commvault/v10/article?p=features/disaster_recovery/r_cs_failover_sys_req.htm

     

    =========================

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