Dateien über SSH auf dem eigenen Server sichern mit der Relayium CLI

Zuletzt aktualisiert: 2026-08-05

Wenn du bereits SSH-Zugriff auf eine Maschine hast — einen VPS, einen Heimserver, ein NAS, eine Workstation —, kannst du Dateien mit der Relayium CLI dorthin sichern, ohne einen Sync-Dienst einzurichten oder ein Konto zu brauchen. Die Übertragung läuft über deine bestehende SSH-Verbindung, sodass die Bytes direkt zu deinem Server gehen und Relayium nie passieren.

Diese Anleitung behandelt das push und pull von Verzeichnissen, was Fortsetzen und Integritätsprüfung dir bringen, und wie du das Ganze mit cron nach Zeitplan laufen lässt.

Bevor du loslegst

Alles unten ist die relayium-CLI, installiere sie also zuerst, falls noch nicht geschehen. Unter macOS oder Linux legt ein Befehl ein vorgebautes Binary in deinen PATH:

curl -fsSL https://relayium.com/install.sh | sh

Willst du die Datei lieber selbst wählen, oder unter Windows? Hol dir ein Binary von der Releases-Seite — relayium.com/cli listet alle Installationswege (mit Go auch go build -o relayium ./cmd/relayium).
relayium --version bestätigt die Installation. Ohne das geben die Befehle unten nur „command not found“ aus.

Ein Verzeichnis auf deinen Server pushen

Was du brauchst

SSH-Zugang, den du ohnehin nutzt. ssh user@your-server true muss stumm zurückkehren — push verwendet genau diese Verbindung wieder und richtet nichts Eigenes ein.
Ein beschreibbares Ziel auf dem Server. Das übergeordnete Verzeichnis des Zielpfads muss existieren und für diesen SSH-Benutzer beschreibbar sein.
Optional relayium auf dem Server — das ist es, was Fortsetzen und dateiweises SHA-256 einbringt. Ohne läuft push trotzdem, über einen schlichten tar-Stream.
Kein Relayium-Konto und kein Daemon auf einer der beiden Seiten. Nichts davon spricht mit den Servern von Relayium.

push nimmt eine oder mehrere Quellen und ein Ziel im scp-Stil entgegen. Relayium verbindet sich per SSH mit deinen üblichen Schlüsseln und deiner Konfiguration und streamt die Dateien dann in das Zielverzeichnis:

Bestätige den SSH-Zugang, den push wiederverwendet. Kehrt er stumm zurück, stimmen Schlüssel, Host-Alias und Port bereits.
```
ssh user@your-server true
```
Finde heraus, welches Protokoll du bekommst. Ein Pfad heißt natives Protokoll — Fortsetzen und dateiweises SHA-256; keine Ausgabe heißt tar-Stream.
```
ssh user@your-server command -v relayium
```
Push das Verzeichnis. Das Ziel steht im scp-Stil, und der Schrägstrich am Ende heißt „in dieses Verzeichnis hinein“.
```
relayium push ./photos user@your-server:backups/
```
Gib Schlüssel oder Port nur für diesen einen Befehl an, falls deine ssh-Konfiguration den Host noch nicht abdeckt.
```
relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/
```
Prüf, was gelandet ist. push ./photos legt photos/ unter dem Ziel wieder an, der Ordnername kommt also mit.
```
ssh user@your-server ls backups/photos
```

So sieht ein erfolgreicher Lauf aus

Auf dem nativen Protokoll gibt push eine Zeile pro fertiger Datei aus und endet mit 0. Gegen einen nackten Server erscheint stattdessen eine einzelne Zusammenfassungszeile — das ist der tar-Weg, und auch das ist Erfolg.

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)

# against a server with no relayium installed, one summary line instead:
sent 2 file(s) (zero-dependency mode)

Es verwendet deine ~/.ssh/config wieder, sodass bereits eingerichtete Host-Aliase, Schlüssel und Ports einfach funktionieren.
Ist relayium auf dem Server installiert, nutzt es das native Protokoll: Fortsetzen je Datei und eine SHA-256-Prüfung für jede Datei.
Ist es das nicht, weicht es darauf aus, einen tar-Stream in die Gegenstelle zu pipen, sodass auch ein nackter Server ohne relayium funktioniert.

Dateien mit pull zurückholen

Das Wiederherstellen ist derselbe Befehl umgekehrt: Gib eine Remote-Quelle und ein lokales Zielverzeichnis an. So stellst du ein Backup wieder her oder synchronisierst die Ausgabe eines Servers auf deinen Laptop herunter:

relayium pull user@your-server:backups/ ./restore

Anders als push braucht pull immer bereits installiertes relayium auf der Gegenseite — es gibt keinen tar-Fallback, installiere es also dort zuerst, falls es fehlt.

Fortsetzen und Integrität sind eingebaut

Backups sind meist groß, und Netzwerke brechen gerne ab. Ist relayium auf beiden Seiten vorhanden, setzt eine unterbrochene Übertragung beim nächsten Lauf dort fort, wo sie aufgehört hat, statt alles neu zu senden, und jede Datei wird Ende-zu-Ende mit einem SHA-256-Hash geprüft — was auf dem Server landet, entspricht Byte für Byte dem, was du gesendet hast.

Willst du statt der Fortsetzung einer Teildatei einen sauberen, vollständigen Neuversand, übergib --no-resume.

Fortsetzen braucht relayium auf der Gegenseite (das native Protokoll); der tar-Fallback sendet immer vollständig.
Die SHA-256-Prüfung läuft automatisch; bei einer Abweichung wird das gemeldet und die Datei als fehlgeschlagen markiert.

Per cron nach Zeitplan ausführen

Da push ein einzelner, nicht-interaktiver Befehl ist, der deine SSH-Schlüssel nutzt, lässt es sich direkt in cron für ein wiederkehrendes Backup einsetzen. Verweise auf einen Schlüssel ohne Passphrase (oder einen Agent) und protokolliere die Ausgabe, damit du Fehlschläge siehst:

# jede Nacht um 2 Uhr sichern — in deine crontab eintragen (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

Zusammen mit dem Fortsetzen läuft ein unterbrochener nächtlicher Job in der folgenden Nacht einfach weiter.
Der Befehl endet mit einem Exit-Code ungleich null, wenn eine Datei ihre Integritätsprüfung nicht besteht, sodass crons Mail-bei-Fehlschlag das Problem auffängt.

Wenn ein Backup nicht ankommt

Ein geplantes Backup scheitert von Natur aus leise — niemand schaut aufs Terminal. Diese vier decken fast alles ab, und jedes wird von einem Befehl entschieden, den du sofort ausführen kannst.

Symptom, Prüfung, Lösung

Der cron-Job hängt, oder das Log endet an einer Passwortabfrage.

ssh -i ~/.ssh/backup_key -o BatchMode=yes user@your-server true
# Permission denied (publickey).

BatchMode=yes fragt nicht nach, sondern scheitert — aus dem stillen Hängen wird diese eine Zeile. Trag den öffentlichen Teil dieses Schlüssels in ~/.ssh/authorized_keys auf dem Server ein, oder gib dem Job einen Schlüssel, den ein Agent bereits hält.

Die crontab-Zeile läuft, aber das Log bleibt leer.

command -v relayium
# /usr/local/bin/relayium

cron läuft mit einem minimalen PATH, in dem /usr/local/bin meist fehlt, also scheitert die Zeile, bevor relayium überhaupt startet. Schreib den eben ausgegebenen absoluten Pfad in den crontab-Eintrag und behalte die Umleitung >> ~/relayium-backup.log 2>&1, damit der nächste Fehler sichtbar ist.

Eine abgebrochene Übertragung fängt beim nächsten Lauf wieder bei null an.

ssh user@your-server command -v relayium
# (gibt nichts aus)

Fortsetzen gehört zum nativen Protokoll, und kein relayium auf der Gegenseite heißt tar-Stream, der jede Datei immer vollständig überträgt. Installier es auf dem Server für dateiweises Fortsetzen — und prüf, dass du nicht --no-resume übergibst, das es absichtlich abschaltet.

„N file(s) failed integrity check“ und ein Exit-Code ungleich null.

relayium push ./photos user@your-server:backups/
# 1 file(s) failed integrity check: [photos/IMG_0413.jpg]
echo $?
# 1

Der beim Eintreffen berechnete SHA-256 stimmte nicht mit dem gesendeten überein, diese Datei ist auf dem Server also nicht vertrauenswürdig. Wiederhol den push und sieh dir den Exit-Code erneut an. Scheitert dieselbe Datei immer wieder, push sie einzeln, um eine kaputte Quelle von einer kaputten Leitung zu trennen.

Häufige Fragen

Laufen die Dateien über die Server von Relayium?

Nein. push und pull laufen vollständig über deine eigene SSH-Verbindung. Die Server von Relayium sind nie beteiligt, und du brauchst kein Konto.

Muss auf dem Server relayium installiert sein?

Das hängt von der Richtung ab. Bei push ist es optional: Mit relayium auf der Gegenseite bekommst du das native Protokoll — fortsetzbare Übertragungen und SHA-256-Prüfungen je Datei —, und ohne das weicht push auf einen tar-Stream über SSH aus, der weiterhin funktioniert, aber jede Datei stets vollständig sendet. Bei pull ist es erforderlich: pull braucht immer relayium auf der Gegenseite (keinen tar-Fallback), installiere es dort also zuerst.

Wie wählt es aus, welchen SSH-Schlüssel und welchen Port es nutzt?

Es liest deine ~/.ssh/config genau wie ssh, sodass Host-Aliase, Schlüssel und Ports automatisch übernommen werden. Du kannst sie auch pro Befehl überschreiben, mit -i für die Identitätsdatei und -p für den Port.

Ist das schneller als rsync?

Beim Push auf den eigenen Server liegt es in etwa auf dem Niveau von rsync über SSH; der Punkt ist nicht, rsync zu schlagen, sondern dir ein einziges Werkzeug zu geben, das mit denselben Fortsetzungs- und Integritätsgarantien auch netzwerkübergreifende und Server-zu-Server-Übertragungen erledigt.

Sichere dein nächstes Verzeichnis auf dem direkten Weg — über deine eigene SSH-Verbindung, fortsetzbar, mit Integritätsprüfung und kostenlos.

CLI holen