Synology: Linux-Rechner per rsync und SSH ohne Passwort sichern (DSM 7)

Mit rsync über SSH sicherst Du Deinen Linux-Rechner auf ein Synology-NAS, ohne bei jedem Lauf das NAS-Passwort einzugeben. Ein SSH-Schlüssel übernimmt die Anmeldung, SSH verschlüsselt die Übertragung. Eine SMB- oder NFS-Freigabe musst Du dafür nicht einbinden. Nach der ersten Kopie überträgt rsync bei weiteren Läufen die Änderungen.

Der ursprüngliche Erfahrungsbericht entstand 2013 mit einer Synology DS212j. Damals lief die Anleitung direkt als root. Der folgende Ablauf richtet sich an DSM 7 und einen Linux-Client, etwa Ubuntu, Linux Mint oder Raspberry Pi OS. Er verwendet Dein eigenes DSM-Administratorkonto. Die alte Änderung an /etc/ssh/sshd_config mit RSAAuthentication entfällt.

Auf dem Synology-NAS vorbereiten: SSH, rsync und Benutzer-Home

Für die SSH-Anmeldung unterstützt DSM lokale Konten der Gruppe administrators. Das ist ein Konto mit weitreichenden Rechten, kein auf einen Backup-Ordner beschränktes Konto. Verwende den Zugang im eigenen Netz oder über ein VPN. Richte dann in DSM Folgendes ein:

1. SSH einschalten: Systemsteuerung → Terminal und SNMP → Terminal → SSH-Dienst aktivieren. Merke Dir den Port, normalerweise 22.
2. rsync einschalten: Systemsteuerung → Dateidienste → rsync → rsync-Dienst aktivieren. Prüfe unter Anwendungsberechtigungen die Freigabe für rsync.
3. Home aktivieren: Systemsteuerung → Benutzer und Gruppe → Erweitert → Benutzer-Home → Benutzer-Home-Dienst aktivieren. Belasse die Berechtigungen der übergeordneten Freigabe homes bei den Standardwerten.
4. Ziel anlegen: Erstelle einen freigegebenen Ordner, beispielsweise Backups, mit einem Unterordner notebook. Dein DSM-Konto benötigt dort Lese- und Schreibrechte.

Die Beispiele verwenden nasbackup als DSM-Benutzer, 192.168.100.10 als NAS-Adresse und /volume1/Backups/notebook/ als Ziel. Ersetze diese Werte durch Deine Angaben, auch die Volume-Nummer. bitblokes steht für Deinen lokalen Linux-Benutzer.

Hier kommt das DSM-Konto über SSH zum Einsatz. Die zusätzliche Option „rsync-Konto aktivieren“ betrifft separate Konten für unverschlüsselte rsync-Verbindungen. Verwechsle auch die Zielschreibweisen nicht: nas:/volume1/Backups/ bezeichnet einen Pfad über SSH, nas::NetBackup ein rsync-Modul. Unsere Übertragung läuft über den SSH-Port; Port 873 gehört zum direkten rsync-Daemon.

SSH-Schlüssel erzeugen und aufs NAS bringen

Auf dem Linux-Rechner brauchst Du rsync und den OpenSSH-Client. Unter Ubuntu, Debian, Mint und Raspberry Pi OS installierst Du sie bei Bedarf so:

sudo apt install rsync openssh-client
mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/nas-rsync
chmod 600 ~/.ssh/nas-rsync

Überschreibe keinen vorhandenen Schlüssel. Für die unten gezeigten unbeaufsichtigten Jobs ohne SSH-Agent lässt Du die Passphrase dieses separaten Schlüssels leer. Wer die private Datei besitzt, kann sie dann zur Anmeldung verwenden. Sie bleibt auf Deinem Rechner. Alternativ schützt Du sie mit einer Passphrase und entsperrst sie über ssh-agent; der geplante Job muss diesen Agenten ebenfalls erreichen können.

Den öffentlichen Schlüssel mit der Endung .pub überträgst Du mit ssh-copy-id. Der Tipp dazu kam seinerzeit von Leser Dakira:

ssh-copy-id -i ~/.ssh/nas-rsync.pub -p 22 [email protected]

Dabei gibst Du noch das DSM-Kennwort ein. Vergleiche beim ersten Kontakt den angezeigten Host-Schlüssel-Fingerabdruck mit einem bereits vertrauenswürdig bekannten Fingerabdruck des NAS, bevor Du ihn bestätigst. ssh-copy-id ergänzt ~/.ssh/authorized_keys auf dem NAS.

Die Rechte-Falle: Home, .ssh und authorized_keys

Kommt weiterhin eine Passwortabfrage, prüfe die Rechte. Melde Dich mit ssh -p 22 [email protected] und dem DSM-Kennwort an. Führe die folgenden Befehle auf dem NAS unter diesem Benutzer aus:

cd ~
pwd -P
mkdir -p .ssh
touch .ssh/authorized_keys
chmod 755 .
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
ls -ld . .ssh .ssh/authorized_keys

Verzeichnis und Schlüsseldatei müssen dem vorgesehenen Benutzer gehören. ~ führt zu dessen Home, typischerweise unter /var/services/homes/nasbackup beziehungsweise dem gewählten Volume. Ändere nur dieses Home, nicht rekursiv die gesamte Freigabe homes. Die früher genannte Berechtigung 644 für authorized_keys ist keine Pflicht: 600 genügt, solange Besitzer und Verzeichnisrechte stimmen.

Beende die NAS-Sitzung mit exit und prüfe vom Linux-Rechner aus den Schlüsselzugang. Bei abweichendem SSH-Port passt Du -p 22 in allen Beispielen an:

ssh -p 22 -i ~/.ssh/nas-rsync -o IdentitiesOnly=yes -o BatchMode=yes [email protected] 'id; command -v rsync'

BatchMode=yes unterbindet interaktive Rückfragen. Du solltest Benutzerinformationen und den Pfad zu rsync erhalten. Erst wenn dieser Test ohne Passwort funktioniert, folgt die Sicherung.

rsync testen: erst Probelauf, dann Sicherung

Starte auf dem Linux-Rechner mit --dry-run. Dieser Probelauf verändert keine Dateien im Sicherungsziel:

rsync -avz --no-owner --no-group --dry-run --itemize-changes \
  --exclude='/.cache/' --exclude='/.ssh/' --exclude='/nas-rsync.log' \
  -e 'ssh -p 22 -i /home/bitblokes/.ssh/nas-rsync -o IdentitiesOnly=yes -o BatchMode=yes' \
  /home/bitblokes/ [email protected]:/volume1/Backups/notebook/

Der Schrägstrich hinter /home/bitblokes/ bedeutet: Kopiere den Inhalt dieses Ordners. -a erhält unter anderem Zeitstempel und Berechtigungen. --no-owner --no-group nimmt Besitzer und Gruppe davon aus, weil ein DSM-Administratorkonto bei diesem Aufruf nicht als root arbeitet. Das Beispiel ist eine Dateisicherung, kein vollständiges Systemabbild. -z komprimiert die Übertragung.

Cache, SSH-Schlüssel und das spätere Log bleiben draußen. Sichere wichtige Schlüssel separat und verschlüsselt. Prüfe die Dateiliste und entferne für den echten Lauf nur --dry-run. Öffne anschließend einige gesicherte Dateien oder kopiere sie testweise in einen separaten lokalen Ordner zurück.

--delete ist optional und löscht im Ziel Dateien, die in der Quelle fehlen. Für eine exakte Spiegelung ergänzt Du es zunächst beim Probelauf und kontrollierst jede angekündigte Löschung. Eine Spiegelung bietet keine älteren Dateiversionen. Plane dafür zusätzlich Versionierung oder eine getrennte Sicherung ein. Für ein komplettes Raspberry-Pi-System passt die Anleitung zum Sichern und Klonen der SD-Karte.

Automatisieren mit Cron oder systemd-Timer

Lege auf dem Linux-Rechner mit mkdir -p ~/bin das Skriptverzeichnis an. Speichere dort als backup-nas.sh den folgenden Inhalt mit Deinen angepassten Werten:

#!/bin/sh
exec /usr/bin/rsync -avz --no-owner --no-group --itemize-changes \
  --exclude='/.cache/' --exclude='/.ssh/' --exclude='/nas-rsync.log' \
  -e '/usr/bin/ssh -p 22 -i /home/bitblokes/.ssh/nas-rsync -o IdentitiesOnly=yes -o BatchMode=yes' \
  /home/bitblokes/ [email protected]:/volume1/Backups/notebook/

Mache es mit chmod 700 ~/bin/backup-nas.sh ausführbar und teste ~/bin/backup-nas.sh einmal manuell. Richte danach eine der beiden Zeitsteuerungen ein.

Cron: alle zwei Stunden

Öffne als derselbe lokale Benutzer crontab -e und ergänze diese Zeile. Der Cron-Dienst muss installiert sein und laufen; flock verhindert überlappende Cron-Läufe:

0 */2 * * * /usr/bin/flock -n /home/bitblokes/.ssh/nas-rsync.lock /home/bitblokes/bin/backup-nas.sh >> /home/bitblokes/nas-rsync.log 2>&1

Das startet zu jeder geraden Stunde. Stündlich lautet der Zeitteil 0 * * * *, alle 30 Minuten */30 * * * *. Prüfe das Log regelmäßig und begrenze seine Größe. Ist der Rechner ausgeschaltet, holt dieser Cron-Eintrag den Lauf nicht nach.

systemd: verpassten Lauf nachholen

Erstelle alternativ mit mkdir -p ~/.config/systemd/user den Ordner für Benutzer-Units. Speichere darin nas-backup.service:

[Unit]
Description=Dateisicherung auf das Synology-NAS

[Service]
Type=oneshot
ExecStart=/home/bitblokes/bin/backup-nas.sh

Daneben liegt nas-backup.timer:

[Unit]
Description=NAS-Sicherung alle zwei Stunden

[Timer]
OnCalendar=*-*-* 00/2:00:00
Persistent=true

[Install]
WantedBy=timers.target

Aktivieren und Protokoll ansehen:

systemctl --user daemon-reload
systemctl --user enable --now nas-backup.timer
systemctl --user list-timers nas-backup.timer
journalctl --user -u nas-backup.service -n 50

Persistent=true holt beim erneuten Aktivieren einen während der Inaktivität verpassten Kalenderlauf nach. Der Benutzer-Dienstmanager startet üblicherweise mit Deiner Anmeldung. Ein gerade laufender Sicherungsdienst wird vom Timer nicht doppelt gestartet. Ein fehlgeschlagener Lauf wegen eines unerreichbaren NAS wird dadurch aber nicht sofort wiederholt.

Fehlersuche bei Passwortabfrage und rsync-Fehlern

• „Permission denied (publickey,password)“: Prüfe Benutzer, Gruppe administrators, Schlüsseldatei und Home-Rechte. Mit ssh -v zusätzlich zu den oben gezeigten SSH-Optionen siehst Du, welcher Schlüssel angeboten wird. Synologys eigene Schlüsselanleitung beschreibt RSA; lehnt Dein NAS Ed25519 ausdrücklich ab, prüfe dessen unterstützte Verfahren.
• „Connection refused“ oder Zeitüberschreitung: Prüfe NAS-Adresse, SSH-Port, Dienst und Firewall. Ist das NAS selbst nicht gestartet, hilft die Anleitung zur blau blinkenden Synology-Power-LED.
• SSH klappt, rsync scheitert: Prüfe rsync-Dienst, Anwendungsberechtigung, Zielpfad und Schreibrechte. Fehler zu Besitzern oder Gruppen sind etwas anderes als eine abgelehnte SSH-Anmeldung.
• Manuell klappt es, geplant nicht: Verwende denselben Linux-Benutzer und absolute Pfade. Kontrolliere Cron-Log beziehungsweise Journal. Ein Schlüssel mit Passphrase benötigt auch im geplanten Job einen erreichbaren, entsperrten Agenten.

Alternativen: Hyper Backup, Active Backup, Drive und rclone

Hyper Backup sichert Daten vom NAS auf weitere Ziele und eignet sich damit für eine zusätzliche Sicherung der hier abgelegten Kopie. Active Backup for Business bietet auf kompatiblen NAS und unterstützten Rechnern zentral verwaltete Systemsicherungen. Synology Drive Client ist eine Alternative für Ordnersynchronisation und PC-Backups mit grafischer Oberfläche.

Soll die zusätzliche Kopie in Nextcloud oder einen anderen Cloud-Speicher, schau Dir rclone für Cloud-Backups an. Für ausgewählte Linux-Dateien auf dem eigenen NAS bleibt rsync über SSH ein gut durchschaubarer Weg: Du bestimmst Quelle, Ziel und Zeitplan selbst.

Aktualisiert am 09.09.2026 von Henry. Fakten geprüft.