You are here: Application protection > Failback and restoration for application jobs > Restoring then failing back applications configured for DNS failover

Restoring then failing back applications configured for DNS failover

For application workloads that were configured for DNS failover, you can use the Application Manager to initiate failback and, if desired restore data from the target back to the source. In order to minimize downtime, the restoration process is completed before the failback.

If you are using a cluster environment and protecting Exchange, make sure the Physical Disk resource(s) and the IP Address resource are online on the source cluster.

When you bring the source cluster online, an identical network name will be active on the target. Therefore, when the source cluster tries to bring the Exchange virtual server on the source online, the network name resource will fail and the group will not come online. Allow the source cluster to finish trying to bring the resources online before beginning failback.
In the Application Manager, make sure your source target pair is selected and then on the Monitor tab, click Failback.

The Failback button may not become active right away after completing a failover. In this case, restart the Application Manager.
Specify the options for your failback and restoration.

Source IP Address—Select an IP address on the source to handle the restoration data. In a cluster environment running Exchange, select the name of Exchange virtual server dependent IP address.
Restore target data prior to failback—Select this option to restore data from the target back to the source. If you are certain that there is no data that you want to restore or you are willing to lose any data changes on the target, you can disable this option.
Enable Compression—Compression allows you to reduce the amount of bandwidth needed to transmit restoration data from the target back to the source. The data is compressed before being transmitted and then is uncompressed before it is written on the source. Typically, compression is used in WAN environments, but not in LAN environments. If desired, enable compression and select the level of compression that you want to use.
Prompt prior to failback—When this option is enabled, the failback process will not start until you manually initiate it after the restoration is complete. You will be prompted when the restoration process is complete. If you disable the failback prompt, failback will automatically start when the restoration is complete.
Mirror—Select the type of mirror to use for the restoration process. A Full mirror will transmit all files from the target back to the target. A Checksum mirror will transmit only the blocks of data that are different between the target and source.

Click Initiate Failback to being the failback process.

The following notes are specific to Exchange protection.

If you deslected any mail stores during your failover configuration, you may see a message during failback about potential errors (unpaired mail stores). This message can be disregarded.

If you created any new mail stores on the target after failover, they will not be failed back.

Mail sent to public folders during failback may be routed to the target server after Exchange is shut down, which will result in mail being stuck in the queue. Make sure mail is not sent to public folders until the failback process is complete.

If you are using Exchange 2010 with DAG, offline address books may need to be distributed to other servers in the DAG after failback.

If you close the Application Manager during failback, you may have to manually run the post_restore.bat file which starts the Exchange services and updates public folders on the source.

If your source is an Exchange 2007 CCR, LCR, or SCR cluster, after failback the CCR, LCR, or SCR replication will need to be manually reseeded after verifying Exchange is functioning properly. For information about this process, see Microsoft TechNet Article How to Seed a Cluster Continuous Replication Copy.

In a like-named cluster environment with more than one DNS server, there may be a delay contacting the source after failback. The DNS server used by the source cluster is updated on failback to point back to the source server. However, if the Application Manager is running on a machine that uses a different DNS server, it may not recognize the change until the next DNS zone refresh.