Near-Zero RPO
Synchronous commit replication means the standby database has every file the primary has. No backup window, no snapshot lag, no lost manifests.
Store every file in SQL Server with Always On replication. If the primary fails, the standby replica has every shipping manifest, every invoice, every file — ready for instant read-only access.
A logistics company processes thousands of shipping manifests daily. If a file server fails and manifests are lost, shipments stop, customers wait, and penalties accumulate. Traditional file-level backup is slow, complex, and never truly real-time.
With files on disk, disaster recovery means maintaining a parallel backup system — rsync scripts, snapshot schedules, and offsite replication. Recovery point objectives (RPO) are measured in hours, not seconds.
If the primary server fails, restoring from backup takes time. Even with hourly snapshots, the most recent files are lost. And testing the failover path is disruptive enough that most teams never do it.
The logistics company needs every manifest replicated in real time to a standby site — with zero additional backup infrastructure to manage.
✗ Files on disk = separate backup system
✗ RPO measured in hours (snapshot lag)
✗ Restore from backup takes hours
✗ Failover path rarely tested
✗ Lost manifests = stopped shipments
✗ Penalties for late deliveries
Stylus SFTP Server stores all files in SQL Server. Always On Availability Groups replicate every file to the standby data center in real time. A second SSS instance pointed at the readable replica provides instant read-only failover access — no restore step needed.
SQL Server Always On replicates every file in real time. The standby SSS instance provides read-only access during failover — no restore step, no data loss.
Two SSS instances, two SQL Server replicas, one Always On Availability Group. The primary is read-write; the standby is read-only and points at the readable secondary.
<filesystem
xmlns="http://www.xmlpipelineserver.com/sftp/">
<storage-backend>database</storage-backend>
<home-root>/${username}</home-root>
<default-access>read-write</default-access>
</filesystem>
<jdbc>
<url>jdbc:sqlserver://sql-primary.logistics.local:1433;
databaseName=sftpdb;encrypt=true;
applicationIntent=ReadWrite</url>
</jdbc>
<!-- DB password secured in credential store -->
<!-- credentials.p12 contains db.password entry -->
<jdbc>
<url>jdbc:sqlserver://sql-replica.logistics.local:1433;
databaseName=sftpdb;encrypt=true;
applicationIntent=ReadOnly</url>
</jdbc>
<filesystem
xmlns="http://www.xmlpipelineserver.com/sftp/">
<storage-backend>database</storage-backend>
<home-root>/${username}</home-root>
<default-access>read-only</default-access>
<!-- Standby serves downloads during failover -->
<!-- DNS CNAME switches sftp.logistics.com to standby -->
</filesystem>
# Store the DB password securely (both primary and standby)
admin.bat credential-set --key db.password
Enter value: ********
Stored in credentials.p12
# SSS automatically composes the H2/SQL Server password
# from credentials.p12 at startup — no plaintext in config
Synchronous commit replication means the standby database has every file the primary has. No backup window, no snapshot lag, no lost manifests.
The standby SSS instance is always running and connected to the readable secondary. A DNS CNAME switch provides read-only access in seconds — no restore step.
Files live in the database. Your DBA's existing backup, replication, and point-in-time recovery strategy covers file data automatically. One fewer system to manage.
SQL Server Transparent Data Encryption (TDE) encrypts file content at the storage layer. Credential Store secures the database password in a PKCS12 keystore protected by a master key.