Remote Restore Failures

If your network has an outage or experiences extreme latency during a remote restore, this synchronization operation may fail. As described in Synchronizing Extensive Changes, the remote restore operation itself is fairly efficient, and it is unlikely to be the cause of such latency.

When a remote restore fails, the standby node automatically attempts to reconnect to the active node and perform the operation again. If the outage or latency was momentary, a retry is usually sufficient to allow the remote restore to complete.

If necessary, the standby node attempts to perform a remote restore a total of three times. If the remote restore fails three successive times, the standby node stops retrying and displays the following error message: “Restore from active server failed.”

After you close this dialog box, the standby server becomes a standalone Vocera Voice Server, and the cluster is in a split brain state. This standalone server has an empty database, and its split brain state is more benign than the one described in Network Problems and Clustering for the following reasons:

Make sure you understand and solve the network problem that caused the cluster to enter this state before starting the standalone server and attempting to rebuild the cluster. Do not start the standalone server without joining it to the cluster again, because badges that were off network when the failure occurred may return and connect to it.

To rejoin the cluster if remote restore fails three times:

  1. Use the control panel to start the standalone server.
  2. Open the Administration Console on the standalone server and log in.
  3. Reconfigure the cluster on the standalone server. See Add/Edit Cluster Server.
    The standalone server enters discovery mode, finds the active node, performs a remote restore, and rejoins the cluster as a standby node.