Dernière mise à jour: 2026-07-09
rsync reflète des dossiers depuis 1996, et ce n'est pas un hasard : synchronisation bidirectionnelle, un algorithme de transfert différentiel à somme de contrôle glissante qui ne transmet que les octets réellement modifiés à l'intérieur d'un fichier, et des décennies d'options pour chaque cas particulier. Si vous avez déjà un accès SSH et connaissez rsync, il est très difficile à surpasser.
La commande sync de Relayium couvre une tâche plus étroite — un miroir incrémental à sens unique — mais elle supprime une étape que rsync suppose déjà faite : la configuration de SSH. Elle fonctionne par SSH si vous en avez déjà un, ou connecte directement deux machines sans aucun serveur SSH. Cet article compare les deux honnêtement : sync n'est pas un remplacement complet de rsync, et la FAQ le dit clairement.
rsync est bidirectionnel — n'importe quel côté peut être la source — et son algorithme de transfert différentiel compare les blocs d'un fichier par somme de contrôle glissante, si bien qu'une petite modification dans un fichier énorme n'envoie que les blocs changés, pas le fichier entier. Ajoutez à cela des décennies d'options (--exclude, --link-dest pour des instantanés par liens durs, la compression, des limites de bande passante, et plus), et vous obtenez le bon outil pour énormément de tâches.
Il est aussi partout : la plupart des systèmes Linux et macOS l'incluent, et il fonctionne sur une connexion SSH que vous avez probablement déjà configurée. Rien de tout cela n'est ce que Relayium sync cherche à remplacer.
relayium sync <sources...> <destination> [--delete] [--watch] est un miroir incrémental à sens unique : il compare la taille et la date de modification de chaque fichier, ignore ce qui correspond déjà, et envoie le reste.
Il fonctionne via deux transports. Pointez-le vers user@host:/dest et il passe par SSH — mais relayium doit déjà être installé sur la machine distante ; contrairement à push, sync n'a pas de repli tar. Pointez-le plutôt vers relayium://host[:port] et il se passe entièrement de SSH : une connexion TLS 1.3 épinglée directement vers un processus relayium serve à l'écoute sur l'autre machine, authentifiée par l'empreinte de cette machine (approuvée une fois, mémorisée ensuite). C'est cette seconde voie qui apporte le vrai confort : pas de sshd à configurer, pas de clés SSH à gérer — juste deux machines avec relayium installé et un port ouvert entre elles.
relayium sync ./photos user@host:/backup/photos # over SSHrelayium sync ./photos relayium://203.0.113.9:9031 # daemon direct, no SSHPar défaut, sync ne fait qu'ajouter et mettre à jour — il ne supprime jamais rien de lui-même. Passez --delete pour refléter aussi les suppressions, mais le récepteur doit y consentir explicitement : il doit tourner avec relayium serve --allow-delete. Sinon, la demande de suppression est refusée et signalée à l'expéditeur plutôt qu'ignorée silencieusement.
Pour un dossier qui change en continu, --watch fait tourner sync après le premier passage et reflète de nouveau dès qu'un fichier change sous la source — rsync n'a rien d'intégré pour cela ; on se tourne normalement vers une tâche cron ou un outil comme lsyncd.
relayium serve --dir /backup --port 9031 --allow-deleterelayium sync ./photos relayium://203.0.113.9:9031 --delete --watchChaque fichier est vérifié de bout en bout par un hachage SHA-256, et un transfert interrompu en plein milieu d'un fichier reprend à partir de l'octet déjà présent sur le disque plutôt que de tout recommencer — utile pour les mêmes raisons que chez rsync.
Il faut être clair sur ce que la reprise n'est pas : ce n'est pas l'algorithme différentiel de rsync. Si un fichier est déjà entièrement présent mais a une taille ou un horodatage différent, sync le retransmet en entier plutôt que de comparer les blocs modifiés à l'intérieur. Pour un unique fichier énorme qui change légèrement et souvent, le transfert différentiel de rsync déplacera moins de données. sync ne gère aussi que les fichiers réguliers — les liens symboliques et fichiers spéciaux sont ignorés, donc tout ce qui en dépend doit être traité séparément.
Choisissez rsync quand la synchronisation doit aller dans les deux sens, quand SSH est déjà configuré et que vous ne voulez pas d'un démon supplémentaire, quand vous avez besoin d'un contrôle fin (exclusions, filtres, instantanés par liens durs, limites de bande passante, compression), ou quand un fichier change légèrement et souvent et que le transfert différentiel économise vraiment de la bande passante. Relayium sync ne cherche à couvrir aucun de ces cas.
Non. Il ne fait qu'un miroir à sens unique et n'a pas d'algorithme différentiel par blocs comme rsync — un fichier dont la taille ou l'horodatage a changé est retransmis en entier, et il a beaucoup moins d'options que rsync. Si vous avez besoin d'une synchronisation bidirectionnelle, d'un contrôle fin par filtres, ou si vous comptez sur l'écosystème mature de rsync, rsync reste le meilleur outil.
Non. Le mode démon direct (relayium://host:port) se passe entièrement de SSH : une connexion TLS épinglée, authentifiée par l'empreinte du récepteur, approuvée une fois puis mémorisée. Vous pouvez aussi passer par SSH (user@host:path), mais relayium doit alors être installé sur la machine distante — et contrairement à push, sync n'a pas de repli tar.
Seulement si vous passez --delete et que le serve du récepteur tourne avec --allow-delete. Sinon, la demande de suppression est refusée et signalée à l'expéditeur, pas ignorée silencieusement.
Oui, avec --watch. Après le premier miroir, sync continue de tourner et reflète de nouveau (avec un anti-rebond) dès qu'un fichier change sous la source.
Oui. La CLI Relayium est entièrement gratuite, et aucun mode — sync compris — ne nécessite de compte.
Reflétez un dossier entre deux de vos propres machines — sans serveur SSH requis.
Obtenir la CLI