The High Availability configuration option provides redundancy, automatic failover, and eliminates single points of failure for Remote Mounts.

High availability helps improve business continuity and user satisfaction by preventing interruptions of critical business processes and providing reliable user experiences. Financial losses can be minimized by eliminating system downtime and service outages.

Customers on our Enterprise plan can configure High Availability for their Mounts. This automatically uses an alternative connection to the same storage location when needed, minimizing downtime.

With High Availability settings, you can specify multiple backends for a Mount. If the primary backend becomes unreachable, the system automatically switches to the next available backend based on priority.

Use Cases

High Availability Mounts are designed for organizations that depend on constant access to remote file systems or cloud storage. They are especially useful for enterprise environments where file transfers, syncs, or automations cannot afford interruptions. Businesses running hybrid storage models rely on HA Mounts to maintain simultaneous access to on-premise NAS systems and cloud storage locations. This ensures that users continue working without disruption, even if a particular connection or protocol becomes unavailable.

In disaster recovery and business continuity scenarios, HA Mounts play a vital role in maintaining access to data during unexpected outages, planned maintenance, or infrastructure failures. They also support customer-facing applications that require uninterrupted availability to deliver files, process data, or serve data. If your workflows must operate continuously, such as those in financial processing, healthcare, logistics, or media production, configuring HA Mounts ensures that Files.com automatically keeps your connections stable and your data available.

Protecting Business Impact

Downtime impacts revenue, customer satisfaction, and trust. Even a brief outage can interrupt automations, delay file transfers, and create workflow bottlenecks. High Availability mitigates these risks by ensuring that alternate backends take over immediately if the primary connection fails. This protection keeps productivity high and eliminates the need for manual intervention during outages.

High Availability also reduces the cost of downtime by allowing teams to continue working seamlessly while IT resolves underlying infrastructure issues. Continuous availability supports compliance requirements for uptime and service reliability, which are common in regulated industries. In essence, High Availability Mounts provide the foundation for resilient file operations, protecting both the customer experience and the organization’s bottom line.

How HA Mount Works

A High Availability Mount connects multiple backends that all point to the same shared storage location. Files.com continuously monitors each backend’s health using connectivity checks, canary files, and configurable stability thresholds. When you configure your Mount, each backend must reference the same remote folder path and use identical permissions. Files.com performs health checks at regular intervals, reading and writing small canary files to confirm connectivity and data integrity.

Each backend is assigned a priority. The backend with the highest priority acts as the active connection, while the others remain passive and on standby. When the system detects that the active backend has become unreachable, it automatically redirects activity to the next healthy backend in the priority list. Once the original backend recovers, it reenters the standby pool and is ready to resume service if needed. This architecture ensures that all file operations remain available with minimal disruption and without requiring user action.

Requirements

All backends must have identical access to the same exact shared storage location. For example, if the Mount points to a folder named path/to/folder, using Read+Write access permissions, on the remote server, then each backend must also point to path/to/folder and each must also have Read+Write access permissions.

Setting Up and Prioritizing Backends

The first new backend you add must be the same one you used when setting up the Mount.

Subsequent backends can use different connection methods. For example, if you are connecting to an on-premise NAS system, the primary backend can connect via SFTP while the secondary backend can connect via FTP(S). This setup lets you use failover options across different protocols and connection methods.

Select a Remote Server to connect with and a remote folder to use for the Mount.

You can also specify a Priority for the backend. During a failover, the healthy backend with the highest priority will be chosen first.

The backend with the highest priority will be the active high availability node while other backends will be available as passive nodes. The active backend handles all requests while a secondary (passive) backends remains on standby. A passive backend, with the highest priority, automatically takes over if the primary fails. This provides a robust and versatile active/passive HA setup for your Mounts.

Make sure that all backends point to the exact same folder on the remote system. This ensures the folder contents remain identical if the High Availability Mount switches between backends.

Health Checks

Health checks assess both connectivity and data integrity using a canary file system. A "canary file" is a dummy file that is used as part of an early warning system. It is a specially placed file that is used to determine changing conditions at its location.

Each backend has a corresponding canary file path defined where canary files will be written. Canary files contain a timestamp, showing when they were written.

The health check will read each of the canary files to verify the health of each backend. Timestamps are compared to determine whether a canary file is outdated, indicating if a backend is no longer healthy.

The health check verifies connectivity, confirms access permissions, and flags configuration issues.

Canary File Path

Make sure that you specify a canary file path to a location that has correct access permissions. Make sure that the path to the canary file is readable and writable by the authentication credentials used for the corresponding Remote Server.

We recommend placing all the canary files into the same folder location. For example, if the Mount is configured to use a Remote Folder path of path/to/folder on the Remote Server then make sure that the canary file path is also pointing to a location within path/to/folder.

Place the canary file into a location that avoids the canary file being deleted, moved, renamed, or changed by other methods.

For example, do not place the canary file in a location that is regularly purged or a location that is used as the source or destination of a Remote Sync, Automation, or file processing script.

Active vs Passive Health Checks

The health check type can be set to either active or passive.

Active health checks will write and read canary files and compare timestamp information to determine the health of each backend. This option is the most comprehensive method for determining connectivity, accessibility, and the health of backends.

Passive health checks will only read canary files to determine the health of each backend. This option is recommended when using read-only permissions on backends. When using a read-only backend, specify an existing file as the canary file.

Check Intervals

Health check intervals are configurable. The default interval is 15 seconds.

Configuring Connection Stability Thresholds

Stability thresholds can be configured for each backend. These thresholds specify the number of successful and unsuccessful connection attempts to use to determine the health of a backend. The default threshold is 1.

For example, if you specify a threshold of 5, then it will take 5 consecutive failed connection attempts to mark a backend as unhealthy and it will take 5 consecutive successful connection attempts to mark a backend as healthy again.

Health Status

The status of each backend will determine its use in the pool of high availability connections for the Remote Mount. During a failover, a healthy backend with the highest priority will be chosen.

Healthy

A status of Healthy indicates that the backend is operational with no connectivity or access issues. The backend is available to be used in the pool of high availability connections.

Failed

A status of Failed indicates that the backend is offline or unreachable. The health check has failed consecutively for the number of times specified in the Connection Stability Threshold. The backend is removed from the pool of high availability connections.

The Failed status clears automatically when the backend’s connectivity is restored.

Degraded

A status of Degraded indicates that some, but not all, of the consecutive connections specified in the Connection Stability Threshold have failed. This status indicates an intermittent connectivity issue with the backend. The backend is available to be used as a fallback in the pool of high availability connections. It is only used when no healthy members exist in the pool.

The Degraded status will automatically clear itself when consistent connectivity with the backend is resumed.

Desynced

A status of Desynced indicates that the timestamp of the canary file is out of date and up-to-date connectivity with the backend cannot be guaranteed. The backend is removed from the pool of high availability connections.

You can manually reset the Desynced status. The Reset option becomes available whenever the status of the backend is Desynced.