locked
Exchange 2007 CCr + SCR RRS feed

  • Question

  • I am Planning to Test CCR + SCR failover  on windows 2008 Server

    I have primary site having two CCR NODes (CCRA & CCRB)
    also Installed third passive node at my DR site (SCR).

    I am able to manage enabling & restoring database copy on my scr.I am able to mount databases and succesfully access my mailbox.

    Required your help to reverting to primary databases.

    My primary databases are in dismounted state.

    do i required to reseed my original databases from scr?

    or I need to  only update changes happens after DR fail over?

    Please provide steps to reverting to primary site.


    R Udeg

    Monday, August 31, 2015 12:08 PM

Answers

  • If you care to lose the updates that have come since you did your CCR activation, you can kill the CCR copy and re-activate the previous production servers.  It's not going to be very much easier (in fact, it is probably just as difficult as activating your CCR system was to start with), but you will only need to replicate across your WAN once.

    As for testing CCR activation, rather than having the CCR copy on your full network when you run the test, just isolate it with a domain controller and activate it that way.  This way, you have a target environment that doesn't affect the rest of your organization.  You will have to reseed after your test completes, but you will need that anyway.

    The simplest way to test DR is to upgrade to Exchange 2010 or 2013 and use a DAG across your WAN for both HA and DR.  Having the same sort of server arrangement you have now, you can test your DR and reactivate the original servers in a 20 minute timespan - and you can do it while users are accessing the systems and no one will notice that you ran the test.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })


    Monday, August 31, 2015 6:36 PM
  • The SCR is now out of sync with the CCR "originals".  If you tested this in your production system and had users access the SCR server, then yes, you will need to fully reseed the CCR "originals", as they are no longer the databases-of-record.  The ability to reseed the originals depends on whether the SCR can be made a cluster member with either of the SCR systems.  If it can, you can do the following:

    • Break the original cluster and cluster the CCR system with one of the SCR systems
    • Make the existing database an SCR database, with a copy on the second system
    • Once the database is fully seeded, make the second system the active system
    • Evict the CCR system and add the third system as the SCR target
    • Once the system is fully seeded, add the CCR system as a CCR target

    If you can't add the CCR system as a cluster member, you will need to do the following:

    • On either of the original systems, add a CCR target of the existing mailbox database
    • Once the target is fully seeded, run your CCR failover steps back to this system
    • With the database active on this system, add the third system as the SCR target of the database
    • Once this system is fully seeded, add the CCR server as a CCR target

    Other than using the above steps, I can't think of any way you can do this without taking the database offline for a full database copy across the WAN.  HTH ...


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    Monday, August 31, 2015 1:42 PM

All replies

  • The SCR is now out of sync with the CCR "originals".  If you tested this in your production system and had users access the SCR server, then yes, you will need to fully reseed the CCR "originals", as they are no longer the databases-of-record.  The ability to reseed the originals depends on whether the SCR can be made a cluster member with either of the SCR systems.  If it can, you can do the following:

    • Break the original cluster and cluster the CCR system with one of the SCR systems
    • Make the existing database an SCR database, with a copy on the second system
    • Once the database is fully seeded, make the second system the active system
    • Evict the CCR system and add the third system as the SCR target
    • Once the system is fully seeded, add the CCR system as a CCR target

    If you can't add the CCR system as a cluster member, you will need to do the following:

    • On either of the original systems, add a CCR target of the existing mailbox database
    • Once the target is fully seeded, run your CCR failover steps back to this system
    • With the database active on this system, add the third system as the SCR target of the database
    • Once this system is fully seeded, add the CCR server as a CCR target

    Other than using the above steps, I can't think of any way you can do this without taking the database offline for a full database copy across the WAN.  HTH ...


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })

    Monday, August 31, 2015 1:42 PM
  • Hi martin ,

    Thanks for inputs.

    I have production database copy of around 300 GB.

    It is very time consuming to reseed database copy back to primary CCR.

    is there any way to update ccr copy from my scr active copy?

    or else can you suggest me any alternative to test DR of CCR + SCR avoiding more complexity.

    Thanks 

    Rajesh


    R Udeg

    Monday, August 31, 2015 2:38 PM
  • If you care to lose the updates that have come since you did your CCR activation, you can kill the CCR copy and re-activate the previous production servers.  It's not going to be very much easier (in fact, it is probably just as difficult as activating your CCR system was to start with), but you will only need to replicate across your WAN once.

    As for testing CCR activation, rather than having the CCR copy on your full network when you run the test, just isolate it with a domain controller and activate it that way.  This way, you have a target environment that doesn't affect the rest of your organization.  You will have to reseed after your test completes, but you will need that anyway.

    The simplest way to test DR is to upgrade to Exchange 2010 or 2013 and use a DAG across your WAN for both HA and DR.  Having the same sort of server arrangement you have now, you can test your DR and reactivate the original servers in a 20 minute timespan - and you can do it while users are accessing the systems and no one will notice that you ran the test.


    Will Martin ...
    -join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })


    Monday, August 31, 2015 6:36 PM