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

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 ./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

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:

1. 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

2. Finde heraus, welches Protokoll du bekommst. Ein Pfad heißt natives Protokoll — Kollisionsprüfung vorab und dateiweises SHA-256; keine Ausgabe heißt tar-Stream, der je Datei nichts prüft.

   ssh user@your-server command -v relayium

3. 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/

4. 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/

5. 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

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: Der ganze Stapel wird auf Kollisionen geprüft, bevor ein Byte fließt, und jede übertragene Datei wird per SHA-256 verifiziert und erst danach an ihren Platz gelegt.
• 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.

Integrität ist eingebaut — Fortsetzen nicht

Ist relayium auf beiden Seiten vorhanden, wird jede Datei, die push überträgt, Ende-zu-Ende mit einem SHA-256-Hash geprüft und erst nach der Prüfung an ihren Platz gelegt — was auf dem Server landet, entspricht Byte für Byte dem, was du gesendet hast. So weit ist das real, und es ist der Grund, relayium auf dem Ziel zu installieren.

Was push nicht tut, ist fortsetzen. Dateien werden einzeln installiert, sobald sie durch sind, sodass ein Abbruch mittendrin die bereits gelandeten Dateien liegen lässt — und weil sie nun existieren, wird derselbe push beim nächsten Versuch von der Kollisionsprüfung abgelehnt statt fortgesetzt. Push die fehlenden Pfade einzeln, oder nimm relayium sync: das ist der Modus, der überspringt, was schon passt, und eine Teildatei in einem späteren Lauf tatsächlich weiterführt.

--no-resume wird von push und pull zwar angenommen, tut dort aber nichts. Real ist es auf einem serve-Listener, der ein sync empfängt — dort kann überhaupt erst eine Teildatei liegen.

• Weder push noch pull setzt fort, in keinem der beiden Protokolle. Nimm sync für ein Verzeichnis, bei dem du mit Unterbrechungen rechnest. Der tar-Fallback setzt weder fort noch prüft er je Datei etwas.
• 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

Plane sync ein, nicht push. push verweigert ein Ziel, das schon existiert, also gelingt ein nächtlicher push in dasselbe Verzeichnis genau einmal und wird danach jede Nacht abgelehnt. sync ist der Modus für den wiederholten Lauf: Er überspringt Dateien, deren Größe und Änderungszeit gleich geblieben sind, sendet nur das Geänderte und führt eine Teildatei aus einem abgebrochenen Lauf weiter. Es ist ein einzelner, nicht-interaktiver Befehl, der deine SSH-Schlüssel nutzt, und passt damit direkt in cron. 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 sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

• Ein unterbrochenes nächtliches sync läuft in der folgenden Nacht einfach weiter: Was schon passt, wird übersprungen, und eine Teildatei wird fortgeführt statt neu begonnen.
• 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.