Diese Anleitung zeigt dir, wie du rsync über SSH auf Debian 12 und Ubuntu 24.04 LTS zum effizienten Synchronisieren und Migrieren von Daten einsetzt. Du lernst die Grundsyntax und die wichtigsten Optionen, den verschlüsselten Transfer per SSH-Key statt Passwort, die berüchtigte Trailing-Slash-Falle, das saubere Spiegeln mit --delete, eine komplette Server-Migration mit --numeric-ids sowie geplante Syncs per Cron. rsync überträgt dabei nur die Unterschiede (Delta-Algorithmus) und ist deshalb auch bei großen Datenmengen schnell.

Kurzfassung: Das Standardkommando lautet rsync -avzhP -e ssh QUELLE user@host:/ZIEL. -a erhält Rechte, Zeiten und Symlinks, -z komprimiert (nur im langsamen WAN sinnvoll), -P zeigt Fortschritt und nimmt Abbrüche wieder auf. Achte penibel auf den abschließenden Slash an der Quelle: quelle/ kopiert den Inhalt, quelle kopiert das Verzeichnis selbst. Vor jedem --delete zwingend --dry-run. Für die Server-Migration als root rsync -aHAXvz --numeric-ids -e ssh /srv/ root@neuserver:/srv/. Geplante Läufe per Cron mit absolutem Pfad /usr/bin/rsync und passphrase-losem SSH-Key.

Voraussetzungen

Zwei Linux-Systeme mit Debian 12 oder Ubuntu 24.04 LTS (Quelle und Ziel). Lokale Sync-Szenarien funktionieren auch auf einem einzelnen Host.
SSH-Zugang zum Zielserver, idealerweise mit SSH-Key statt Passwort (für unbeaufsichtigte und geplante Läufe Pflicht).
rsync auf beiden Seiten installiert - die Versionen sollten halbwegs zusammenpassen.
Für Server-Migration mit Owner-/Rechte-Erhalt: root-Zugriff auf beiden Seiten (rsync muss als root laufen, sonst gehören alle Dateien dem ausführenden Benutzer).

Falls rsync fehlt, installierst du es so:

sudo apt update
sudo apt install rsync

Schritt 1: Grundsyntax und die wichtigsten Optionen

Der Aufbau ist immer gleich: rsync [OPTIONEN] QUELLE ZIEL. Quelle und Ziel können beide lokal sein oder per user@host:/pfad remote. Die mit Abstand wichtigste Option ist -a (Archive-Modus). Sie ist exakt äquivalent zu -rlptgoD, also rekursiv, Symlinks, Permissions, Times, Group, Owner sowie Devices/Specials.

Wichtig zu wissen: -a enthält laut offizieller man page nicht ACLs (-A), erweiterte Attribute/xattrs (-X) und Hardlinks (-H). Die brauchst du erst bei der Migration in Schritt 6.

OptionBedeutung

-a

Archive-Modus = -rlptgoD (rekursiv, Rechte, Zeiten, Owner, Group, Symlinks)

-v

verbose, mehr Ausgabe; mehrfach (-vv) noch mehr

-z

komprimiert die Übertragung (nur im langsamen WAN sinnvoll)

-h

human-readable Zahlen (KB, MB, GB statt Bytes)

-P

= --partial --progress: Fortschrittsanzeige und Wiederaufnahme abgebrochener Transfers

-n / --dry-run

Probelauf ohne jede Änderung

--delete

löscht am Ziel, was an der Quelle fehlt (echtes Mirror)

--exclude

schließt Muster aus (z. B. --exclude=cache/)

Ein typischer lokaler Aufruf, der ein Verzeichnis sauber spiegelt, sieht so aus - erst der Probelauf:

# Probelauf: zeigt nur an, was passieren WUERDE
rsync -avh --dry-run --delete /pfad/src/ /pfad/dst/

# Wenn die Ausgabe stimmt: scharf schalten
rsync -avh --delete /pfad/src/ /pfad/dst/

Schritt 2: Die Trailing-Slash-Falle verstehen

Das ist der Fehler, der die meisten rsync-Einsteiger erwischt. Entscheidend ist der abschließende Slash an der Quelle:

Mit Slash (/pfad/src/) kopiert rsync nur den Inhalt des Verzeichnisses ins Ziel.
Ohne Slash (/pfad/src) kopiert rsync das Verzeichnis selbst als Unterordner ins Ziel.
Am Ziel ist ein abschließender Slash dagegen bedeutungslos.

# MIT Slash: Inhalt von src landet direkt in dst  ->  /pfad/dst/datei.txt
rsync -avh /pfad/src/ /pfad/dst/

# OHNE Slash: src wird zum Unterordner          ->  /pfad/dst/src/datei.txt
rsync -avh /pfad/src  /pfad/dst/

Merksatz: quelle/ bedeutet „nimm, was drin ist“, quelle bedeutet „nimm den Ordner mit“. Wer das verwechselt, bekommt entweder verschachtelte Verzeichnisse (/dst/src/src/...) oder löscht beim Mirror die falschen Daten. Genau dieses Verhalten nutzt du in Schritt 5 gezielt aus.

Schritt 3: SSH-Key einrichten und ersten Transfer über SSH starten

SSH ist heute der Default-Transport von rsync. Ein explizites -e ssh ist meist optional, zur Klarheit und Dokumentation aber üblich. Für unbeaufsichtigte Läufe nutzt du einen SSH-Key statt Passwort. Erzeuge und verteile ihn so:

# Schluesselpaar erzeugen (moderner Ed25519-Algorithmus)
ssh-keygen -t ed25519 -C rsync-backup

# Oeffentlichen Schluessel auf den Zielserver bringen
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

Die Remote-Pfad-Syntax lautet user@host:/pfad. So überträgst du ein Verzeichnis mit Fortschritt und Kompression auf den Server (Upload) bzw. holst es zurück (Download):

# Upload: lokal  ->  remote (mit Fortschritt und Kompression)
rsync -avzhP -e ssh /var/www/ user@host:/var/www/

# Download: remote  ->  lokal
rsync -avzhP -e ssh user@host:/var/www/ /var/www/

Läuft SSH auf einem anderen Port oder soll ein bestimmter Key verwendet werden, packst du diese Angaben in das -e-Argument. Setze es dann in doppelte Anführungszeichen, damit die Shell den Port-Parameter korrekt zuordnet:

# Nicht-Standard-Port 2222 und expliziter Key
rsync -avzhP -e "ssh -i /home/user/.ssh/id_ed25519 -p 2222" /pfad/src/ user@host:/pfad/dst/

Die Einrichtung der Keys vertieft die verlinkte SSH-Anleitung am Ende dieses Artikels.

Schritt 4: Backup-Szenario mit Ausschlüssen

Für ein Backup willst du nicht alles mitnehmen - Caches, .git-Verzeichnisse oder temporäre Dateien sind unnötiger Ballast. Mit mehreren --exclude-Mustern blendest du sie aus:

# Backup eines Web-Verzeichnisses ohne Cache, .git und tmp
rsync -avzhP --exclude=cache/ --exclude=.git/ --exclude=tmp/ /pfad/src/ user@host:/pfad/dst/

Willst du das Quellverzeichnis bewusst als eigenen Unterordner im Backup ablegen (siehe Trailing-Slash-Regel), lässt du den Slash an der Quelle weg. Das folgende Kommando erzeugt am Ziel /backup/projekt:

# Verzeichnis selbst mitkopieren  ->  erzeugt /backup/projekt auf dem Ziel
rsync -avh /home/user/projekt user@host:/backup/

Ein Hinweis zur Kompression: -z lohnt sich nur in langsamen WAN-Verbindungen. In schnellen LANs oder bei bereits komprimierten Daten (Bilder, Videos, Archive) erzeugt die Kompression nur CPU-Overhead und bremst eher. Dort lässt du -z weg.

Schritt 5: Echtes Mirror mit --delete (erst Probelauf!)

Ein normaler rsync-Lauf fügt am Ziel nur hinzu und aktualisiert. Soll das Ziel ein exaktes Spiegelbild der Quelle werden, brauchst du --delete: Dateien, die an der Quelle fehlen, werden am Ziel gelöscht. Das ist mächtig - und gefährlich, wenn die Quelle versehentlich leer oder falsch gemountet ist.

Deshalb gilt die eiserne Regel: Vor jedem --delete ein --dry-run.

# 1. Probelauf: zeigt jede geplante Aenderung und Loeschung
rsync -avh --dry-run --delete /pfad/src/ user@host:/pfad/dst/

# 2. Ausgabe pruefen - stimmen Quelle und geplante Loeschungen?

# 3. Erst dann scharf schalten
rsync -avh --delete /pfad/src/ user@host:/pfad/dst/

Lies die Dry-Run-Ausgabe wirklich, bevor du den scharfen Lauf startest. Tauchen dort unerwartet viele deleting ...-Zeilen auf, hast du vermutlich die falsche Quelle, den falschen Slash oder ein nicht gemountetes Quellverzeichnis erwischt.

Schritt 6: Server-Migration als root mit voller Attributerhaltung

Beim Umzug eines ganzen Servers oder Verzeichnisbaums reicht -a nicht aus. Du willst zusätzlich ACLs, erweiterte Attribute und Hardlinks mitnehmen - und die rohen numerischen IDs erhalten. Das leistet diese Kombination, ausgeführt als root auf beiden Seiten:

# Vollstaendige Migration: ACLs (-A), xattrs (-X), Hardlinks (-H), numerische IDs
sudo rsync -aHAXvz --numeric-ids --delete -e ssh /srv/ root@neuserver:/srv/

Zwei Punkte sind hier entscheidend:

root auf beiden Seiten: Rechte und Owner bleiben nur erhalten, wenn rsync auf beiden Seiten als root läuft. Als unprivilegierter Benutzer gehören am Ziel alle Dateien dem ausführenden User, und -o/-g (Owner/Group setzen) erfordern root am Ziel.
--numeric-ids: Diese Option überträgt die rohen numerischen uid und gid, statt sie über Namen aufzulösen (man page: do not map uid/gid values by user/group name). Das ist essenziell, wenn am Zielserver Benutzer oder Gruppen fehlen oder abweichende IDs haben - sonst landet die Datei beim falschen oder einem zufälligen Konto.

Plane bei einer Migration zwei Läufe ein: einen ersten großen Lauf bei laufendem Betrieb und einen kurzen Abgleich nach dem Stoppen der Dienste, der nur noch die letzten Deltas überträgt.

Schritt 7: Geplante Syncs per Cron

Ein wiederkehrendes Backup automatisierst du per Cron. Cron läuft jedoch mit minimaler Umgebung - das ist die häufigste Fehlerquelle. Beachte deshalb drei Regeln: immer den absoluten Pfad /usr/bin/rsync verwenden, einen passphrase-losen Key mit chmod 600 (oder ssh-agent) nutzen und PATH sowie MAILTO in der Crontab setzen.

Lege zuerst die Crontab des passenden Benutzers an:

crontab -e

Und trage dann einen täglichen Lauf um 02:30 Uhr ein. Die Ausgabe wird in eine Logdatei umgeleitet, damit du Fehler nachvollziehen kannst:

# Crontab-Kopf: Umgebung explizit setzen
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=admin@DEINE-DOMAIN

# Taeglich 02:30 Uhr: Sync ueber SSH mit Key, Ausgabe ins Log
30 2 * * * /usr/bin/rsync -az --delete -e "ssh -i /home/user/.ssh/id_ed25519" /daten/ user@host:/backup/daten/ >> /var/log/rsync-backup.log 2>&1

Verbinde dich vor dem ersten unbeaufsichtigten Lauf einmal manuell per ssh user@host, damit der Hostkey in ~/.ssh/known_hosts landet - sonst hängt oder bricht der erste Cron-Lauf wegen unbekanntem Hostkey ab. Die Cron-Syntax selbst vertieft die verlinkte crontab-Anleitung.

Troubleshooting

Daten landen verschachtelt (z. B. /dst/src/...): Trailing-Slash-Fehler. Mit quelle/ kopierst du den Inhalt, ohne Slash das Verzeichnis selbst. Prüfe den Slash an der Quelle.
--delete hat zu viel gelöscht: Die Quelle war leer, falsch gemountet oder falsch geschrieben. Immer zuerst rsync -n --delete ... als Probelauf, Ausgabe lesen, dann erst scharf schalten.
Alle Dateien gehören am Ziel dem falschen User: rsync lief nicht als root, oder --numeric-ids fehlte. Für Migrationen root nach root und --numeric-ids setzen.
Cron findet rsync/ssh nicht oder fragt nach Passphrase: Relativer Befehl statt absolutem Pfad, fehlendes PATH oder ein Key mit Passphrase ohne ssh-agent. Lösung: /usr/bin/rsync, passphrase-loser Key mit chmod 600 bzw. ssh-agent, PATH/MAILTO in der Crontab.
Erster Lauf hängt am Hostkey: StrictHostKeyChecking blockiert unbekannte Hosts. Verbinde dich vorher einmal manuell, damit der Host in known_hosts landet. Deaktiviere StrictHostKeyChecking nicht leichtfertig - das ist ein Sicherheitsrisiko.
Übertragung ist langsamer als erwartet: -z in schnellen LANs oder bei bereits komprimierten Dateien (Bilder, Videos, Archive) bremst statt zu beschleunigen. Dort Kompression weglassen.

Häufige Fragen

Was genau bewirkt der Slash am Ende der Quelle?

Mit Slash (quelle/) kopiert rsync nur den Inhalt des Verzeichnisses ins Ziel. Ohne Slash (quelle) kopiert es das Verzeichnis selbst als Unterordner ins Ziel. Am Ziel ist ein abschließender Slash bedeutungslos.

Brauche ich das `-e ssh` überhaupt noch?

Technisch meist nicht - SSH ist heute der Default-Transport von rsync. Aus Gründen der Klarheit und Dokumentation schreibt man es trotzdem oft hin, und sobald du Port oder Key angeben willst, brauchst du -e "ssh -p 2222 -i ..." ohnehin.

Wann sollte ich `-z` (Kompression) nutzen?

Nur in langsamen WAN-Verbindungen. In schnellen LANs oder bei bereits komprimierten Daten wie Bildern, Videos oder Archiven verursacht -z nur CPU-Overhead und bremst die Übertragung eher, als dass es nützt.

Warum brauche ich bei der Migration `--numeric-ids`?

Ohne diese Option mappt rsync uid und gid über die Benutzer-/Gruppennamen. Fehlt der Benutzer am Ziel oder hat dort eine andere ID, entsteht falsche Ownership. --numeric-ids überträgt die rohen Zahlen und erhält die Eigentümer korrekt.

Ist rsync ein vollständiges Backup?

Nein. rsync ist ein Sync-Werkzeug. Ohne Versionierung oder Snapshots werden auch fehlerhafte Änderungen oder Löschungen übernommen. Für echte Backups mit Restore-Punkten kombinierst du rsync mit Snapshots bzw. --link-dest und einer getesteten Restore-Routine.

Fazit

Mit dem Standardkommando rsync -avzhP -e ssh QUELLE user@host:/ZIEL, einem SSH-Key statt Passwort und dem bewussten Umgang mit dem Trailing-Slash hast du die wichtigsten 90 Prozent abgedeckt. Spiegeln erledigst du mit --delete - immer nach einem --dry-run. Ganze Server ziehst du als root mit -aHAXvz --numeric-ids um, und wiederkehrende Syncs automatisierst du per Cron mit absolutem Pfad und passphrase-losem Key. Denk daran: rsync ist ein erstklassiges Werkzeug, aber kein Ersatz für eine durchdachte Backup-Strategie mit Versionierung und getestetem Restore.

Weiterführende Anleitungen und Quellen

Diese Anleitungen ergänzen den rsync-Einsatz und bauen die nötige Basis bzw. Strategie drumherum:

SSH-Key-Authentifizierung unter Linux und Windows einrichten - die Grundlage für passwortlose, automatisierbare rsync-Transfers.
Eine Backup- und Restore-Test-Routine etablieren - weil rsync allein noch keine vollständige Backup-Strategie ist.
Cron und crontab unter Linux: Grundlagen - vertieft die Zeitsteuerung für geplante Syncs aus Schritt 7.
Alle Anleitungen der Kategorie Linux für weitere Themen rund um die Server-Administration.

Quellen: