Rsync vs. scp: Der richtige Linux-Kopierbefehl

Nimm rsync für alles, was größer ist als eine schnelle Einmal-Kopie, und scp, wenn du einfach nur sofort eine Datei auf einem anderen Kasten haben willst. Der Kernunterschied: scp streamt jedes Mal die komplette Datei und hat kein Gedächtnis für abgebrochene Verbindungen, während rsync Quelle und Ziel vergleicht, nur die veränderten Blöcke überträgt und eine unterbrochene Kopie dort fortsetzt, wo sie aufhörte. Bei einem großen Backup über eine wackelige Leitung ist das der Unterschied zwischen zwei Minuten und neu anfangen. Beide kommen mit OpenSSH auf praktisch jeder Linux-Distribution — das ist also eine Gewohnheitsentscheidung, keine Installationsentscheidung, und die Gewohnheit sollte auf rsync stehen. Unten: eine ehrliche Vergleichstabelle, echte Tempounterschiede, der Resume-Trick, den scp nicht kann, und die Fälle, in denen scp trotzdem die richtige Antwort ist.

Was ist der Unterschied zwischen rsync und scp?

scp macht genau eine Sache: SSH-Kanal auf, Bytes streamen, zu. Es hat keinen Zustand zwischen Läufen — stirbt der Transfer bei 90 %, beginnst du bei null.

rsync ist ein Synchronisierungswerkzeug, das zufällig SSH als Transport nutzt. Vor dem Senden baut es eine Prüfsummenliste der Zieldatei auf (der Rolling-Checksum-Delta-Algorithmus) und überträgt nur die Blöcke, die abweichen. Derselbe Befehl zweimal: Der zweite Lauf bewegt fast nichts. Das macht rsync auch zum natürlichen Werkzeug, um zwei Verzeichnisse synchron zu halten — einplanen, und jeder Lauf kopiert nur die Deltas.

Die praktischen Folgen:

• Abbrüche: rsync setzt fort; scp startet die Datei neu.
• Zweite Kopien: rsync sendet nur Änderungen; scp sendet alles erneut.
• Löschungen: rsync kann Löschungen mit --delete spiegeln; scp kann es nicht.
• Filtern: rsync hat --exclude-Muster; scp kopiert alles, worauf du zeigst.
• Dry Runs: rsync zeigt mit --dry-run, was es täte; scp bietet nichts.

Ist rsync schneller als scp?

Bei der ersten Kopie einer großen Datei über eine schnelle Leitung liegen sie nah beieinander — beide stopfen SSH voll, und der Prüfsummen-Durchgang kostet nur wenig Overhead. Die Lücke öffnet sich an drei Stellen:

1. Viele kleine Dateien. rsync pipelined Verzeichnisdurchläufe und kann eine Verbindung wiederverwenden; ältere scp-Setups machten pro Datei eigene Arbeit. Tausende kleine Dateien (ein node_modules, eine WordPress-Installation) sind mit rsync spürbar schneller durch.
2. Erneute Läufe. Kopierst du eine 4-GB-Datei, an der sich 50 MB geändert haben, bewegt rsync grob 50 MB; scp bewegt erneut 4 GB.
3. Kompression. -z komprimiert unterwegs — hilft auf langsamen WAN-Leitungen.

Miss gerne selbst — der Befehl ist in der Form identisch:

# gleiche Datei, gleicher Server, beides über SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# nochmal beide: scp kopiert neu, rsync prüft und sendet ~nichts
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Wenn du deinen Tag auf Servern verbringst, ist Transfertempo eine der Sachen, die sich einmal messen lohnen — so wie ss auf beschäftigten Hosts netstat schlägt (siehe ss vs netstat: welcher Linux-Port-Befehl wann).

Kann scp einen abgebrochenen Transfer fortsetzen?

Nein. scp hat kein Resume; bricht die Verbindung bei 900 MB von 1 GB ab, fängst du von vorn an. Das ist der meistzitierte Grund in jeder rsync-vs-scp-Debatte, und er ist real.

rsyncs gesamtes Design geht davon aus, dass der Transfer manchmal abbricht. Der kanonische Resume-Spruch:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial behält die halb geschriebene Datei, statt sie zu löschen.
• --append-verify setzt per Anhang fort und prüft den angehängten Bereich per Prüfsumme — sicher gegen eine korrupte Teil-Datei, anders als das alte pure --append.
• --progress zeigt dir, wo er wiederaufgesetzt hat.

In eine Retry-Schleife gewickelt, ist das ein Einrichten-und-Vergessen-Backup über selbst feindliche Verbindungen:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

Wann solltest du scp statt rsync nehmen?

scp bleibt in einer Handvoll Fällen das richtige Werkzeug:

• Eine kleine Datei, einmal. scp app.conf user@host:/etc/myapp/ zu tippen ist kürzer als jeder rsync-Aufruf, und fortzusetzen gibt es nichts.
• rsync fehlt am anderen Ende. rsync braucht sein Binary auf beiden Seiten. Viele minimale Container und Appliances liefern scps SFTP-Server mit, aber nicht rsync.
• Du willst keinen rsync-Server exponieren. Selten, aber manche Umgebungen sperren den rsync-Daemon gezielt.

Eine Feinheit, die man kennen sollte: Das OpenSSH-Projekt hat scps ursprüngliches Protokoll vor Jahren für veraltet erklärt, und modernes scp spricht darunter tatsächlich SFTP. Das fixte einen Pfad-Escape-Quirk, aber an den beiden Einschränkungen, die hier zählen — kein Resume, kein Delta-Transfer — änderte es nichts. Die Protokollumstellung macht scp nicht zu rsync.

Auch verwandt: Ist deine Frage wirklich „rsync vs cp”, spiegelt die Antwort diese hier — cp ist das lokale Gegenstück zu scp (kein Resume, kein Delta, keine Attribute ohne Extra-Flags), und rsync funktioniert lokal wie remote. Für lokale Einmal-Kopien ist cp fein.

Welche rsync-Flags sind am wichtigsten?

Die meisten brauchen nur eine Zeile:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Flag	Was es macht
-a (archive)	Rekursiv + behält Berechtigungen, Zeiten, Gruppe, Symlinks, Devices
-v (verbose)	Listet auf, was es überträgt
-h (human)	Menschenlesbare Größen
--partial	Teilweise übertragene Dateien behalten, damit ein erneuter Lauf fortsetzt
--progress	Fortschritt pro Datei — das, was scp nie hatte
-z	Unterwegs komprimieren (schwache CPUs an schnellem LAN: weglassen)
--delete	Auch Löschungen spiegeln — gefährlich, immer mit einem Dry Run paaren
--dry-run (-n)	Zeigen, was passieren würde, nichts ändern

Zwei Gewohnheiten, die sich lohnen. Erstens: alles mit --delete erst im Dry Run:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # erst prüfen
rsync -avh --delete src/ user@server:/srv/dest/             # dann ausführen

Zweitens: auf den Slash am Ende achten — /srv/src kopiert das Verzeichnis selbst ins Ziel, /srv/src/ kopiert seinen Inhalt. Das erwischt jeden einmal; rsync warnt sogar mit „no bytes transferred”, wenn du die andere Form gemeint hast.

Für einen täglichen oder wöchentlichen Sync: rsync in einen systemd-Timer werfen und nur die Deltas kopieren lassen — die journalctl-Seite der Einplanung deckt der journalctl-Spickzettel ab.

Rsync vs. scp: das Fazit

	scp	rsync
Kommt mit OpenSSH	Ja	Ja (beide Enden nötig)
Abgebrochenen Transfer fortsetzen	Nein	Ja (--partial)
Delta-Transfer bei erneuten Läufen	Nein	Ja
Berechtigungen/Symlinks erhalten	Teilweise	Vollständig (-a)
Exclude-Muster	Nein	--exclude
Dry Run	Nein	--dry-run
Löschungen spiegeln	Nein	--delete
Am besten für	Schnelle Einmal-Kopien	Backups, Syncs, große Bäume

Standard auf rsync für Backups, große Bäume, alles über Leitungen, die abbrechen können, und alles, was du mehr als einmal laufen lässt. Nimm scp, wenn der Befehl kürzer ist als der Gedanke. Nimmst du ein Flag mit, dann --partial — es verwandelt jeden künftigen Verbindungsabbruch von einem Neustart in eine Pause.