Verschlüsselte Server-Backups mit einem Cron-Job automatisieren

Zuletzt aktualisiert: 2026-08-06

Backups, an die man selbst denken muss, passieren am Ende nicht. cron denkt daran, und die Relayium CLI ist genau dafür gebaut: ein einzelner, nicht-interaktiver Befehl, der ein Verzeichnis auf eine andere Maschine kopiert (oder spiegelt), jede Datei prüft und dort weitermacht, wo er aufgehört hat, falls das Netzwerk abbricht.

Diese Anleitung behandelt, wie du relayium push und das inkrementelle relayium sync per cron planst, welche zwei Übertragungswege beide nutzen können, und welche crontab-Zeilen du einfach übernehmen kannst.

push oder sync: vollständige Kopie oder inkrementelle Spiegelung

push und sync übertragen beide ein Verzeichnis auf eine andere Maschine, und beide lassen sich gefahrlos wiederholt ausführen, aber sie lösen leicht unterschiedliche Backup-Probleme.

push sendet bei jedem Lauf eine Kopie per SSH oder daemon-direct — einfach, und funktioniert dank Tar-Fallback sogar gegen einen nackten Server ohne installiertes relayium. sync dagegen hält das Ziel als inkrementellen, einseitigen Spiegel der Quelle: Nur geänderte Dateien werden erneut gesendet, sodass eine nächtliche Synchronisierung eines großen Verzeichnisses nach dem ersten Lauf schnell ist. sync benötigt auf beiden Seiten immer das native Protokoll von relayium — es gibt keinen Tar-Fallback.

Nutze push für eine unkomplizierte geplante Kopie, besonders auf einen Server, auf dem eventuell kein relayium installiert ist.
Nutze sync für ein großes oder häufig wechselndes Verzeichnis, bei dem jede Nacht alles neu zu senden Verschwendung wäre.
Beide werden je Datei per SHA-256 geprüft und lassen sich bei einer Unterbrechung fortsetzen.

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.

Zwei Übertragungswege: SSH oder daemon-direct

Richte beide Befehle entweder auf ein SSH-Ziel (im scp-Stil, unter Verwendung deiner ~/.ssh/config) oder, falls die andere Maschine relayium serve ausführt, direkt über das daemon-direct-Protokoll — ganz ohne SSH.

# SSH-Ziel — nutzt deine vorhandenen SSH-Schlüssel und deine Konfiguration
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct — auf dem Ziel läuft "relayium serve", kein SSH nötig
relayium push ./data relayium://backup-server:9031

daemon-direct-Verbindungen nutzen gepinntes TLS 1.3 mit Trust-on-first-use und werden danach bei jedem weiteren Lauf gegen genau diesen Fingerabdruck geprüft.
sync akzeptiert dieselben zwei Zielformen wie push.

Per cron planen

Was du vor Schritt 1 brauchst

Die CLI auf diesem Rechner — und auf dem Ziel ebenfalls, wenn du sync nutzen willst. sync hat keinen tar-Fallback.
Einen SSH-Schlüssel ohne Passphrase, oder ein Ziel, auf dem relayium serve läuft. cron hat weder Agent noch Terminal und kann eine Passphrase-Abfrage nicht beantworten.
Ein Quellverzeichnis, das in dem Moment existiert, in dem cron feuert — keins auf einem Netzlaufwerk, das nur eingehängt ist, solange du angemeldet bist.
Einen Ort für ein Log. Ein Cron-Job, dessen Ausgabe ins Nichts geht, ist ein Backup, von dem du erst erfährst, wenn du es brauchst.

push und sync sind beide einzelne, nicht-interaktive Befehle, die sich direkt in eine crontab einsetzen lassen. Verweise auf einen Schlüssel ohne Passphrase (oder einen Agent) und protokolliere die Ausgabe, damit Fehlschläge sichtbar werden:

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

# stattdessen alle 15 Minuten ein inkrementeller Spiegel
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

Finde heraus, wo relayium wirklich liegt. cron nutzt nicht den PATH deiner Shell, und install.sh weicht auf ~/.local/bin aus, wenn /usr/local/bin nicht beschreibbar ist — genau die Stelle, die cron nie sieht.
```
command -v relayium
```
Prüfe, ob der Schlüssel auch ohne jemanden an der Tastatur funktioniert. BatchMode=yes scheitert, statt zu fragen — genau die Lage von cron.
```
ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
```
Führ den ganzen Befehl einmal von Hand aus, exakt so geschrieben wie cron ihn ausführen wird, absoluter Pfad inklusive.
```
/usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/
```
Erst danach den Zeitplan eintragen. Absoluten Pfad und Umleitung behalten.
```
crontab -e
```
Nach dem ersten geplanten Lauf das Log lesen statt zu vermuten. Genau dieser Schritt wird übersprungen, und genau er hätte es gesagt.
```
tail -n 20 ~/relayium-backup.log
```

So sieht ein funktionierendes Setup aus

relayium löst sich zu einem absoluten Pfad auf, den du in die crontab kopieren kannst, und die ssh-Prüfung mit BatchMode endet mit 0, ohne etwas auszugeben oder zu fragen. Ein Backup, das nur aus deiner interaktiven Shell läuft, ist noch nicht geplant.

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ echo $?
0

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.
Ein unterbrochener Lauf setzt beim nächsten geplanten Lauf einfach fort oder holt auf.

Löschungen spiegeln und Echtzeit-Synchronisierung

Standardmäßig fügt sync am Ziel nur Dateien hinzu oder aktualisiert sie. Mit --delete wird daraus ein echter Spiegel, der auch Dateien entfernt, die es in der Quelle nicht mehr gibt — die Empfängerseite muss dafür ausdrücklich mit serve --allow-delete lauschen, sonst werden die Löschungen stillschweigend übersprungen und als abgelehnt zurückgemeldet. sync verweigert --delete außerdem grundsätzlich, wenn das Quellverzeichnis zu keiner einzigen Datei aufgelöst wird, sodass ein Tippfehler im Quellpfad das Ziel nicht leerräumen kann.

Wer nicht auf den nächsten cron-Zeitpunkt warten will, kann mit --watch relayium sync dauerhaft laufen lassen: Es synchronisiert automatisch kurz nachdem sich eine Datei unter der Quelle ändert — eine leichtgewichtige Alternative zum zeitgesteuerten Polling.

relayium sync ./data user@backup-server:/srv/backups/ --delete spiegelt auch Löschungen (Empfänger braucht serve --allow-delete).
relayium sync ./data user@backup-server:/srv/backups/ --watch bleibt laufen und synchronisiert bei jeder Änderung, statt einmalig per cron.

Wenn es nicht funktioniert

Jeder dieser Fälle ist unsichtbar, bis du ins Log schaust — deshalb steht die Umleitung in der crontab-Zeile und ist nicht optional. Der fünfte ist schlimmer als unsichtbar: er sieht wie Erfolg aus.

Symptom, Prüfung, Lösung

Im Log steht relayium: command not found, derselbe Befehl läuft in deiner Shell aber.

tail -n 5 ~/relayium-backup.log
# /bin/sh: relayium: command not found

cron läuft mit einem minimalen PATH, meist nur /usr/bin:/bin. Konnte install.sh nicht nach /usr/local/bin schreiben, liegt das Binary in ~/.local/bin, und dort sucht cron nie. Nimm den absoluten Pfad aus command -v in die crontab-Zeile, oder setz oben in der crontab eine PATH=-Zeile.

Das Log zeigt eine abgewiesene ssh-Verbindung, oder nach dem ersten Lauf gar nichts mehr.

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

cron hat keinen ssh-agent und kein Terminal, ein Schlüssel mit Passphrase kann also nur hängen oder scheitern. Zeig mit -i auf einen passphrasenlosen Schlüssel, der nur fürs Backup da ist, und prüfe mit BatchMode=yes — das verweigert die Abfrage, statt auf jemanden zu warten, der nicht da ist.

sync läuft sauber, aber an der Quelle gelöschte Dateien liegen am Ziel noch.

grep -i deni ~/relayium-sync.log

Löschen ist eine Opt-in-Entscheidung der Empfängerseite. Ohne serve --allow-delete drüben werden die Löschungen übersprungen und als denied zurückgemeldet — deshalb steht die Antwort im Log und nicht im Exit-Code. Starte den Listener der Gegenseite mit --allow-delete neu.

sync verweigert --delete rundheraus.

relayium sync ~/documents user@backup-server:/srv/backups/ --delete
# refusing --delete with an empty source: this would delete everything on the destination. Check the path(s).

Die Quelle löste sich zu null Dateien auf, der Spiegel hätte also das Ziel geleert. Diese Weigerung ist Absicht. Prüfe den Pfad auf einen Tippfehler — und prüfe, ob das, was dort eingehängt sein soll, auch zum Zeitpunkt des Cron-Laufs eingehängt ist und nicht nur, während du angemeldet bist.

Das Backup läuft, endet mit 0, und ist nicht das, wofür du es hältst.

ssh user@backup-server command -v relayium

Hat die Gegenstelle kein relayium, fällt push auf einen einfachen tar-Strom über SSH zurück. Die Dateien kommen an, also beschwert sich nichts — aber auf diesem Weg gibt es keine SHA-256-Prüfung pro Datei und kein Fortsetzen, und genau das sind die beiden Gründe, das hier statt scp einzuplanen. Installier die CLI auf dem Ziel, dann sind sie zurück. sync kennt diesen Fehler nicht: es hat gar keinen Fallback und scheitert stattdessen laut.

Häufige Fragen

Muss auf dem Backup-Server relayium installiert sein?

Das hängt vom Befehl ab. push funktioniert so oder so: Mit installiertem relayium nutzt es das native Protokoll (Fortsetzen + SHA-256 je Datei); ohne weicht push auf einen einfachen Tar-Stream über SSH aus, sodass auch ein nackter Server funktioniert. sync braucht auf der Gegenseite immer das native Protokoll von relayium — für sync gibt es keinen Tar-Fallback, installiere es also dort zuerst.

Ist das Backup verschlüsselt und geprüft?

Ja. Jede Datei wird Ende-zu-Ende mit einem SHA-256-Hash geprüft, und beim Push per SSH oder daemon-direct sind die Bytes bereits durch die Verschlüsselung dieser Verbindung geschützt — es ist nichts zusätzlich zu konfigurieren.

Was passiert, wenn der cron-Job mittendrin unterbrochen wird?

Mit relayium auf beiden Seiten setzt der nächste geplante Lauf Teildateien fort, statt alles neu zu senden. Übergib --no-resume, wenn du stattdessen einen sauberen, vollständigen Neuversand willst.

Kann --delete versehentlich mein Ziel leeren?

sync verweigert die Ausführung mit --delete, wenn das Quellverzeichnis keine Dateien enthält, und die Empfängerseite muss mit serve --allow-delete gestartet sein, damit Löschungen überhaupt wirksam werden — sonst werden sie übersprungen und dir gemeldet.

Brauche ich ein Konto oder kostet das etwas?

Nein. Die CLI ist kostenlos und braucht für push, pull oder sync kein Konto — die Übertragung läuft über deine eigene SSH-Verbindung oder eine direkte daemon-Verbindung, nicht über die Server von Relayium.

Bring deine Backups auf einen Zeitplan, an den du nicht denken musst — verschlüsselt, fortsetzbar und kostenlos.

CLI holen