Offsite NAS & backup-tool protocols: rsync vs SFTP vs SMB vs S3 vs WebDAV (2026)
A practical matrix of which protocols each NAS and backup tool can actually emit — and the traps where a tool simply cannot send over the protocol you assumed. Read it before designing any offsite backup path.
How this matrix was built — honest status
Compatibilities are established from vendor documentation plus the ingestion capabilities of an OpenMediaVault gateway. Field validations are ongoing — the first test is Synology Hyper Backup → rsync. We do not claim anything as « tested » beyond what is stated here.
Three principles that drive the protocol choice
Before reading a single cell, internalise these three rules — they explain why the recommendation lands on rsync first.
1 · Everything rides inside a dedicated VPN tunnel
All ingestion flows through a dedicated VPN tunnel (WireGuard / OpenVPN) — the Gateway never exposes ingestion in clear text on the Internet. As a result, application-level encryption (FTPS, WebDAV-S, rsync-over-SSH) becomes a bonus, not an obligation, since the VPN already encrypts. That is exactly what lets you calmly accept rsync-daemon / FTP / SMB.
2 · The protocol preserves the source's native versioning/dedup
Protocol choice is made on preserving the source's native versioning/dedup, not on encryption: rsync keeps Synology's
.hbkand QNAP's QuDedup; file/object protocols (S3, SMB, WebDAV, FTP) drop raw data.3 · Downstream, the input protocol no longer matters
Downstream, the input protocol does not matter: the Gateway buffers → Nimbus replicates to PBS (Primary → AirGap → LTO), and it is PBS that applies dedup + immutability on the target side. The ingestion protocol only affects the source side, not the final protection.
Note: towards the Gateway there is no front-end deduplication — it stores raw data, dedup happens downstream. The Gateway is a multiplexer of non-Proxmox injection sources (NAS, Linux, Windows…): its buffer is itself backed up to PBS, then AirGap and LTO, so Gateway → PBS → LTO is fully supported — ingesting to the Gateway is not a dead end. Proxmox VMs, by contrast, go straight to PVE → PBS without passing through the Gateway (≈ 10% dedup with few VMs, up to ≈ 25% with many homogeneous VMs).
Resulting rule — rsync as the primary path whenever the source can emit it (versioning preserved), S3 for the object/immutable angle, everything else as a fallback.
Gateway support legend (OpenMediaVault)
Each cell tells you how an OMV gateway receives the protocol — not just whether the protocol exists.
What each client can emit
One table per source. Watch the ⛔ cannot emit rows — that is where most offsite designs break.
Synology
— Hyper Backup| Protocol (tool) | Gateway support |
|---|---|
| rsync (File Server) | ✅ core |
| WebDAV | ✅ plugin |
| S3-compatible (Cloud Service) | 🟡 MinIO |
| OpenStack Swift | ❌ (no OMV backend) |
Dedicated page: offsite Synology backup →
Recommended protocol — Hyper Backup → rsync (File Server category, over the VPN). Preserves .hbk versioning + granular restore even to a generic target; Gateway core, zero friction.
| Option | Status | When |
|---|---|---|
| rsync | ✅ recommended | default |
| WebDAV-S (HTTPS) | ✅ fallback | if rsync is filtered |
| S3-compatible (→ MinIO) | 🟡 alternative | client wants object storage (raw deposit, but .hbk keeps versioning) |
| SMB / FTP / SFTP | ❌ | Hyper Backup does not emit them |
| OpenStack Swift | ❌ | not received by the Gateway |
Client side: Hyper Backup → Create → File Server (rsync) → Gateway VPN IP + rsync account/module → enable client-side AES-256 encryption (recommended) → schedule + retention → integrity check.
Gateway side: rsyncd module (Server tab) or rsync-over-SSH, inside the VPN.
⛔ Cannot emit: SMB/CIFS, FTP, SFTP — Hyper Backup does not offer them as a destination (the #1 mistake of naive matrices).
⛔ Cloud Sync adds S3/WebDAV/Swift but that is file sync, NOT versioned backup.
QNAP
— HBS 3| Protocol (tool) | Gateway support |
|---|---|
| rsync (Remote Server) | ✅ core |
| FTP/FTPS | ✅ core |
| SMB/CIFS | ✅ core |
| WebDAV | ✅ plugin |
| S3-compatible | 🟡 MinIO |
| RTRR (proprietary) | ❌ (needs a QNAP/RTRR receiver) |
Dedicated page: offsite QNAP backup →
Recommended protocol — HBS 3 → rsync (Remote Server) with version management enabled. Triggers QuDedup (source-side dedup + versions); rsync is the only generic path that preserves QNAP dedup. Gateway core.
| Option | Status | When |
|---|---|---|
| rsync (Remote Server) | ✅ recommended | default (QuDedup) |
| S3-compatible (→ MinIO) | 🟡 alternative | object/immutable angle (raw deposit, no QuDedup) |
| FTPS / SMB / WebDAV-S | ✅ fallback | simple configs over the VPN |
| SFTP | ❌ | not supported by HBS 3 |
| RTRR | ❌ | requires a QNAP receiver |
Client side: HBS 3 → Backup & Restore → New Backup Job → Remote Server (rsync) → Gateway VPN IP + rsync creds → Enable version management (QuDedup) → encryption port → schedule.
Gateway side: rsyncd module inside the VPN.
⛔ Cannot emit: SFTP (not documented in HBS 3). The “rsync encryption” goes through SSH ≠ SFTP.
TrueNAS
— CORE / SCALE| Protocol (tool) | Gateway support |
|---|---|
| rsync (task / SSH) | ✅ core |
| SFTP (Cloud Sync / rclone) | ✅ core |
| FTP (Cloud Sync) | ✅ core |
| WebDAV (Cloud Sync) | ✅ plugin |
| S3-compatible (Cloud Sync) | 🟡 MinIO |
| ZFS replication (send/recv) | ❌ (needs ZFS+SSH on the Gateway, not a file server) |
Dedicated page: offsite TrueNAS backup →
Recommended protocol — Rsync Task (or Cloud Sync → SFTP/S3). ⛔ ZFS replication = no (requires ZFS on the target).
⛔ ZFS send/recv is a trap on a generic gateway: it requires ZFS and SSH on the receiving side, not a plain file server.
Unraid
— User Scripts / containers| Protocol (tool) | Gateway support |
|---|---|
| rsync (User Scripts) | ✅ core |
| SMB/NFS (mount) | ✅ core |
| SFTP (restic / rclone) | ✅ core |
| FTP (rclone) | ✅ core |
| WebDAV (rclone) | ✅ plugin |
| S3-compatible (restic / rclone) | 🟡 MinIO |
Dedicated page: offsite Unraid backup →
Recommended protocol — rsync (User Scripts) or restic → SFTP/S3.
Depends on the chosen container — not an “official Unraid” feature, but real, working paths.
Linux server
— rsync / restic / rclone / Duplicati| Protocol (tool) | Gateway support |
|---|---|
| rsync (SSH / daemon) | ✅ core |
| SFTP (restic / rclone / Duplicati) | ✅ core |
| FTP/FTPS (rclone / Duplicati) | ✅ core |
| WebDAV (rclone / Duplicati) | ✅ plugin |
| S3-compatible (restic / rclone) | 🟡 MinIO |
| BorgBackup ssh:// | ❌ (needs borg on the Gateway) |
| restic REST server | ❌ (needs rest-server on the Gateway) |
Dedicated page: offsite Linux server backup →
Recommended protocol — restic → SFTP (or S3) for app-level dedup/encryption; rsync for a mirror. ⛔ Borg / restic-REST = no (require the binary on the Gateway).
⛔ Borg ssh:// and the restic REST server are traps: both require dedicated peer software running on the receiving gateway, not a generic file target.
Windows
— server / workstation| Protocol (tool) | Gateway support |
|---|---|
| SMB/CIFS (Veeam, robocopy, wbadmin) | ✅ core |
| SFTP (restic / Duplicati / Duplicacy) | ✅ core |
| FTP/FTPS (Duplicati) | ✅ core |
| WebDAV (Duplicati) | ✅ plugin |
| S3-compatible (Veeam, restic, SQL 2022) | 🟡 MinIO |
| rsync | ❌ (not native to Windows) |
Recommended protocol — Veeam Agent → SMB (or S3); plus the alternative path NimbusBackupClient → PBS direct (outside the Gateway).
Databases / business software
— pattern “local dump → transport”| Protocol (tool) | Gateway support |
|---|---|
| SFTP | ✅ core |
| FTP/FTPS | ✅ core |
| SMB | ✅ core |
| rsync | ✅ core |
| S3 (rclone / SQL 2022 BACKUP TO URL) | 🟡 MinIO |
Dedicated page: offsite database backup →
Recommended protocol — dump → transport pattern; SFTP or rsync.
The database speaks no network protocol of its own — you dump locally, then the transport is what matters.
Coverage at a glance (protocol × clients)
✅ can emit · ❌ cannot · ➖ possible but redundant / not the natural path.
| Protocol | Syno | QNAP | TrueNAS | Unraid | Linux | Windows | DB | Gateway tier |
|---|---|---|---|---|---|---|---|---|
| rsync | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | core |
| S3-compatible | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 🟡 MinIO |
| WebDAV | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ➖ | plugin |
| SMB/CIFS | ❌ | ✅ | ➖ | ✅ | ➖ | ✅ | ✅ | core |
| SFTP | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | core |
| FTP/FTPS | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | core |
Which protocol should you choose?
Lean, maintained set: rsync + S3 + SMB (with WebDAV as a second NAS option and SFTP for Linux / Windows / databases). Swift and iSCSI stay out.
- S3-compatible — the only protocol all seven clients can emit (including Synology and QNAP). Universal candidate #1, despite the MinIO / API-only friction.
- rsync — covers every NAS and Linux server (everything except Windows), in core, and keeps Synology's
.hbkversioning even when targeting a « dumb » destination. - WebDAV — the only other protocol shared by both Synology and QNAP: a multi-NAS safety net.
- SFTP — universal except the two NAS brands: essential for Linux / Windows / TrueNAS / databases, useless for Synology and QNAP.
- SMB/CIFS — the Windows pivot.
- FTP/FTPS — legacy, redundant with rsync / S3: drop it unless explicitly required.
And with Nimbus?
Nimbus is one possible ingestion target among others. The OpenMediaVault gateway receives these standard protocols (rsync, S3, SMB, SFTP, WebDAV, FTP), then Nimbus protects them to Proxmox Backup Server — immutable, with optional AirGap and LTO archival.
Immutable PBS
Each backup locked against modification and deletion during retention.
PBS AirGap
An optional physically disconnected copy, beyond network reach.
LTO archival
Cold, long-term WORM tape kept in a secure vault.
Adjacent proof — first 1 TB Windows backup to PBS
On a 1 TB Windows server, the first PBS backup transferred 876 GB in 20h30, with 75 % deduplicated chunks and 57 % end-to-end savings. Note: this REX is the NimbusBackupClient → PBS direct path — not the gateway — cited here as adjacent evidence of the PBS chain. Read the case study → To map these figures onto your own volume and bandwidth, estimate your backup window.
Frequently asked questions
Designing an offsite path?
We map the right protocol for each source, then build the ingestion and PBS protection around it. 15-minute technical call, no strings attached.