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

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 prüfen, was sie übertragen, im nativen Protokoll je Datei per SHA-256. Weder push noch pull setzt fort; von den dreien führt nur sync eine Teildatei weiter, und der tar-Fallback prüft und setzt gar nichts fort.

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.

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

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/$(date +\%F)/ >> ~/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

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

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

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

4. Erst danach den Zeitplan eintragen. Absoluten Pfad und Umleitung behalten.

   crontab -e

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

$ 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 unterbrochenes sync holt beim nächsten geplanten Lauf auf: Was schon passt, wird übersprungen, und eine Teildatei wird weitergeführt. Ein unterbrochenes push setzt nicht fort — aber weil jede Nacht in ihr eigenes datiertes Verzeichnis schreibt, ist die nächste Nacht eine saubere vollständige Kopie statt einer Ablehnung.

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.