Do you need a load balancer for SFTP high availability?

Yes. CompleteFTP does not distribute client connections itself, so an external load balancer is required. It can be a hardware appliance or a software solution such as Microsoft Network Load Balancing. The load balancer must operate at the TCP layer, because SFTP is not HTTP and cannot be inspected or routed by an HTTP-aware proxy.

Is a cluster the same thing as disaster recovery?

No. A cluster protects against the loss of a node inside one site. Disaster recovery protects against the loss of the site itself, and usually involves a separate server in another location holding a copy of the configuration and the user data. CompleteFTP documents a distinct DR procedure based on copying config.db and restoring the DR server's own activation key, and that procedure is not used on clustered servers.

High Availability SFTP: Active-Active Clustering on Windows

Q: What is an active-active SFTP cluster?

An active-active SFTP cluster is a set of servers that all accept client connections at the same time, sitting behind a load balancer that distributes incoming connections between them. Every node holds the same configuration and reaches the same file storage, so a client gets the same service whichever node it lands on. If one node stops responding, the load balancer stops sending it connections and the remaining nodes carry the traffic.

Q: What is the difference between active-active and active-passive SFTP?

In active-passive, one server handles all traffic while a standby sits idle until a failover promotes it. In active-active, every node serves clients concurrently. Active-passive is simpler to reason about but wastes the standby and introduces a failover gap. Active-active removes the gap and lets configuration changes propagate to running servers, which is why CompleteFTP clustering is designed around it.

Q: Does an SFTP cluster need shared storage?

It needs shared storage or file replication. CompleteFTP clustering synchronises server configuration between nodes, but it does not synchronise user files. Either point every node at shared network storage such as a NAS or SAN, or replicate the file trees between nodes with something like Windows DFS.

Q: Can OpenSSH do high availability?

OpenSSH has no clustering feature. You can place several sshd hosts behind a load balancer, but you then have to keep host keys, user accounts, chroot definitions, key files and sshd_config identical across every host yourself, usually with a configuration management tool. The protocol behaves fine in that arrangement; the work is in the configuration drift you now own.

Most SFTP deployments start as one server on one machine, and for a long time that is a perfectly reasonable design. The question of high availability tends to arrive later, prompted by something specific: an SLA a business unit has signed, an auditor asking what happens when the file transfer host reboots, or a Windows update that took the server down while a partner was mid-upload. The answer to whether the SFTP server can be clustered has more parts to it than the word "cluster" implies.

Do you actually need HA SFTP?

The starting question is what an hour of downtime costs you, and whether anyone has ever measured it.

When high availability earns its cost

Redundancy is straightforward to justify when a contract makes the availability of file transfer a legal obligation rather than an internal preference. Managed service providers who accept files on behalf of clients are in that position, as are organisations in payments, healthcare messaging and logistics where an inbound feed missing its window has consequences measured in fines or stalled shipments. Interactive transfer patterns are another, because a partner uploading during business hours sees an outage the moment it happens.

Planned maintenance is a third, and often the one that earns the cluster its keep. A cluster lets you patch Windows, upgrade the file transfer software and reboot hardware without arranging an outage window and notifying every partner, which for teams patching monthly can matter more than the failure scenario the cluster was bought for.

The request commonly arrives with production already running and the second server being fitted around it:

"Please, I need your recommendations to configure high availability to the SFTP service, add a second Server 2 to configure a Cluster with a main Server 1 already in production."

a Chilean payments organization (EnterpriseDT support archive)

When a single server is the right answer

If your transfers are batch jobs with automatic retries, the partners are internal, and an unplanned hour of downtime means files arrive an hour later with no other consequence, a cluster is a large amount of machinery bought for a problem you do not have. You would be adding a load balancer, a second Windows Server licence, a second CompleteFTP Enterprise MFT licence, shared or replicated storage, and a permanent obligation to keep several nodes on the same software version. A single well-backed-up server with a documented and tested rebuild procedure is often the better engineering decision, and shortening the restore time can do more for real availability than clustering would.

Active-active and active-passive are different designs

Active-passive

One server handles all client traffic while a second sits idle, holding a copy of the configuration and either sharing storage or receiving a replica of it. When the active server fails, something promotes the standby: a clustering layer, a monitoring script, a DNS change, or a person at 3am.

You pay for a machine doing nothing most of the time, a real gap exists between failure and promotion, and a standby that has never taken traffic has a readiness you are assuming rather than observing. A further problem is specific to file transfer servers, in that configuration changes made on the active server have to reach the standby somehow. A standby that is powered off cannot receive them at all; one that is powered on can, but by then it is doing everything an active node does except serving clients. CompleteFTP's clustering is built around an active-active arrangement partly for this reason: if the second server is running anyway, there is little to gain from holding it back from traffic.

Active-active

Every node runs and accepts connections, with a load balancer distributing incoming connections between them. All nodes hold the same configuration and see the same files, so a client receives equivalent service regardless of which node it reaches. Failure handling becomes a routing decision rather than a promotion event: when a node stops answering health checks the load balancer stops sending it new connections, and sessions already established there are lost and reconnect elsewhere. Each node carries production traffic continuously, so a fault shows up during normal operation instead of at the moment of failover.

What high availability requires architecturally

Use a layer-4 (TCP) load balancer

SFTP runs over SSH on a single TCP connection and the load balancer cannot see inside it, so anything expecting to parse HTTP headers, terminate TLS or route on a URL path is the wrong tool. What you need is layer-4 balancing with a TCP health check against the SFTP port, which every hardware load balancer supports and which Microsoft Network Load Balancing provides as a software option. CompleteFTP does not distribute client connections itself, so uneven load is a load balancer configuration issue.

Shared storage or replication

CompleteFTP clustering synchronises server configuration between nodes. It does not synchronise user files, and assuming otherwise is a documented source of confusion. There are two ways to give every node the same view of the files:

Local storage on each node, replicated between them with something like Windows DFS, which converges in near real time at the price of running and monitoring the replication.
One shared NAS or SAN behind every node, which is simpler but makes the storage a single point of failure unless it has redundancy of its own.

Configuration synchronisation

Users, groups, folder permissions, site definitions, protocol settings, triggers and IP filtering rules all have to be identical on every node, and keeping them so by hand breaks down as soon as the change rate picks up. In a CompleteFTP cluster one server is designated the primary, and all configuration changes are made through the CompleteFTP Manager connected to it. The primary propagates those changes to the secondaries, which apply them and serve clients, so all administration happens in one place while every node serves traffic.

The host keys are part of that synchronised configuration, so every node presents the same fingerprint to clients, which matters when partners have pinned it. It is worth confirming after setup rather than assuming:

"I noticed that the fingerprint for ED25519 public key is different on server 1 and 2 in my cluster (two servers using standard CompleteFTP sync). RSA, DSA and ECDSA are fine, same fingerprint/thumbprint on both servers but ED25519 hasn't synced."

a Swedish insurance administration organization (EnterpriseDT support archive)

Session affinity

For FTP, FTPS and SFTP an entire session lives inside one connection, so once a client lands on a node it stays there until it disconnects, and no session affinity configuration is needed. HTTP and HTTPS behave differently, because each web session in CompleteFTP is local to the server the client connected to, so the load balancer must be configured for session stickiness, typically by source IP or cookie.

Setting up an active-active cluster in CompleteFTP Enterprise MFT

Clustering is available in the CompleteFTP Enterprise MFT edition. Each server in the cluster needs its own Enterprise MFT licence, and all servers must run the same version of CompleteFTP.

The practical questions tend to arrive together:

"We have a CompleteFTP installed & running in a stand alone server. We are planning to add an additional server to this FTP server to configured a cluster or any form of physical redundancy."

a US data infrastructure organization (EnterpriseDT support archive)

Licences, whether the second machine has to match the first, whether it can be done without downtime, and how shared storage fits in are the recurring ones, and the rest of this section answers them in order.

Licensing and activation

Each server, including the primary, is normally activated separately to obtain and set its own activation key. Volume License customers holding a universal activation key have a shortcut: install the UAK on the primary first and it is propagated automatically to each secondary as that secondary joins, activating it out of the trial state.

Preparing the secondaries

The primary reaches each secondary over port 14983 by default, using SFTP for server-to-server communication so configuration data in transit is encrypted, and that port must be open in both directions.

Each secondary also filters admin connections by IP and by default permits only localhost or LAN addresses. On each secondary, open CompleteFTP Manager, enable "Show system users/folders/sites" from the Options menu, select the Sites panel, choose the Admin site, then edit the "IP filtering" property in the "IP filtering and Auto-banning" category to allow the primary server's address. Restrict that rule to the primary and the other cluster members rather than opening it broadly.

Adding nodes

On the primary, select "Servers" from the side-bar menu to open the Servers panel, then click "Add server". Enter the secondary server's details, including admin credentials that exist on that secondary, click "Next", then "Add". Wrong credentials, a blocked port 14983, an IP filter that still excludes the primary, and a version mismatch account for most failures here.

Synchronisation settings

Each secondary has a "Sync enabled" checkbox in the Servers panel controlling whether it receives configuration changes, and it should stay enabled outside deliberate maintenance. Synchronisation runs every 60 seconds by default, adjustable per secondary through right-click, "Properties", "Synchronization Interval". When a secondary has drifted after a network interruption, right-click it and choose "Force configuration update".

Load balancer configuration

Configure a TCP virtual service on port 22, or whichever port your SFTP site uses, pointing at every node, with a TCP health check against the same port. If you also publish the web interface, add a separate virtual service for it with session stickiness enabled. One useful variation is to direct most client traffic to the secondaries, leaving the primary to configuration management, though the synchronisation load on the primary is light enough that this matters only on busy clusters.

Testing failover

Stop the CompleteFTP service on each active node in turn and confirm that new connections continue to succeed and that a client connected to the stopped node reconnects rather than hanging. Make a configuration change on the primary and confirm on each secondary that it arrived. Stop the primary itself and confirm that traffic to the secondaries is unaffected.

Operating a cluster

Upgrading without taking the cluster down

Upgrades follow a specific order. Secondaries are upgraded first and the primary last, with the primary's service stopped throughout, and with no configuration changes made anywhere for the duration.

Configure the load balancer to direct traffic away from the primary, close CompleteFTP Manager on it and stop its service. Then take each secondary one at a time: remove it from the load balancer pool, close Manager, stop the service, run the new installer over the existing installation using the same administrator password as the primary, let the service restart, and return the node to the pool. Then run the installer over the primary, start its service, and reintroduce it. The secondaries cannot synchronise while the primary is stopped, which is expected and resolves as soon as it is back.

Whether this is genuinely zero-downtime depends on the cluster carrying its normal load with one node out of the pool at a time.

Scaling and changing the primary

Adding a node later uses the same "Add server" flow, so a cluster can grow as demand does. Removing one is a right-click and "Remove server", after which that machine reverts to a standalone server carrying the configuration it had at the time. Promoting a secondary is also a right-click, "Select as primary". If the old primary has failed outright, that promotion restores configuration synchronisation across the remaining nodes, and clients on the secondaries were never interrupted.

Disaster recovery is a separate problem

A cluster protects against the loss of a node. It does not protect against the loss of the site, the storage or the datacentre, and nodes that share a rack and a SAN sit in a single failure domain however many of them there are.

CompleteFTP documents a distinct DR procedure for a server in another location, based on regularly copying config.db and the user home directories from the primary, then restoring the DR machine's own activation key with the license utility, since the copied config.db carries the source machine's key. That utility is not used with clustered servers, because clusters replicate configuration themselves; the copy-and-restore procedure is mainly for Professional-edition users who do not have clustering at all.

Monitoring cluster health

The Servers panel shows each node's state as Online, Offline or Synchronizing along with its last synchronisation time. Logs are per-server, under C:\ProgramData\Enterprise Distributed Technologies\Complete FTP\Logs, and Manager generally shows only the logs of the server it is connected to, so secondary logs are read from the file system.

Worth monitoring externally as well: the load balancer's health checks, the replication or shared storage layer, and synchronisation age per node. A secondary that quietly stopped synchronising keeps serving clients from a configuration that is weeks out of date, and the first sign of it can be a revoked user still logging in successfully.

Replication failures are usually noticed through their effects rather than through an alert:

"When we are creating Events on the first server in a cluster, they are not replicating to the secondary server."

an Israeli clearing and settlement organization (EnterpriseDT support archive)

Why OpenSSH is hard to run in an HA arrangement

OpenSSH has no clustering feature and no concept of a peer server, though several sshd hosts behind a load balancer will work, because the protocol has no cross-connection state to preserve.

The work lands elsewhere. Host keys must be identical across nodes or clients will report a changed host key on every failover and, depending on their configuration, refuse to connect. Local accounts, chroot definitions, authorized_keys files, sshd_config and per-user restrictions have to be kept in step by a configuration management tool you now maintain as part of the file transfer service.

Frequently asked questions

What is an active-active SFTP cluster?

A set of servers that all accept client connections simultaneously, behind a load balancer that distributes connections between them. Every node holds the same configuration and reaches the same file storage, so a client gets equivalent service whichever node it reaches.

How do you set up SFTP failover?

Stand up more than one SFTP server, give them a common view of the files through shared storage or replication, keep their configuration synchronised, and put a TCP load balancer in front with a health check on the SFTP port. Failover is then the balancer removing an unhealthy node from rotation.

Do you need a load balancer for SFTP HA?

Yes, in practice. CompleteFTP does not distribute client connections itself, so an external load balancer does that work, either a hardware appliance or software such as Microsoft Network Load Balancing. DNS round-robin has no health awareness, so failed nodes keep receiving connections.

What is the difference between active-active and active-passive SFTP?

In active-passive one server serves clients while a standby waits to be promoted; in active-active every node serves clients concurrently. Active-active avoids the failover gap, and because every node is running their configuration stays in step; a standby only receives configuration updates while it is powered on, so if it is running anyway there is little reason not to let it serve clients too.

Can OpenSSH do high availability?

Not on its own. Several sshd hosts behind a load balancer will work, but host keys, accounts, key files and configuration have to be kept identical across those hosts by a configuration management tool you maintain.

Does an SFTP cluster need shared storage?

It needs shared storage or file replication, because CompleteFTP clustering keeps configuration in step between nodes but does not synchronise user files.

Where to start

If clustering looks warranted, build it once in a test environment before committing to hardware. Two virtual machines, a software load balancer and a file share are enough to run the procedure end to end, including stopping a node to see what a connected client experiences.

Clustering is part of CompleteFTP Enterprise MFT, which runs on Windows and covers SFTP, FTPS, FTP and HTTPS on the same server. Background on the underlying server is in our SFTP server guide, and the wider context of managed file transfer capabilities is in MFT vs SFTP. The Enterprise MFT trial is a full build, so a two-node test cluster can be assembled from it directly. For a multi-region or unusually large deployment, ask to talk to engineering, and an engineer will answer.