Einen großen Ordner zwischen zwei Servern synchronisieren (fortsetzbar, im Hintergrund)

Zuletzt aktualisiert: 2026-08-05

Du hast einen großen Ordner — zig Gigabyte — auf einem Server und willst eine exakte Kopie auf einem anderen. Du kannst kein Terminal stundenlang bewachen, und eine Übertragung, die auf halbem Weg abbricht, sollte nicht bei null neu beginnen. relayium sync ist genau dafür gebaut: ein einseitiger inkrementeller Spiegel, der überspringt, was schon da ist, eine halb gesendete Datei dort fortsetzt, wo sie stehen blieb, und jede Datei, die er sendet, Ende-zu-Ende prüft.

Diese Anleitung richtet eine unbeaufsichtigte, selbstheilende Übertragung ein: genehmige den Sender einmal, betreibe den Listener im Hintergrund und treibe relayium sync aus einer Retry-Schleife in tmux an, sodass es über Verbindungsabbrüche hinweg weiterläuft, bis der ganze Ordner angekommen ist.

Warum relayium sync für diese Aufgabe passt

sync ist ein einseitiger inkrementeller Spiegel über das native Protokoll (installiere relayium an beiden Enden). Drei Eigenschaften machen es sicher, es unbeaufsichtigt auszuführen und erneut auszuführen:

Überspringt bereits vorhandene Dateien: Eine Datei, deren Kopie auf dem Empfänger in Größe und Änderungszeit übereinstimmt, wird nicht erneut gesendet.
Setzt Teildateien fort: War eine Datei beim Verbindungsabbruch halb übertragen, setzt der nächste Lauf beim bereits auf der Platte liegenden Byte-Offset fort, statt neu zu beginnen.
Prüft, was er sendet: Jede übertragene Datei — auch eine fortgesetzte — wird Ende-zu-Ende gegen die SHA-256 des Senders geprüft, und eine Abweichung wird als Fehler gemeldet. Übersprungene Dateien werden allein über Größe und mtime entschieden und nicht neu gehasht; über Inhalte, die er nicht gesendet hat, sagt sync nichts aus.
Deshalb ist der Befehl idempotent — ein erneuter Lauf erledigt nur die verbleibende Arbeit, und genau das lässt eine Retry-Schleife eine riesige Übertragung abschließen.

Voraussetzungen

Was du brauchst

Diese Anleitung nutzt daemon-direct (relayium://), die beiden Server brauchen also keinen SSH-Zugang zueinander.
Öffne den Port des Listeners (Standard 9031) für den Sender in Firewall oder Security-Group des Empfängers.
Platz für den ganzen Ordner auf dem Empfänger. Vergleich du -sh /root/workspace auf dem Sender mit df -h /root auf dem Empfänger, bevor du eine mehrstündige Übertragung startest.

Installiere relayium auf beiden Servern (sync spricht das native Protokoll, muss also an jedem Ende vorhanden sein):

# auf BEIDEN Servern
curl -fsSL https://relayium.com/install.sh | sh

Den Sender einmal genehmigen (auf dem Empfänger)

Der Empfänger genehmigt die sendende Maschine einmal; die Genehmigung wird auf die Platte geschrieben und bleibt über Neustarts hinweg gültig, du wiederholst sie also nie. Starte den Listener zuerst in einem Terminal und richte --dir auf das übergeordnete Verzeichnis — relayium sync /root/workspace reproduziert workspace/... auf dem Empfänger, sodass --dir /root die Dateien in /root/workspace/ landen lässt.

Bei der ersten Verbindung des Senders (nächster Abschnitt) zeigt serve dessen Adresse und Fingerprint und bittet dich um Genehmigung; antworte mit y, und er wird dauerhaft gespeichert:

# auf dem EMPFÄNGER (im Vordergrund, zum interaktiven Genehmigen)
relayium serve --dir /root --port 9031

# auf dem EMPFÄNGER, bei der ersten Verbindung:
Incoming push from 203.0.113.9:52140
  fingerprint: 9f2c41ab…
Accept and remember this peer? [y/N] y

Für ein vollständig unbeaufsichtigtes Setup überspringst du die Abfrage: Führe relayium id auf dem Sender aus, um seinen Fingerprint auszugeben, dann relayium authorize <Fingerprint> auf dem Empfänger.
--dir ist das übergeordnete Verzeichnis des zu synchronisierenden Ordners, nicht der Ordner selbst — sonst landen die Dateien eine Ebene zu tief (z. B. /root/workspace/workspace).

Den Listener im Hintergrund betreiben (auf dem Empfänger)

Ist der Fingerprint genehmigt, beende das serve im Vordergrund (Ctrl-C) und starte es abgekoppelt neu, damit es dein Ausloggen übersteht. Es lädt den gespeicherten Fingerprint und akzeptiert den Sender stillschweigend — diesmal ohne Abfrage. Dieselbe Zeile schreibt die PID des neuen Prozesses nach ~/relayium-serve.pid, und damit beendet der letzte Schritt dieser Anleitung den Listener, den er selbst gestartet hat, statt jeden relayium-Befehl auf der Maschine:

# auf dem EMPFÄNGER
nohup relayium serve --dir /root --port 9031 > ~/relayium-serve.log 2>&1 & echo $! > ~/relayium-serve.pid

serve verarbeitet Verbindungen nacheinander und läuft weiter, ist also für jede erneute Verbindung der Retry-Schleife unten bereit.
Für einen dauerhaft laufenden Posteingang betreibe es stattdessen unter systemd (Restart=always, --config-dir /etc/relayium).

sync in einer Retry-Schleife unter tmux ausführen (auf dem Sender)

Lange Übertragungen werden unterbrochen — eine abgebrochene Sitzung, ein wackeliges Netz, ein Neustart. Die Lösung ist kein raffiniertes Werkzeug, sondern eine Schleife, die sync erneut ausführt, bis es gelingt, plus ein Terminal-Multiplexer, damit es dein Ausloggen übersteht. tmux ist hier sauberer als nohup: keine Ausgabe-Umleitung, die man falsch machen kann, und du kannst dich wieder verbinden, um den Fortschritt zu sehen.

Starte eine tmux-Sitzung und führe den Spiegel in einer until-Schleife aus — sie versucht es alle 10 Sekunden erneut, bis sync Erfolg meldet, und beendet sich dann von selbst:

Starte auf dem Sender eine tmux-Sitzung, damit die Schleife die ssh-Sitzung überlebt, aus der du sie gestartet hast.
```
# auf dem SENDER
tmux new -s xfer      # apt install -y tmux, falls es fehlt
```
Lass den Spiegel in einer until-Schleife laufen. Sie versucht es alle 10 Sekunden erneut, bis sync Erfolg meldet, und beendet sich dann von selbst.
```
until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done
```
Koppel mit Ctrl-b, dann d ab. Die Schleife läuft weiter; verbinde dich wieder, wann immer du zusehen willst.
```
tmux attach -t xfer
```

So sieht ein erfolgreicher Durchlauf aus

Jeder Durchlauf gibt eine Zeile pro tatsächlich gesendeter Datei aus, dann eine Zusammenfassung, die Gesendetes gegen das stellt, was der Empfänger schon hatte. Die Schleife endet, sobald sync das erste Mal Erfolg meldet, und diese Zusammenfassung ist der Stand des Spiegels.

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

Jeder Versuch tut weniger: bereits übertragene Dateien werden übersprungen, eine halb gesendete Datei wird fortgesetzt — so konvergiert die Schleife und ist fertig.
Der Fortschritt gibt pro fertiger Datei eine Zeile aus, eine große Datei überträgt also still, bis sie fertig ist. Stille ist kein Stillstand (siehe Fehlerbehebung).

Prüfen und abschließen

Die Übertragung ist abgeschlossen, wenn die until-Schleife endet und du wieder an einer normalen Shell-Eingabe bist. Prüfe, dass beide Seiten übereinstimmen, und stoppe dann den Listener:

Warte, bis die until-Schleife von allein endet. Wieder an einer gewöhnlichen Shell-Eingabe zu sein heißt, dass die Übertragung fertig ist, nicht dass du sie abgebrochen hast.

Vergleich die Gesamtgrößen auf beiden Servern.

# Gesamtgrößen auf BEIDEN Servern vergleichen
du -sh /root/workspace

Stopp den Listener auf dem Empfänger, sobald die Größen übereinstimmen. Das Signal geht an die PID, die du beim Start notiert hast, statt per Textsuche an jeden relayium-Befehl auf der Maschine, und die PID-Datei verschwindet nur, wenn das Signal geglückt ist. Eine PID-Datei aus einem früheren Lauf kann eine PID nennen, die das System längst neu vergeben hat — bist du dir also nicht sicher, dass die Datei noch deine ist, lass dir erst die Kommandozeile dieser PID ausgeben und töte sie nur, wenn serve zurückkommt.
```
# auf dem EMPFÄNGER, sobald geprüft
ps -p "$(cat ~/relayium-serve.pid)" -o command=
kill "$(cat ~/relayium-serve.pid)" && rm ~/relayium-serve.pid
```

So sieht ein fertiger Spiegel aus

du -sh meldet auf beiden Servern dieselbe Gesamtgröße, und die until-Schleife hat dich an einen gewöhnlichen Shell-Prompt zurückgegeben, statt erneut zu versuchen. Gleiche Summen sind eine grobe Vollständigkeitsprobe und kein Integritätsbeweis: sync hat über Größe und mtime entschieden, welche Dateien gar nicht erst gehen, also sagt die Summe nichts über den Inhalt der übersprungenen Dateien.

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

Was sync gesendet hat, ist geprüft: Jede übertragene Datei wurde beim Eintreffen mit SHA-256 kontrolliert, und ein sauberes Ende heißt, dass keine dieser Prüfungen fehlgeschlagen ist. Was übersprungen wurde, wurde nur über Größe und mtime abgeglichen; gleiche du -sh-Summen sind deshalb eine Plausibilitätsprobe auf Vollständigkeit und kein Beweis, dass die übersprungenen Inhalte noch übereinstimmen. Brauchst du diesen Beweis, vergleiche Prüfsummen pro Datei auf beiden Servern.

Fehlerbehebung

Bei einem mehrstündigen Spiegel kommen sechs Dinge vor. Drei davon sehen wie Fehler aus und sind keine, die anderen drei sind echt — und zu jedem gibt es einen Befehl, der sagt, welches du gerade vor dir hast.

Symptom, Prüfung, Lösung

Lange Zeit erscheint nichts, und die Übertragung sieht aus, als stünde sie.

# auf dem SENDER, zweimal im Abstand einiger Sekunden
ss -tinp dst :9031
# ESTAB    der Listener wurde erreicht; kein Beleg dafür, dass Bytes fließen
# SYN-SENT erreicht den Listener nicht

Der Fortschritt erscheint nur, wenn eine Datei fertig ist, eine einzelne große Datei überträgt also völlig still. ESTAB belegt nur die Erreichbarkeit — ein aufgebauter Socket kann untätig sein oder hängen — und ist für sich genommen nie ein Beleg für Fortschritt. Führ die Prüfung zweimal im Abstand einiger Sekunden aus und vergleich den bytes_acked-Zähler, den -i für diesen Socket ausgibt: ein steigender Wert ist eine laufende Übertragung, ein unveränderter ein echter Stillstand.

Der Socket bleibt in SYN-SENT, und die Übertragung beginnt gar nicht erst.

# auf dem EMPFÄNGER
sudo ufw allow from 203.0.113.9 to any port 9031 proto tcp
ss -tlnp | grep 9031

Der Port ist blockiert. Öffne 9031/TCP nur für den Sender — ersetz 203.0.113.9 durch die Adresse des Senders selbst, seine öffentliche IP oder seine private, wenn beide Server im selben Netz hängen — grenz die Cloud-Sicherheitsgruppe auf dieselbe Quelle ein und prüf dann, ob serve wirklich lauscht. Das ist die häufigste Ursache für eine Übertragung, die nie anfängt.

Nach dem Einfügen des Hintergrundbefehls hängt die Shell an einem >-Fortsetzungsprompt.

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

Ein mehrzeiliger nohup-Befehl mit Anführungszeichen und einer >-Umleitung bricht beim Einfügen meist an der Umleitung. Nimm stattdessen tmux und diese einzeilige Schleife: Es gibt keine Umleitung, die schiefgehen kann, und du kannst dich wieder verbinden und zusehen.

Beim Aufräumen ist etwas gestorben, das du nicht treffen wolltest.

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

Über ein Kommandozeilen-Muster zu töten schickt das Signal an jeden Prozess, dessen Kommandozeile diesen Text enthält — auf einer Maschine mit mehr als einer Übertragung also nicht an den gemeinten. Es stoppt den Spiegel auch nicht: die until-Schleife besitzt das sync, ein getötetes Kind wird zehn Sekunden später einfach neu gestartet. Sieh mit pgrep -af nach und beende dann, was diese Anleitung wirklich besitzt — tmux kill-session -t xfer beendet die Schleife, und ein kill auf die PID in ~/relayium-serve.pid beendet den Listener, den du gestartet hast. Liegt die PID-Datei noch von einem früheren Lauf herum, lass dir vor dem Signal ihre Kommandozeile ausgeben: eine vom System neu vergebene PID gehört zu etwas ganz anderem.

Du willst ein Unterverzeichnis auslassen, und es gibt keine exclude-Option.

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

sync nimmt -i und -p, --delete, --watch und --config-dir — nichts, was mitten im Baum einen Pfad herausfiltert. Nenn stattdessen die Unterverzeichnisse, die du willst: Jede Quelle landet unter dem --dir des Empfängers unter ihrem eigenen Namen, gegen serve --dir /root/workspace entstehen so wieder /root/workspace/src und /root/workspace/data, und ein neu erzeugbares venv wird nie durchlaufen.

Eine Quelle, die gespiegelt werden sollte, kommt leer an.

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

sync überträgt nur reguläre Dateien, und genau so sieht ein Baum aus, der nur aus Symlinks besteht. Richte sync auf die Verzeichnisse, auf die die Links zeigen, und leg die benötigten Symlinks auf dem Empfänger getrennt an.

Häufige Fragen

Was passiert, wenn die Übertragung auf halbem Weg unterbrochen wird?

Nichts geht verloren. Führe relayium sync erneut aus — es überspringt bereits auf dem Empfänger vorhandene Dateien und setzt eine halb gesendete Datei beim bereits auf der Platte liegenden Byte-Offset fort. Die until-Schleife in dieser Anleitung tut das automatisch, bis der ganze Ordner gespiegelt ist.

Wie unterscheidet sich das von rsync?

Beide machen inkrementelles einseitiges Spiegeln, aber relayium sync läuft über eine TLS-Verbindung mit Pinning ohne SSH-Konto (daemon-direct), authentifiziert die beiden Maschinen per Zertifikats-Fingerprint und prüft jede übertragene Datei mit SHA-256. Wie bei rsync in der Voreinstellung wird eine Datei, deren Größe und mtime auf dem Empfänger schon übereinstimmen, übersprungen statt neu gehasht. Es ist dieselbe Übertragungs-Engine wie die anderen Modi von relayium.

Löscht sync auf dem Empfänger Dateien, die ich aus der Quelle entfernt habe?

Nur wenn du es verlangst. Standardmäßig fügt sync nur hinzu und aktualisiert. Übergib --delete, um Löschungen zu spiegeln, und der Empfänger muss serve mit --allow-delete betreiben, damit es befolgt wird — sonst wird die Löschung ignoriert und zurückgemeldet.

Kann ich zwei Ordner dauerhaft synchron halten?

Ja. Füge --watch hinzu, und sync läuft weiter und spiegelt bei jeder Änderung unter der Quelle neu. Für ein einmaliges Verschieben eines großen Ordners brauchst du es nicht — die Retry-Schleife plus ein schlichtes sync genügen.

Muss ich einen Port öffnen?

Für daemon-direct ja — der Port des Listeners (Standard 9031) muss vom Sender erreichbar sein. Willst du keinen Port öffnen und hast bereits SSH zwischen den Servern, funktioniert sync auch über SSH: relayium sync /path user@host:/path (relayium muss auf der Gegenseite installiert sein).

Spiegle einen Ordner zwischen zwei eigenen Servern — inkrementell, fortsetzbar, ohne Bewachen.

CLI holen