The High Availability configuration option adds redundancy and automatic failover to Remote Mounts, removing single points of failure. When the active backend becomes unreachable, Files.com switches to the next healthy backend automatically, so file operations continue without manual intervention.

High Availability is available on the Enterprise plan. You configure multiple backends for a single Mount, each pointing to the same shared storage location. The system selects the active backend by priority and fails over to the next healthy backend when needed.

Use Cases

High Availability Mounts apply to organizations that depend on constant access to remote file systems or cloud storage, where file transfers, syncs, or automations cannot tolerate interruption. Businesses running hybrid storage models use HA Mounts to maintain access to both on-premise NAS systems and cloud storage when one connection or protocol becomes unavailable.

HA Mounts also apply to disaster recovery and business continuity scenarios, planned maintenance windows, and customer-facing applications that deliver files continuously. Workflows in financial processing, healthcare, logistics, and media production are common candidates.

How HA Mount Works

A High Availability Mount connects multiple backends that all point to the same shared storage location. Each backend must reference the same remote folder path and use identical permissions. Files.com monitors each backend's health at a configurable interval using connectivity checks and canary files.

Each backend is assigned a priority. The backend with the highest priority acts as the active connection; the others remain passive and on standby. When the active backend becomes unreachable, Files.com redirects activity to the next healthy backend in the priority list. When the original backend recovers, it re-enters the standby pool.

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 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 connects via FTP(S). This lets you fail over 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 is chosen first. The active backend handles all requests while passive backends remain on standby.

All backends must point to the exact same folder on the remote system. This keeps the folder contents identical when the High Availability Mount switches between backends.

Health Checks

Health checks assess connectivity and data integrity using a canary file. A canary file is a small file Files.com writes to and reads from a known location to detect changing conditions at that location.

Each backend has a canary file path. Files.com writes a timestamp into the canary file and compares timestamps across backends to detect when a backend has fallen behind. The health check verifies connectivity, confirms access permissions, and flags configuration issues.

Canary File Path

The canary file path must be readable and writable by the authentication credentials used for the corresponding Remote Server.

Place all canary files in 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, the canary file path must point to a location within path/to/folder.

Place the canary file in a location where it will not be deleted, moved, renamed, or otherwise changed by other processes. Do not place the canary file in a location that is regularly purged or used as the source or destination of a 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 write and read canary files and compare timestamps to determine the health of each backend. This is the most thorough method for verifying connectivity, accessibility, and backend health.

Passive health checks only read canary files. Use passive checks when the backend has read-only permissions, and 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. The threshold sets the number of consecutive successful or unsuccessful connection attempts required to change the health state of a backend. The default threshold is 1.

For example, with a threshold of 5, it takes 5 consecutive failed connection attempts to mark a backend as unhealthy, and 5 consecutive successful connection attempts to mark it healthy again.

Health Status

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

Healthy

A status of Healthy indicates that the backend is operational with no connectivity or access issues. The backend is available 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 for the number of consecutive attempts 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 as a fallback in the pool of high availability connections, and is only used when no healthy members exist in the pool.

The Degraded status clears automatically when consistent connectivity with the backend resumes.

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 is available whenever the status of the backend is Desynced.