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

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

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 chaque fichier de bout en bout.

Ce guide met en place un transfert sans surveillance et auto-réparateur : autorisez l'émetteur une fois, faites tourner l'écouteur 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 chaque fichier : chaque fichier est contrôlé de bout en bout en SHA-256, donc un miroir terminé est connu comme intact.
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

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

# on BOTH servers
curl -fsSL https://relayium.com/install.sh | sh

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 de l'écouteur (9031 par défaut) à l'émetteur dans le pare-feu ou le groupe de sécurité du récepteur.

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 l'écouteur 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 :

# on the RECEIVER (foreground, to approve interactively)
relayium serve --dir /root --port 9031

# on the RECEIVER, at the first connection:
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 l'écouteur 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 :

# on the RECEIVER
nohup relayium serve --dir /root --port 9031 > ~/relayium-serve.log 2>&1 &

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 :

# on the SENDER
tmux new -s xfer      # apt install -y tmux if it's missing

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

Détachez avec Ctrl-b puis d ; la boucle continue de tourner après la fermeture du terminal. Reconnectez-vous avec tmux attach -t xfer.
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 l'écouteur :

# compare totals on BOTH servers
du -sh /root/workspace

# on the RECEIVER, once verified
pkill -f 'relayium serve'

Chaque fichier a été contrôlé en SHA-256 à l'arrivée, donc des tailles identiques plus une sortie propre signifient une copie intacte.

Dépannage

Quelques choses qui ressemblent à des problèmes mais n'en sont généralement pas — et celle qui en est généralement une (un port bloqué).

Aucune sortie n'est pas un blocage. La progression ne s'affiche que quand chaque fichier se termine, un gros fichier se transfère donc en silence. Vérifiez l'état réel sur l'émetteur avec ss -tnp | grep 9031 — ESTAB signifie connecté et en transfert ; SYN-SENT signifie qu'il ne peut pas joindre l'écouteur.
SYN-SENT signifie que le port est bloqué. Ouvrez 9031/TCP à l'émetteur sur le récepteur (groupe de sécurité cloud, ou ufw allow 9031/tcp). C'est la cause la plus fréquente d'un transfert qui ne démarre jamais.
Préférez tmux plus une boucle sur une seule ligne au nohup multi-lignes. Coller dans un shell une commande multi-lignes avec des guillemets et une redirection > casse souvent sur la redirection ou vous laisse à une invite de continuation >.
En nettoyant les processus, faites une correspondance précise (pkill -f 'relayium sync'), pas pkill relayium — une correspondance large peut tuer un processus relayium sans rapport tournant sur la même machine.
venv et autres répertoires régénérables valent la peine d'être exclus. Un environnement virtuel Python peut contenir des gigaoctets de bibliothèques que pip recrée de l'autre côté ; les sauter économise beaucoup de transfert.
Les liens symboliques et fichiers spéciaux sont sautés — sync ne transfère que des fichiers réguliers. Traitez séparément les liens symboliques importants.

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 épinglée sans compte SSH (daemon direct), authentifie les deux machines par empreinte de certificat, et vérifie chaque fichier en SHA-256. 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 de l'écouteur (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, reprenable, sans surveillance.

Obtenir la CLI