Open topic with navigation

Failback and restoration for applications configured for identity failover

Use the following steps for application workloads that were configured for identity failover.

1. Before you begin the failback and restoration process, stop the services on your source that correspond with your application.
Exchange 2007
• Microsoft Exchange Active Directory Topology Service
• Microsoft Exchange Anti-spam Update
• Microsoft Exchange EdgeSync
• Microsoft Exchange File Distribution
• Microsoft Exchange IMAP4
• Microsoft Exchange Information Store
• Microsoft Exchange Mail Submission
• Microsoft Exchange Mailbox Assistants
• Microsoft Exchange POP3
• Microsoft Exchange Replication Service
• Microsoft Exchange Search Indexer
• Microsoft Exchange Service Host
• Microsoft Exchange System Attendant
• Microsoft Exchange Transport
• Microsoft Exchange Transport Log Search
• Microsoft Search (Exchange)
• World Wide Web Publishing Service
Exchange 2003
• MSExchangeSA
• MSExchangeMGMT
• POP3SVC
• IMAP4SVC
• ResVC
• MSExchangeES
• W3SVC
• SMTPSVC
SQL Server
• MSSqlServer
• SQLServerAgent
• MSSearch (SQL 2000)
• MSFteSQL (SQL 2005)
• MSSQLServerADHelper
• MSDTC
• MSSQLServerOLAPService
• MSDTSServer
• SQLWriter
• SQLBrowser (SQL 2005)
File Server
• Server
• Computer Browser
2. Ideally, you want to restore your data from the target back to the source before you failback. This allows users who are currently accessing their data on the target because of failover to continue accessing their data. Restoration before failback reduces user downtime. The procedure to restore and then failback varies widely with server and network configuration. Another method, which may be easier in some environments, allows you to failback first and then restore the data from the target to the source. A possible disadvantage to this process is that users may experience longer downtime, depending on the amount of data to be restored, because they will be unable to access their data during both the restoration and the failback. 
Restoring then failing back
Restoring before failing back allows your users to continue accessing their data on the failed over target, which is standing in for the source, while you perform the restoration process. The key to this process is to keep the users off of the source, but allow the source and target to communicate to perform the restoration.
1. Locate the file connect.sts on the source where you installed Double-Take Availability and rename it to connect.sts.old. This will keep the original connection from reconnecting when you bring the source online.
2. Resolve the problem(s) on the source that caused it to fail. Make sure in resolving the problems, that you do not bring the source on the network at this time because the target currently has the source’s identity because of failover.
3. Disable all of the NICs on the source.
4. Change one of the NICs on the source to a unique IP address that the target can access.
5. Configure that IP address so that it does not automatically register with DNS. This option is on the Advanced TCP/IP Settings dialog box on the DNS tab.
6. Do not enable the modified NIC yet. If you do, you will receive a network name conflict, because the target has the source’s identity because of failover. There are many variations for dealing with a name conflict, here are a few examples.
• Enable the modified NIC, knowing you will get the name conflict error. Disregard the error. Change the source name to a unique name in the domain and reboot when prompted.
• Change the source name to a unique name in a workgroup, not in the domain, and reboot when prompted. Enable the modified NIC.
• Stop the Workstation and Server services on the source. You may be prompted to stop other services. Stop those services also and note the service names for later. Enable the modified NIC. The server will not broadcast its name to the network because of the services you disabled.
7. Stop any applications that may be running on your source. The files must be closed on the source so that updated files from the target will overwrite the files on the source.
8. At this point, confirm you have the following configuration.
• Your target is standing in for your source because of failover, and users are accessing their data from the target.
• Your source is back online with a unique IP address and no network name conflicts.
• The source and target can communicate with each other.
• All applications on the source are stopped.
9. The Replication Console is a legacy console that is eventually being phased into the Double-Take Console. This console is used for the restoration process. To access this console, select Start, Programs, Double-Take, Double-Take Replication Console.
10. Select Insert Server, specify the source and click OK.
11. Begin your restoration process.
1. From the Replication Console, select Tools, Restoration Manager.
2. Identify the Original Source machine. This is your source machine where the data originally resided.
3. Select the Restore From machine. This is the target machine where the copy of the data is stored.
4. Replication Set contains the replication set information stored on the target machine (the machine in Restore From). If no replication sets are available, the list will be blank. Select the replication set that corresponds to the data that you need to restore.
5. Select the Restore To machine. This is your temporary source that has the unique IP address.
6. Select the Restore from Route. This is the IP address and port on the target that the data will be transmitted through. This allows you to select a different route for Double-Take Availability traffic. For example, you can separate regular network traffic and Double-Take Availability traffic on a machine with multiple IP addresses.

7. The Restore To Server Path and Restore From Server Path paths will automatically be populated when the replication set is selected. The restore to path is the directory that is the common parent directory for all of the directories in the replication set. If the replication set crosses volumes, then there will be a separate path for each volume. The restore from path is the path on the target server where the replicated files are located.

8. Select the Use Backup Replication Set check box to use the target’s copy of the replication set database for the restoration. If this check box is not marked, you will be accessing the replication set information from the source.
9. Select the Restore Replication Set check box to restore the target’s copy of the replication set database to the source during the restoration process.
10. Select the restoration conditionals that you want to use.
• Overwrite existing files during restore—This option restores all existing files by overwriting them. Any files that do not exist on the source are written also. If this option is disabled, only files that do not exist on the source will be restored.

• Only if backup copy is more recent—This option restores only those files that are newer on the target than on the source. The entire file is overwritten with this option.

  If you are using a database application, do not use the newer option unless you know for certain you need it. With database applications, it is critical that all files, not just some of them that might be newer, get mirrored.

   

• Use block checksum comparison/delta block transfer—Specify if you want the restoration process to use a block checksum comparison to determine which blocks are different. If this option is enabled, only those blocks (not the entire files) that are different will be restored to the source.
11. If you want to configure orphan files, click the Orphans tab.
12. If your original source was using Replicate NT Security by Name, you must enable that option on the target before you start the restoration. The option is available on the target’s Server Properties on the Source tab.

13. Click Restore to begin the restoration. You can identify a restoration connection because it is enclosed in parenthesis ( ) and it has _Restore appended to the end of the replication set name. The initial restoration is complete when the Mirror Status is Idle. After the Mirror Status is Idle, the connection will continue replicating any on-going data changes from the target to the source.

    During the restoration, only the data is restored back to the source. Shares are not created on the source during the restoration. Shares that were created on the target during failover will need to be created manually on the source.

     

12. After the Mirror Status is Idle, schedule a time for failback. User downtime will begin once failback is started, so select a time that will have minimal disruption on your users.
13. When you are ready, begin the failback process. User downtime starts now.
1. Deny user access to the target, so that no additional updates can be made to the data on the target.
2. Stop all applications on the target, allowing the data to become quiescent.
3. In the Replication Console, watch the restoration connection until activity has ended and replication is in a Ready state. This will happen as the final data in queue, if any, is applied on the source. The replication Ready state indicates replication is waiting for new incoming data changes.
4. The Failover Control Center is a legacy console that is eventually being phased into the Double-Take Console. This console is used for the failback process. To access this console, select Start, Programs, Double-Take, Availability, Double-Take Availability Failover Control Center.
5. On the main Failover Control Center page, click Add Target, specify your target server, and click OK.
6. After the target is inserted in the Target Machine list, click Login. Supply valid credentials if prompted.
7. Highlight the failed source and click Failback.
8. You will be prompted that the restoration connection is still in place. Continue with the failback. If you have a pre-failback script configured, it will be started.
9. When failback is complete, the post-failback script, if configured, will be started. When the script is complete, you will be prompted to determine if you want to continue monitoring the source, do not select either option. Leave the prompt dialog box open as is.
10. Since failback has occurred, your restoration connection is no longer valid and will be marked with a red X. Disconnect the restoration connection.
11. On the source, change the IP address that you modified earlier to the unique address back to its original address. You can also enable any other NICs on the source.
12. Also on the source, change the source name back to its original name and reboot, or restart the Workstation, Server, and any other services you were prompted to stop.
13. Once the source is back online, users can reconnect to the source.
14. Confirm the Replication Console is communicating with the source using the original IP address.
1. Right-click the source and select Remove.
2. Depending on your configuration, the source may be automatically inserted back into the Replication Console. If it is not, select Insert, Server. Specify the source server and click OK.

15. At this time, you can go back to the dialog box in the Failover Control Center. Select Continue or Stop to indicate if you want to continue monitoring the source. After you have selected whether or not to continue monitoring the source, the source post-failback script, if configured, will be started.

    The source must be online and Double-Take Availability must be running to ensure that the source post-failback script can be started. If the source has not completed its boot process, the command to start the script may be lost and the script will not be initiated.

     

16. If desired, you can reconnect your original replication set on the source to your target to reestablish protection.
Failing back then restoring
Failback before restoration can be a simpler process, but it may require additional downtime. The amount of downtime will depend on the amount of data to be restored. Users must be kept off of the source and target during this entire process.
1. Locate the file connect.sts on the source where you installed Double-Take Availability and rename it to connect.sts.old. This will keep the original connection from reconnecting when you bring the source online.
2. Resolve the problem(s) on the source that caused it to fail. Make sure in resolving the problems, that you do not bring the source on the network at this time because the target currently has the source’s identity because of failover.
3. Schedule a time for this process. Select a time that will have minimal disruption on your users.
4. When you are ready, begin the failback process.
1. The Failover Control Center is a legacy console that is eventually being phased into the Double-Take Console. This console is used for the failback process. To access this console, select Start, Programs, Double-Take, Availability, Double-Take Availability Failover Control Center.
2. On the main Failover Control Center page, click Add Target, specify your target server, and click OK.
3. After the target is inserted in the Target Machine list, click Login. Supply valid credentials if prompted.
4. Highlight the failed source and click Failback. The user downtime starts now. If you have a pre-failback script configured, it will be started.
5. When failback is complete, the post-failback script, if configured, will be started. When the script is complete, you will be prompted to determine if you want to continue monitoring the source, do not select either option. Leave the prompt dialog box open as is.
5. Bring your source onto the network at this time, but make sure that the users are not accessing it. The target must be able to access the source, but users cannot access the source because the data on the source is out-of-date.

6. Once your source is on the network, select Continue or Stop in the Failover Control Center to indicate if you want to continue monitoring the source. After you have selected whether or not to continue monitoring the source machine, the source post-failback script, if configured, will be started.

   The source must be online and Double-Take Availability must be running to ensure that the source post-failback script can be started. If the source has not completed its boot process, the command to start the script may be lost and the script will not be initiated.

    

7. Stop any applications that may be running on your source. The files must be closed on the source so that updated files from the target will overwrite the files on the source.
8. Now you can begin your restoration process.
1. The Replication Console is a legacy console that is eventually being phased into the Double-Take Console.This console is used for the restoration process. To access this console, select Start, Programs, Double-Take, Double-Take Replication Console.
2. Select Insert Server, specify the source and click OK.
3. From the Replication Console, select Tools, Restoration Manager.
4. Identify the Original Source machine. This is your source machine where the data originally resided.
5. Select the Restore From machine. This is the target machine where the copy of the data is stored.
6. Replication Set contains the replication set information stored on the target machine (the machine in Restore From). If no replication sets are available, the list will be blank. Select the replication set that corresponds to the data that you need to restore.
7. Select the Restore To machine. This is your source where the updated data from the target will be sent.
8. Select the Restore from Route. This is the IP address and port on the target that the data will be transmitted through. This allows you to select a different route for Double-Take Availability traffic. For example, you can separate regular network traffic and Double-Take Availability traffic on a machine with multiple IP addresses.
9. The Restore To Server path and Restore From Server path paths will automatically be populated when the replication set is selected. The restore to path is the directory that is the common parent directory for all of the directories in the replication set. If the replication set crosses volumes, then there will be a separate path for each volume. The restore from path is the path on the target server where the replicated files are located.
10. Select the Use Backup Replication Set check box to use the target’s copy of the replication set database for the restoration. If this check box is not marked, you will be accessing the replication set information from the source.
11. Select the Restore Replication Set check box to restore the target’s copy of the replication set database to the source during the restoration process.
12. Select the restoration conditionals that you want to use.
• Overwrite existing files during restore—This option restores all existing files by overwriting them. Any files that do not exist on the source are written also. If this option is disabled, only files that do not exist on the source will be restored.

• Only if backup copy is more recent—This option restores only those files that are newer on the target than on the source. The entire file is overwritten with this option.

  If you are using a database application, do not use the newer option unless you know for certain you need it. With database applications, it is critical that all files, not just some of them that might be newer, get mirrored.

   

• Use block checksum comparison/delta block transfer—Specify if you want the restoration process to use a block checksum comparison to determine which blocks are different. If this option is enabled, only those blocks (not the entire files) that are different will be restored to the source.
13. If you want to configure orphan files, click the Orphans tab.
14. If your original source was using Replicate NT Security by Name, you must enable that option on the target before you start the restoration. The option is available on the target’s Server Properties on the Source tab.

15. Click Restore to begin the restoration. You can identify a restoration connection because it is enclosed in parenthesis ( ) and it has _Restore appended to the end of the replication set name.

    During the restoration, only the data is restored back to the source. Shares are not created on the source during the restoration. Shares that were created on the target during failover will need to be created manually on the source.

     

9. Because there are no users accessing the target data, the restoration process is complete when the Mirror Status is Idle. When the Mirror Status is Idle, disconnect the restoration connection from the target.
10. Your original connection on the source, if it still exists in the Replication Console, will be in a Mirror Required state. Right-click the connection and select Mirror, Start. Select the type of mirror you wish to perform and click OK. When prompted to start replication, click Yes.
11. Once you have restarted the mirror and replication, you can allow users to reconnect to the source.

If you are protecting Exchange, after the restoration is complete, you will need to rehome the informational store databases to the source.

1. From a command prompt on the source, run the post_restore_<source server name>_<target server name>.bat file that Application Manager automatically generated.
2. Restart any Outlook clients so that they can access the source.