Neverfail Cascade



This Knowledgebase article presents an overview of Neverfail Cascade including important information when considering implementation of this field-engineered solution and Neverfail's policy on selling Neverfail Cascade.

More Information


Neverfail Cascade is a customized, field-engineered solution that complements Neverfail Heartbeat and provides Disaster Recovery by replicating the protected data set from the Neverfail server pair to a Tertiary server, which is typically at a remote location.

This configuration is often desirable in situations where one might desire a local High Availability pair plus a remote Disaster Recovery server.  The following considerations are important when considering a Neverfail Cascade implementation:

  • Neverfail V5.0.2 is the final version that supports Neverfail Cascade.
  • Neverfail Cascade can ONLY be used in conjunction with Neverfail for Exchange or Neverfail for SQL Server.

Warning:  Neverfail Cascade can NOT be installed in Neverfail for FileServer deployments for the following reasons:

  1. Alternate data streams will become corrupt.
  2. File security attributes and DFS links are not replicated.
  3. The file sharing services do not run on the passive server (they are part of the FileServer AM).  Cascade uses file shares to make the Cascade queue available to the tertiary.
  • As Neverfail Cascade is a customized, field-engineered solution, it can only be installed and configured by Neverfail staff.
  • The Tertiary server is "fed" from the Secondary server whenever the Secondary server is in passive mode.  Consequently, replication to the Tertiary server will stop if the Secondary server becomes active, for instance in the case of a failover or switchover.
  • Switching back from an a ctive Secondary server to a passive Primary server will require the Tertiary server to be completely re-synchronized with data from the Secondary following the switchback process.
  • The Tertiary server provides no monitoring of the High Availability pair, and therefore all failovers to the Tertiary server must be initiated manually.
  • Following a failover to the Tertiary server, no automated processes exist for restoring data/service back to the High Availability pair; however, a set of documented manual steps can be provided as guidance.
  • The Tertiary server can either function as:
    • A simple data store (easy to setup, longer to failover) - in this case, the Tertiary server must simply have the same OS version and service pack level as the High Availability pair.
    • A clone of the High Availability pair (more complex to setup, quicker to failover) - in this case, all servers must be running Windows 2003 SP1.
  • Data changes are not always sent continuously to the Tertiary server. Instead, if there has been no activity for a while, the Tertiary server will poll the Secondary server for changes every 5 minute. A SCOPE Professional, SCOPE Enterprise Data Collector, or SCOPE Data Collector service analysis of application load and network bandwidth is essential.  Neverfail Cascade is not recommended for applications under substantial load, due to the dependency on high bandwidth to the Tertiary server.  A minimum bandwidth of 10 Mbit between the High Availability pair and the Tertiary server is highly recommended.
  • Ports used by Neverfail Cascade:
    • Port 52267: Used by nfcmd client to send commands from Tertiary to the Secondary server
    • Port 445: Used to access fileshares on the Secondary Server.
    • Ports in the range 23xx .


  1. Neverfail Cascade is a field engineered non-standard configuration.  Standard Neverfail Support is not available.
  2. Neverfail Cascade should never be proactively suggested as an option to a customer or partner.
  3. If a customer or partner inquires about Tertiary configuration, they should be guided toward a standard Neverfail configuration implemented across a WAN rather than a Tertiary server.
    • Because of Neverfail's unique architecture, Neverfail provides seamless failover across a WAN, preventing a disruption to users in the event of a failover. Why involve a third server – where is the benefit?
    • Running a standard Neverfail pair reduces the cost to the customer – no third server needed.
  1. At the end of the day, if you are going to lose the deal because the customer is demanding this feature, and it is the only  “deal breaker” on the table, then go ahead a propose it.
  2. Before you propose it, be sure to inform Paul Dossey (in the US) or Ken Anton (in the UK) of the situation.
  3. Bottom line – avoid proposing a Tertiary server if at all possible.

Applies To

Neverfail Heartbeat V5.0.2 and prior

Related Information



0 out of 0 found this helpful



Please sign in to leave a comment.