Synchroniser un gros dossier entre deux serveurs (avec reprise, en arrière-plan)

Dernière mise à jour: 2026-08-05

Vous avez un gros dossier — des dizaines de gigaoctets — sur un serveur et vous voulez une copie exacte sur un autre. Vous ne pouvez pas surveiller un terminal pendant des heures, et un transfert qui meurt à mi-chemin ne devrait pas repartir de zéro. relayium sync est fait pour cela : un miroir incrémental à sens unique qui saute ce qui est déjà là, reprend un fichier envoyé à moitié là où il s'est arrêté, et vérifie de bout en bout chaque fichier qu'il envoie.

Ce guide met en place un transfert sans surveillance et auto-réparateur : autorisez l'émetteur une fois, faites tourner le processus à l'écoute en arrière-plan, et pilotez relayium sync depuis une boucle de reprise dans tmux pour qu'il continue malgré les coupures jusqu'à ce que tout le dossier soit arrivé.

Pourquoi relayium sync convient à cette tâche

sync est un miroir incrémental à sens unique via le protocole natif (installez relayium aux deux bouts). Trois propriétés le rendent sûr à exécuter et réexécuter sans surveillance :

Saute les fichiers déjà présents : un fichier dont la copie sur le récepteur correspond par taille et date de modification n'est pas renvoyé.
Reprend les fichiers partiels : si un fichier était à moitié transféré à la coupure, l'exécution suivante continue depuis l'offset d'octets déjà sur le disque au lieu de le recommencer.
Vérifie ce qu'il envoie : chaque fichier transféré — y compris un fichier repris — est contrôlé de bout en bout face au SHA-256 de l'émetteur, et un écart est signalé comme un échec. Les fichiers ignorés sont décidés sur la taille et le mtime, jamais rehachés, et sync ne dit donc rien du contenu qu'il n'a pas envoyé.
De ce fait, la commande est idempotente — la relancer ne fait que le travail restant, ce qui est précisément ce qui permet à une boucle de reprise de terminer un transfert énorme.

Prérequis

Ce qu'il vous faut

Ce guide utilise le daemon-direct (relayium://), les deux serveurs n'ont donc pas besoin d'accès SSH l'un vers l'autre.
Ouvrez le port du processus à l'écoute (9031 par défaut) à l'émetteur dans le pare-feu ou le groupe de sécurité du récepteur.
De la place pour tout le dossier sur le récepteur. Comparez du -sh /root/workspace sur l'émetteur et df -h /root sur le récepteur avant de lancer un transfert de plusieurs heures.

Installez relayium sur les deux serveurs (sync parle le protocole natif, il doit donc être présent à chaque bout) :

# sur les DEUX serveurs
curl -fsSL https://relayium.com/install.sh | sh

Autoriser l'émetteur une fois (sur le récepteur)

Le récepteur approuve la machine émettrice une seule fois ; l'approbation est écrite sur le disque et reste valable après les redémarrages, vous ne la répétez donc jamais. Démarrez d'abord le processus à l'écoute dans un terminal, et pointez --dir vers le répertoire parent — relayium sync /root/workspace reproduit workspace/... sur le récepteur, donc --dir /root fait atterrir les fichiers dans /root/workspace/.

À la première connexion de l'émetteur (section suivante), serve affiche son adresse et son empreinte et vous demande de l'approuver ; répondez y et elle est mémorisée pour de bon :

# sur le RÉCEPTEUR (au premier plan, pour approuver de façon interactive)
relayium serve --dir /root --port 9031

# sur le RÉCEPTEUR, à la première connexion :
Incoming push from 203.0.113.9:52140
  fingerprint: 9f2c41ab…
Accept and remember this peer? [y/N] y

Pour une configuration entièrement sans surveillance, sautez l'invite : lancez relayium id sur l'émetteur pour afficher son empreinte, puis relayium authorize <empreinte> sur le récepteur.
--dir est le parent du dossier que vous synchronisez, pas le dossier lui-même — sinon les fichiers atterrissent un niveau trop bas (p. ex. /root/workspace/workspace).

Faire tourner le processus à l'écoute en arrière-plan (sur le récepteur)

Une fois l'empreinte autorisée, arrêtez le serve au premier plan (Ctrl-C) et relancez-le détaché pour qu'il survive à votre déconnexion. Il charge l'empreinte enregistrée et accepte l'émetteur silencieusement — pas d'invite cette fois. La même ligne note le PID du nouveau processus dans ~/relayium-serve.pid, et c'est ainsi que la dernière étape de ce guide arrête le processus à l'écoute qu'elle a lancé, au lieu de viser toute commande relayium de la machine :

# sur le RÉCEPTEUR
nohup relayium serve --dir /root --port 9031 > ~/relayium-serve.log 2>&1 & echo $! > ~/relayium-serve.pid

serve traite les connexions une par une et continue de tourner, il est donc prêt pour chaque reconnexion de la boucle de reprise ci-dessous.
Pour une boîte de réception toujours active, faites-le tourner plutôt sous systemd (Restart=always, --config-dir /etc/relayium).

Exécuter sync dans une boucle de reprise sous tmux (sur l'émetteur)

Les longs transferts sont interrompus — une session coupée, un réseau instable, un redémarrage. La solution n'est pas un outil sophistiqué ; c'est une boucle qui réexécute sync jusqu'à la réussite, plus un multiplexeur de terminal pour qu'il survive à votre déconnexion. Ici tmux est plus propre que nohup : pas de redirection de sortie à rater, et vous pouvez vous reconnecter pour voir la progression.

Démarrez une session tmux, puis exécutez le miroir dans une boucle until — elle réessaie toutes les 10 secondes jusqu'à ce que sync réussisse, puis se termine d'elle-même :

Ouvrez une session tmux sur l'émetteur, pour que la boucle survive à la session ssh depuis laquelle vous l'avez lancée.
```
# sur l'ÉMETTEUR
tmux new -s xfer      # apt install -y tmux s'il manque
```
Faites tourner le miroir dans une boucle until. Elle réessaie toutes les 10 secondes jusqu'à ce que sync réussisse, puis s'arrête d'elle-même.
```
until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done
```
Détachez-vous avec Ctrl-b puis d. La boucle continue ; reconnectez-vous quand vous voulez la regarder.
```
tmux attach -t xfer
```

À quoi ressemble un passage réussi

Chaque passage affiche une ligne par fichier réellement envoyé, puis un résumé opposant ce qu'il a envoyé à ce que le récepteur avait déjà. La boucle s'arrête au premier succès de sync, et ce résumé est l'état du miroir.

relayium sync /root/workspace relayium://203.0.113.43:9031
  workspace/data/part-004.bin (1073741824 bytes)
synced: 1 sent, 812 unchanged

Chaque tentative fait moins : les fichiers déjà transférés sont sautés, un fichier envoyé à moitié reprend — la boucle converge donc et se termine.
La progression affiche une ligne par fichier terminé, un gros fichier se transfère donc en silence jusqu'à sa fin. Le silence n'est pas un blocage (voir dépannage).

Vérifier et terminer

Le transfert est terminé quand la boucle until s'achève et que vous revenez à une invite shell normale. Confirmez que les deux côtés correspondent, puis arrêtez le processus à l'écoute :

Attendez que la boucle until s'achève d'elle-même. Retrouver une invite shell ordinaire signifie que le transfert est terminé, pas que vous l'avez interrompu.

Comparez les totaux sur les deux serveurs.

# comparez les totaux sur les DEUX serveurs
du -sh /root/workspace

Arrêtez le processus à l'écoute sur le récepteur une fois les totaux identiques. Le signal part vers le PID noté au lancement, et non vers toute commande relayium de la machine trouvée par correspondance de texte, et le fichier de PID n'est supprimé que si ce signal a réussi. Un fichier de PID laissé par une exécution précédente peut désigner un PID que le système a depuis réattribué, donc si vous n'êtes pas certain qu'il soit encore le vôtre, affichez d'abord la ligne de commande de ce PID et ne le tuez que si serve apparaît.
```
# sur le RÉCEPTEUR, une fois vérifié
ps -p "$(cat ~/relayium-serve.pid)" -o command=
kill "$(cat ~/relayium-serve.pid)" && rm ~/relayium-serve.pid
```

À quoi ressemble un miroir terminé

du -sh annonce le même total sur les deux serveurs, et la boucle until vous a rendu une invite de shell ordinaire au lieu de réessayer. Des totaux identiques sont un contrôle d'exhaustivité grossier, pas une preuve d'intégrité — sync a décidé sur la taille et le mtime quels fichiers ne pas envoyer, donc le total ne dit rien du contenu des fichiers ignorés.

# the same total, on BOTH servers
46G	/root/workspace

Ce que sync a envoyé est vérifié — chaque fichier transféré a été contrôlé en SHA-256 à l'arrivée, et une sortie propre signifie qu'aucun de ces contrôles n'a échoué. Ce qu'il a ignoré n'a été comparé que sur la taille et le mtime, donc des totaux du -sh identiques sont un contrôle de vraisemblance sur l'exhaustivité, pas une preuve que le contenu ignoré correspond toujours. Si vous avez besoin de cette preuve, comparez les sommes de contrôle fichier par fichier sur les deux serveurs.

Dépannage

Six choses reviennent sur un miroir de plusieurs heures. Trois ressemblent à des pannes sans en être, les trois autres en sont vraiment, et chacune a une commande qui dit laquelle vous avez sous les yeux.

Symptôme, vérification, correction

Rien ne s'affiche depuis longtemps et le transfert semble bloqué.

# sur l'ÉMETTEUR, deux fois, à quelques secondes d'intervalle
ss -tinp dst :9031
# ESTAB    le processus à l'écoute a été atteint, ce n'est pas une preuve que des octets circulent
# SYN-SENT n'atteint pas le processus à l'écoute

La progression ne s'affiche qu'à la fin de chaque fichier, un seul gros fichier se transfère donc dans un silence complet. ESTAB ne prouve que l'accessibilité — une socket établie peut rester inactive ou bloquée — et ne constitue jamais à elle seule une preuve d'avancement ; relancez la vérification à quelques secondes d'intervalle et comparez le compteur bytes_acked que -i affiche pour cette socket, un compteur qui monte est un transfert qui avance, un compteur figé est un vrai blocage.

La socket reste en SYN-SENT et le transfert ne démarre jamais.

# sur le RÉCEPTEUR
sudo ufw allow from 203.0.113.9 to any port 9031 proto tcp
ss -tlnp | grep 9031

Le port est bloqué. N'ouvrez 9031/TCP qu'à l'émetteur — remplacez 203.0.113.9 par l'adresse de l'émetteur lui-même, son IP publique ou son IP privée si les deux serveurs partagent un réseau — restreignez le groupe de sécurité cloud à cette même source, puis vérifiez que serve écoute vraiment. C'est la cause la plus fréquente d'un transfert qui ne commence jamais.

Coller la commande d'arrière-plan laisse le shell sur une invite de continuation >.

tmux new -s xfer
until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done

Une commande nohup multiligne avec des guillemets et une redirection > casse le plus souvent sur la redirection au moment du collage. Utilisez plutôt tmux et cette boucle d'une seule ligne : aucune redirection à rater, et vous pouvez vous reconnecter pour regarder.

Le nettoyage a tué quelque chose que vous ne visiez pas.

pgrep -af relayium
ps -p "$(cat ~/relayium-serve.pid)" -o command=
tmux kill-session -t xfer
kill "$(cat ~/relayium-serve.pid)" && rm ~/relayium-serve.pid

Tuer par motif de ligne de commande envoie le signal à tout processus dont la ligne de commande contient ce texte, sur une machine où tourne plus d'un transfert ce n'est donc pas celui que vous visiez. Et cela n'arrête pas la copie, la boucle until possède le sync et un enfant tué est simplement relancé dix secondes plus tard. Regardez avec pgrep -af, puis terminez ce que ce guide possède réellement : tmux kill-session -t xfer met fin à la boucle, et un kill sur le PID contenu dans ~/relayium-serve.pid arrête le processus à l'écoute que vous avez lancé. Si le fichier de PID traîne depuis une exécution précédente, affichez sa ligne de commande avant d'envoyer le signal, car un PID réattribué par le système appartient à tout autre chose.

Vous voulez laisser un sous-répertoire de côté et il n'y a aucune option d'exclusion.

relayium sync /root/workspace/src /root/workspace/data relayium://203.0.113.43:9031

sync accepte -i et -p, --delete, --watch et --config-dir — rien qui filtre un chemin au milieu de l'arborescence. Nommez plutôt les sous-répertoires que vous voulez : chaque source arrive sous le --dir du récepteur avec son propre nom, donc face à serve --dir /root/workspace cette commande reconstruit /root/workspace/src et /root/workspace/data sans jamais parcourir un venv régénérable.

Une source censée être mise en miroir arrive vide.

relayium sync ./links relayium://203.0.113.43:9031
# warning: no regular files to send (symlinks and special files are skipped)

sync ne transfère que des fichiers réguliers, et cet avertissement est exactement l'aspect d'une arborescence faite uniquement de liens symboliques. Pointez sync sur les répertoires que les liens désignent, et créez séparément sur le récepteur les liens dont vous avez besoin.

Questions fréquentes

Que se passe-t-il si le transfert est interrompu à mi-chemin ?

Rien n'est perdu. Relancez relayium sync — il saute les fichiers déjà sur le récepteur et reprend un fichier envoyé à moitié depuis l'offset d'octets déjà sur le disque. La boucle until de ce guide le fait automatiquement jusqu'à ce que tout le dossier soit recopié.

En quoi est-ce différent de rsync ?

Les deux font un miroir incrémental à sens unique, mais relayium sync tourne sur une connexion TLS avec épinglage sans compte SSH (daemon-direct), authentifie les deux machines par empreinte de certificat, et vérifie en SHA-256 chaque fichier qu'il transfère. Comme rsync par défaut, un fichier dont la taille et le mtime correspondent déjà côté récepteur est ignoré plutôt que rehaché. C'est le même moteur de transfert que les autres modes de relayium.

sync supprime-t-il sur le récepteur les fichiers que j'ai retirés de la source ?

Seulement si vous le demandez. Par défaut, sync ne fait qu'ajouter et mettre à jour. Passez --delete pour recopier les suppressions, et le récepteur doit exécuter serve avec --allow-delete pour que ce soit honoré — sinon la suppression est ignorée et signalée.

Puis-je garder deux dossiers synchronisés en continu ?

Oui. Ajoutez --watch et sync reste en marche, recopiant à chaque changement sous la source. Pour un déplacement ponctuel d'un gros dossier, inutile — la boucle de reprise plus un sync simple suffisent.

Dois-je ouvrir un port ?

Pour le daemon-direct, oui — le port du processus à l'écoute (9031 par défaut) doit être joignable depuis l'émetteur. Si vous préférez ne pas ouvrir de port et avez déjà SSH entre les serveurs, sync fonctionne aussi via SSH : relayium sync /path user@host:/path (relayium doit être installé côté distant).

Recopiez un dossier entre deux de vos propres serveurs — incrémental, avec reprise, sans surveillance.

Obtenir la CLI