Automatic Failback With Optional Manual Failback

Failback is the process in which Primary station resumes its Primary status after an Failover event. Two steps are involved in the Failback process: 1) copy all current files from the Standalone server to the newly-started server; 2) set the newly-started server to be the Primary station in the clustering.

ClusterReplica Enterprise offers two ways to Failback:

1. Automatic Failback - when automatic failback is set, users can choose to failback with or without the date replicated back from the now Primary station.
   
   
2. Confirmed Failback - when no automatic failback is set, the original Primary station will become the Secondary station after a failover. Users can manually switch the roles if they want to reset the original state of the Primary and Secondary stations.
   
   

There are advantage and disadvantages in each of the Failback method.

Advantages:

• The automatic Failback is simple and hassle-free for keeping the original Primary station to be the active server whenever the clustering functions normally.
  
  Some users prefer this way because they use a heavy-duty machine to run the Primary station while using an average machine for the backup. Naturally, they would prefer to use the original Primary to be the active server.
  
  
• The confirmed Failback guarantees no mistakes on overwritten data.
  
  In some special circumstances, the newly-started server may contain the data users wanted. Users may then want to copy the data on the newly-started server to the Standalone server, instead of vice versa which occurs under normal Failover. Manual Failback gives you full control of which direction the data flows.

Disadvantages:

• The automatic Failback - In some special circumstances, the newly-start server may contain the data users want to keep. If automatic failover is set on the cluster server, this data will be overwritten as soon as the system is connected to the clustering. This accidental loss of data then becomes inevitable.
  
• The confirmed Failback requires a person to sit in front of the server and confirm each step of the configuration. This process can be tedious and is vulnerable to human error.

The main reason that some users want to Failback is that of the two clustering systems, the one used for the Primary station is more robust than the one used for the Secondary station. Failback keeps the robust system as the Active server for as long as possible.

Notice that, if the two systems in the cluster server are comparable, letting the Primary station "float" in between the servers without Failback can be equally efficient.

Back to ClusterReplica Enterprise page