Protocoles de sauvegarde NAS externalisée : rsync, SFTP, SMB, S3, WebDAV
Une matrice concrète des protocoles que chaque NAS et outil de sauvegarde sait réellement émettre — et les pièges où un outil ne peut tout simplement pas envoyer via le protocole que vous croyiez. À lire avant de concevoir un chemin de sauvegarde externalisée.
Comment cette matrice est établie — statut honnête
Compatibilités établies d'après la documentation des éditeurs + les capacités d'ingestion d'une Gateway OpenMediaVault. Validations terrain en cours — premier test : Synology Hyper Backup → rsync. Rien n'est revendiqué comme « testé » au-delà de ce qui est indiqué ici.
Trois principes qui dictent le choix du protocole
Avant de lire la moindre cellule, intégrez ces trois règles — elles expliquent pourquoi la reco tombe sur rsync en premier.
1 · Tout transite dans un tunnel VPN dédié
Toute l'ingestion passe par un tunnel VPN dédié (WireGuard / OpenVPN) — la Gateway n'expose jamais l'ingestion en clair sur Internet. Conséquence : le chiffrement applicatif (FTPS, WebDAV-S, rsync-over-SSH) devient un bonus, pas une obligation, puisque le VPN chiffre déjà. C'est ce qui permet d'accepter sereinement rsync-daemon / FTP / SMB.
2 · Le protocole préserve le versioning/dédup natif de la source
Le choix du protocole se fait sur la préservation du versioning/dédup natif de la source, pas sur le chiffrement : rsync conserve le
.hbkSynology et le QuDedup QNAP ; les protocoles fichier/objet (S3, SMB, WebDAV, FTP) déposent du brut.3 · En aval, le protocole d'entrée n'a plus d'importance
En aval, peu importe le protocole d'entrée : la Gateway tamponne → Nimbus réplique vers PBS (Principal → AirGap → LTO), et c'est PBS qui applique dédup + immutabilité côté cible. Le protocole d'ingestion n'impacte que le source-side, pas la protection finale.
À noter : vers la Gateway, pas de déduplication en frontal — elle stocke du brut, la dédup arrive en aval. La Gateway est un multiplexeur de sources d'injection non-Proxmox (NAS, Linux, Windows…) : son tampon est lui-même sauvegardé vers PBS, puis AirGap et LTO, donc Gateway → PBS → LTO est pleinement supporté — ingérer vers la Gateway n'est pas un cul-de-sac. Les VMs Proxmox, elles, vont directement en PVE → PBS sans passer par la Gateway (≈ 10 % de dédup avec peu de VM, jusqu'à ≈ 25 % avec beaucoup de VM homogènes).
Règle qui en découle — rsync en primaire dès que la source sait l'émettre (versioning préservé), S3 pour l'angle objet/immuable, le reste en fallback.
Légende — support Gateway (OpenMediaVault)
Chaque cellule indique comment une Gateway OMV reçoit le protocole — pas seulement s'il existe.
Ce que chaque client sait émettre
Un tableau par source. Surveillez les lignes ⛔ ne peut pas émettre — c'est là que la plupart des architectures externalisées cassent.
Synology
— Hyper Backup| Protocole (outil) | Support Gateway |
|---|---|
| rsync (File Server) | ✅ core |
| WebDAV | ✅ plugin |
| S3-compatible (Cloud Service) | 🟡 MinIO |
| OpenStack Swift | ❌ (OMV absent) |
Protocole recommandé — Hyper Backup → rsync (catégorie File Server, sur VPN). Conserve le versioning .hbk + restauration granulaire même vers une cible générique ; core Gateway, zéro friction.
| Option | Statut | Quand |
|---|---|---|
| rsync | ✅ recommandé | défaut |
| WebDAV-S (HTTPS) | ✅ fallback | si rsync est filtré |
| S3-compatible (→ MinIO) | 🟡 alternative | le client veut de l'objet (dépôt brut, mais .hbk garde le versioning) |
| SMB / FTP / SFTP | ❌ | Hyper Backup ne les émet pas |
| OpenStack Swift | ❌ | non reçu par la Gateway |
Côté client : Hyper Backup → Create → File Server (rsync) → IP VPN de la Gateway + compte/module rsync → activer le chiffrement client AES-256 (recommandé) → planification + rétention → integrity check.
Côté Gateway : module rsyncd (onglet Server) ou rsync-over-SSH, dans le VPN.
⛔ Ne peut PAS émettre : SMB/CIFS, FTP, SFTP — Hyper Backup ne les propose pas comme destination (l'erreur n°1 des matrices naïves).
⛔ Cloud Sync ajoute S3/WebDAV/Swift mais c'est de la synchro de fichiers, PAS une sauvegarde versionnée.
QNAP
— HBS 3| Protocole (outil) | Support Gateway |
|---|---|
| rsync (Remote Server) | ✅ core |
| FTP/FTPS | ✅ core |
| SMB/CIFS | ✅ core |
| WebDAV | ✅ plugin |
| S3-compatible | 🟡 MinIO |
| RTRR (propriétaire) | ❌ (exige un récepteur QNAP/RTRR) |
Protocole recommandé — HBS 3 → rsync (Remote Server) avec version management activé. Déclenche QuDedup (dédup + versions côté source) ; rsync est le seul chemin générique qui préserve le dédup QNAP. Core Gateway.
| Option | Statut | Quand |
|---|---|---|
| rsync (Remote Server) | ✅ recommandé | défaut (QuDedup) |
| S3-compatible (→ MinIO) | 🟡 alternative | angle objet/immuable (dépôt brut, pas de QuDedup) |
| FTPS / SMB / WebDAV-S | ✅ fallback | configs simples sur VPN |
| SFTP | ❌ | non supporté par HBS 3 |
| RTRR | ❌ | exige un récepteur QNAP |
Côté client : HBS 3 → Backup & Restore → New Backup Job → Remote Server (rsync) → IP VPN Gateway + creds rsync → Enable version management (QuDedup) → encryption port → planification.
Côté Gateway : module rsyncd dans le VPN.
⛔ Ne peut PAS émettre : SFTP (non documenté dans HBS 3). Le « chiffrement rsync » passe par SSH ≠ SFTP.
TrueNAS
— CORE / SCALE| Protocole (outil) | Support Gateway |
|---|---|
| rsync (task / SSH) | ✅ core |
| SFTP (Cloud Sync / rclone) | ✅ core |
| FTP (Cloud Sync) | ✅ core |
| WebDAV (Cloud Sync) | ✅ plugin |
| S3-compatible (Cloud Sync) | 🟡 MinIO |
| Réplication ZFS (send/recv) | ❌ (exige ZFS+SSH côté Gateway, pas un serveur de fichiers) |
Protocole recommandé — Rsync Task (ou Cloud Sync → SFTP/S3). ⛔ réplication ZFS = non (exige ZFS côté cible).
⛔ La réplication ZFS send/recv est un piège sur une gateway générique : elle exige ZFS et SSH côté réception, pas un simple serveur de fichiers.
Unraid
— User Scripts / conteneurs| Protocole (outil) | Support Gateway |
|---|---|
| rsync (User Scripts) | ✅ core |
| SMB/NFS (montage) | ✅ core |
| SFTP (restic / rclone) | ✅ core |
| FTP (rclone) | ✅ core |
| WebDAV (rclone) | ✅ plugin |
| S3-compatible (restic / rclone) | 🟡 MinIO |
Protocole recommandé — rsync (User Scripts) ou restic → SFTP/S3.
Dépend du conteneur choisi — pas une fonction « officielle Unraid », mais des chemins réels et opérationnels.
Serveur Linux
— rsync / restic / rclone / Duplicati| Protocole (outil) | Support Gateway |
|---|---|
| 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:// | ❌ (exige borg sur la Gateway) |
| restic REST server | ❌ (exige rest-server sur la Gateway) |
Protocole recommandé — restic → SFTP (ou S3) pour dédup/chiffrement applicatif ; rsync si miroir. ⛔ Borg / restic-REST = non (exigent le binaire côté Gateway).
⛔ Borg ssh:// et le restic REST server sont des pièges : tous deux exigent un logiciel pair dédié côté gateway, pas une cible de fichiers générique.
Windows
— serveur / poste| Protocole (outil) | Support Gateway |
|---|---|
| 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 | ❌ (pas natif Windows) |
Protocole recommandé — Veeam Agent → SMB (ou S3) ; + voie alternative NimbusBackupClient → PBS direct (hors Gateway).
Bases de données / logiciels métiers
— pattern « dump local → transport »| Protocole (outil) | Support Gateway |
|---|---|
| SFTP | ✅ core |
| FTP/FTPS | ✅ core |
| SMB | ✅ core |
| rsync | ✅ core |
| S3 (rclone / SQL 2022 BACKUP TO URL) | 🟡 MinIO |
Protocole recommandé — pattern dump → transport ; SFTP ou rsync.
La base ne parle aucun protocole réseau en propre — on fait un dump local, puis c'est le transport qui compte.
Vue couverture (protocole × clients)
✅ sait émettre · ❌ ne sait pas · ➖ possible mais redondant / pas le chemin naturel.
| Protocole | Syno | QNAP | TrueNAS | Unraid | Linux | Windows | BDD | Tier Gateway |
|---|---|---|---|---|---|---|---|---|
| rsync | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | core |
| S3-compatible | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | 🟡 MinIO |
| WebDAV | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ➖ | plugin |
| SMB/CIFS | ❌ | ✅ | ➖ | ✅ | ➖ | ✅ | ✅ | core |
| SFTP | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | core |
| FTP/FTPS | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | core |
Quel protocole choisir ?
Set lean, maintenu : rsync + S3 + SMB (avec WebDAV en 2ᵉ option NAS et SFTP pour Linux / Windows / bases de données). Swift et iSCSI restent dehors.
- S3-compatible — le seul protocole que les sept clients savent émettre (y compris Synology et QNAP). Candidat universel n°1, malgré la friction MinIO / API-only.
- rsync — couvre tous les NAS et Linux (tout sauf Windows), en core, et garde le versioning
.hbkcôté Synology même vers une cible « bête ». - WebDAV — le seul autre protocole partagé par Synology et QNAP : un filet multi-NAS.
- SFTP — universel sauf les deux marques NAS : essentiel pour Linux / Windows / TrueNAS / BDD, inutile pour Synology et QNAP.
- SMB/CIFS — le pivot Windows.
- FTP/FTPS — legacy, redondant avec rsync / S3 : à écarter sauf demande explicite.
Et avec Nimbus ?
Nimbus n'est qu'une cible d'ingestion parmi d'autres. La Gateway OpenMediaVault reçoit ces protocoles standard (rsync, S3, SMB, SFTP, WebDAV, FTP), puis Nimbus les protège vers Proxmox Backup Server — immuable, avec AirGap et LTO en option.
PBS immuable
Chaque sauvegarde verrouillée en modification et suppression pendant la rétention.
PBS AirGap
Une copie physiquement déconnectée, en option, hors de portée du réseau.
Archivage LTO
Bande WORM froide longue durée, conservée en coffre sécurisé.
Preuve adjacente — premier backup Windows 1 To vers PBS
Sur un serveur Windows 1 To, le premier backup PBS a transféré 876 GB en 20h30, avec 75 % de chunks dédupliqués et 57 % d'économie bout-en-bout. À noter : ce REX est le chemin NimbusBackupClient → PBS direct — pas la Gateway — cité ici comme preuve adjacente de la chaîne PBS. Lire l'étude de cas → Pour transposer ces chiffres à votre volume et votre débit, estimez votre fenêtre de sauvegarde.
Questions fréquentes
Vous concevez un chemin externalisé ?
On choisit le bon protocole pour chaque source, puis on construit l'ingestion et la protection PBS autour. Café technique de 15 minutes, sans engagement.