rsync: Dateien sicher synchronisieren und sichern

rsync synchronisiert Dateien lokal oder über SSH und überträgt dabei nur nötige Änderungen. Entscheidend sind jedoch Quellpfad, abschließender Schrägstrich, Metadaten und Löschregeln. Beginnen Sie mit einem Probelauf, prüfen Sie die Gegenstelle und testen Sie die Wiederherstellung. Eine Spiegelung allein ist kein unabhängiges Backup.

Erst Sicherungsziel und Fehlergrenze definieren

rsync ist ein Kopier- und Synchronisationswerkzeug. Es kann einen Verzeichnisbaum effizient an einen zweiten Ort bringen, kennt aber weder Ihre Aufbewahrungsfrist noch den fachlich letzten guten Datenstand. Ein identisches Ziel ist zunächst ein Spiegel. Löscht oder verschlüsselt ein Prozess die Quelle, kann der nächste Lauf genau diesen Schaden übertragen.

Für ein unabhängiges Backup brauchen Sie mehr als einen zweiten Pfad. Das Ziel sollte eine eigene Zugriffsgrenze besitzen, mehrere Wiederherstellungspunkte behalten und nicht mit denselben dauerhaft verfügbaren Schreibrechten wie die Quelle erreichbar sein. Die Kopie muss außerdem auf einem getrennten Fehlerbereich liegen. Zwei Verzeichnisse auf derselben Platte sind keine Redundanz.

Klären Sie vor dem ersten Lauf:

• Umfang: Welcher Quellbaum gehört in die Sicherung, welche temporären Daten nicht?
• Zielstruktur: Soll der Quellordner selbst oder nur sein Inhalt unter dem Ziel erscheinen?
• Metadaten: Brauchen Sie Eigentümer, ACLs, erweiterte Attribute oder Hardlinks beim Restore?
• Aufbewahrung: Genügt ein aktueller Spiegel oder benötigen Sie versionierte Stände?
• Rückweg: In welches isolierte Verzeichnis testen Sie die Wiederherstellung?

Der abschließende Schrägstrich ändert den Zielbaum

Bei rsync ist der Schrägstrich am Ende des Quellpfads keine Schreibvariante. Er entscheidet, welche Ebene am Ziel entsteht. Die Variante ohne Schrägstrich kopiert das Verzeichnis unter seinem Namen. Die Variante mit Schrägstrich kopiert dessen Inhalt in das angegebene Ziel.

Ein lokaler Probelauf für den Inhalt sieht so aus:

rsync -ani /srv/data/ /backup/data/

Das n verhindert Änderungen, i zeigt die geplanten Änderungen einzeln. Prüfen Sie nicht nur die Dateinamen, sondern auch die oberste Zielebene. Ein falsch gesetzter Schrägstrich kann sonst bei jedem Lauf eine unerwartete zusätzliche Verzeichnisebene erzeugen.

Auch das Ziel verdient einen Schrägstrich, wenn es als Verzeichnis gedacht ist. Existiert ein Ziel ohne abschließenden Schrägstrich noch nicht und passt nur ein einzelnes Quellelement, kann dessen Name unerwartet als Zielname interpretiert werden. Legen Sie das Ziel bewusst an und kontrollieren Sie seine Identität vor der Automatisierung.

Lokal und über SSH eindeutig adressieren

Sind beide Pfade lokal, arbeitet rsync wie ein erweitertes Kopierwerkzeug. Bei einer einzelnen entfernten Seite verwendet die Schreibweise Benutzer, Host, Doppelpunkt und Pfad gewöhnlich eine Remote-Shell. Ein Push zu einem Sicherungsserver kann als Vorschau so aussehen:

rsync -aHAXni /srv/data/ backup@backup.example.invalid:/srv/backups/app/current/

Für einen Pull steht die entfernte Adresse auf der Quellseite:

rsync -aHAXni backup@source.example.invalid:/srv/data/ /srv/restore-check/

rsync unterstützt nicht, Quelle und Ziel gleichzeitig als zwei entfernte Hosts anzugeben. Zudem muss rsync auf beiden beteiligten Systemen installiert sein. Testen Sie Client- und Gegenstellenversion, bevor Sie Optionen in einen unbeaufsichtigten Auftrag übernehmen.

SSH verschlüsselt den Transport, löst aber nicht die Identitätsfrage. Prüfen Sie den Fingerabdruck des Hostschlüssels bei der ersten Verbindung über einen getrennten vertrauenswürdigen Kanal. Hinterlegen Sie den geprüften Schlüssel in der known-hosts-Datei und lassen Sie geänderte Schlüssel nicht automatisch akzeptieren.

Für einen geplanten Lauf kann BatchMode interaktive Passwort- und Bestätigungsdialoge unterbinden. Aktivieren Sie das erst, nachdem Anmeldung und Hostschlüsselprüfung kontrolliert funktionieren. Ein unbeaufsichtigter Auftrag soll bei unbekannter Gegenstelle abbrechen, nicht still eine neue Identität übernehmen.

Archivmodus bewahrt nicht alle Metadaten

Die verbreitete Option a steht für rekursives Kopieren mit symbolischen Links, Rechten, Zeitstempeln, Gruppen, Eigentümern sowie Geräte- und Spezialdateien. Sie ist kein vollständiger Metadatenschalter. Hardlinks, ACLs und erweiterte Attribute sind darin nicht enthalten.

Die Kombination aHAX ist für viele Linux-Dateibäume ein sinnvoller Ausgangspunkt, aber keine universelle Garantie. Prüfen Sie, ob Quelle und Ziel dieselben Metadaten abbilden können. Ein Objekt- oder Netzwerkdateisystem kann Eigentümer, ACLs oder erweiterte Attribute anders behandeln als das Quellsystem.

Der ausführende Benutzer setzt ebenfalls eine Grenze. Ohne passende Rechte kann rsync einen numerischen Eigentümer, eine Gerätedatei oder geschützte Attribute nicht vollständig wiederherstellen. Testen Sie deshalb nicht nur den Transfer, sondern die spätere Nutzung unter dem vorgesehenen Dienstkonto. Eine Datei kann vorhanden und dennoch betrieblich unbrauchbar sein.

Änderungen zuerst sichtbar machen

Ein Probelauf mit n schreibt keine Daten. Zusammen mit i liefert er eine kompakte Aufstellung der geplanten Änderungen. Das ist die Freigabeansicht für Pfade, Filter und Metadaten. Verwenden Sie für Vorschau und echten Lauf dieselbe Optionsbasis; entfernen Sie für die Übertragung ausschließlich den Probelauf-Schalter.

rsync -aHAXni --exclude-from="$HOME/rsync-excludes" /srv/data/ backup@backup.example.invalid:/srv/backups/app/current/

Lesen Sie die Ausgabe vollständig. Neue Dateien, geänderte Attribute, ersetzte Typen und unerwartet große Verzeichnisbereiche sind unterschiedliche Befunde. Halten Sie bei einer unklaren obersten Zielebene an. Mehr Ausgabe ist hier billiger als eine schnelle Freigabe.

Ein Probelauf überträgt keine Nutzdaten. Er beweist daher weder genügend freien Speicher noch einen stabilen Datenpfad für große Dateien. Zwischen Vorschau und Ausführung kann sich die Quelle zudem ändern. Begrenzen Sie das Zeitfenster, vermeiden Sie parallele Schreiber oder verwenden Sie einen anwendungskonsistenten Snapshot als Quelle.

Löschungen bleiben ein eigener Freigabeschritt

Die Option delete entfernt Zielobjekte, die im übertragenen Quellbereich nicht mehr vorkommen. Damit wird aus einer Kopie eine engere Spiegelung. Sie ist gefährlich, wenn Quelle, Ziel oder Filter falsch gewählt sind. Geben Sie Löschungen nie allein deshalb frei, weil ein vorheriger Lauf erfolgreich war.

Wenn Sie einen Spiegel wirklich benötigen, prüfen Sie Löschungen in einem gesonderten, begrenzten Probelauf:

rsync -aHAXni --delete --max-delete="$MAX_DELETE" --exclude-from="$HOME/rsync-excludes" /srv/data/ backup@backup.example.invalid:/srv/backups/app/current/

Setzen Sie MAX_DELETE auf eine für diesen Bestand begründete Obergrenze und führen Sie den Befehl nur als Vorschau aus. Kontrollieren Sie jede gemeldete Entfernung und die genaue Zielwurzel. Diese Zeile ist kein Rezept für einen unbeaufsichtigten Produktivlauf. Die Freigabe der realen Löschung gehört in einen separat geprüften Betriebsauftrag.

Filter wirken ebenfalls auf Löschungen. Ausgeschlossene Zielobjekte sind normalerweise vor einer Entfernung geschützt. delete-excluded hebt diesen Schutz auf und kann damit Daten löschen, die gerade wegen eines Filters nicht in der Quelle erscheinen. Verwenden Sie diese Kombination nicht als Abkürzung für eine unklare Aufräumregel.

Eine unabhängige Sicherung sollte frühere Stände nicht durch einen Spiegelbefehl verlieren. Trennen Sie das aktuelle Übertragungsziel von unveränderbaren oder zumindest getrennt berechtigten Wiederherstellungspunkten. Dann bleibt ein versehentlich gelöschtes Objekt aus einem älteren Stand erreichbar.

Unterbrochene Übertragungen kontrolliert fortsetzen

Bei großen Dateien kann partial bereits übertragene Teile behalten. Liegt die Teildatei direkt am Ziel, ist jedoch schwerer erkennbar, ob dort ein vollständiges Objekt steht. Ein relatives partial-dir hält den Zwischenstand in einem gesonderten Verzeichnis und kann ihn bei einem späteren Lauf wiederverwenden.

rsync -aHAXi --partial-dir=.rsync-partial /srv/data/ backup@backup.example.invalid:/srv/backups/app/current/

Das Zwischenverzeichnis darf nicht von anderen Benutzern beschreibbar sein. Verwenden Sie kein allgemein beschreibbares temporäres Verzeichnis. Planen Sie außerdem freien Speicher für Ziel und Teildaten ein und beobachten Sie alte Fragmente nach wiederholten Fehlern.

Ein fortgesetzter Transfer ist noch kein erfolgreicher Sicherungslauf. Bewerten Sie Rückgabestatus und Protokoll, prüfen Sie unvollständige Übertragungen und geben Sie den Stand erst nach der Zielkontrolle für eine Wiederherstellung frei.

Der Transfer ist nur der mittlere Teil der Arbeit. Freigabe und Rückweg liegen bewusst außerhalb des Kopiervorgangs.

Versionierte Stände mit link-dest aufbauen

Mit link-dest kann rsync einen neuen Zielbaum erzeugen und unveränderte Dateien als Hardlinks aus einem Referenzstand übernehmen. Geänderte Dateien werden neu geschrieben. So entstehen vollständig navigierbare Verzeichnisbäume, ohne jede unveränderte Datei mehrfach zu speichern.

Die Referenz muss aus Sicht des Ziels korrekt adressiert sein. Ein relativer Pfad wird gegen das Zielverzeichnis aufgelöst. Dateien werden nur verlinkt, wenn Inhalt und alle zu bewahrenden Attribute passen. Unterschiedliche Eigentümerabbildung oder Mount-Optionen können deshalb unerwartet echte Kopien erzeugen.

link-dest liefert snapshot-ähnliche Bäume, aber keine automatische Aufbewahrungspolitik. Erstellen Sie jeden neuen Stand in einem leeren Ziel, veröffentlichen Sie ihn erst nach erfolgreicher Prüfung und löschen Sie alte Stände nach einer dokumentierten Regel. Ändern Sie eine hardverlinkte Datei nicht nachträglich in place, weil mehrere Stände denselben Inode teilen können.

Liegen Referenz und neue Sicherung unter demselben Speicherkonto und auf demselben Dateisystem, teilen sie weiterhin viele Fehlergrenzen. Ergänzen Sie eine getrennt geschützte Kopie oder einen zweiten Speicherort. Eine effiziente Historie ersetzt keine unabhängige Sicherung.

Ergebnis prüfen und Wiederherstellung üben

rsync entscheidet standardmäßig anhand von Dateigröße und Änderungszeit, welche Inhalte erneut übertragen werden müssen. Das ist schnell und für normale Synchronisation praktisch. Es ist aber keine vollständige Inhaltsprüfung gegen jede denkbare stille Veränderung.

Eine Prüfung mit checksum vergleicht Dateiinhalte und liest dafür beide Seiten vollständig. Das kostet Plattenzugriffe und Laufzeit. Setzen Sie sie gezielt für periodische Integritätsläufe oder besonders kritische Bereiche ein, nicht gedankenlos bei jedem großen Bestand.

Prüfen Sie nach einem Lauf mindestens:

• Rückgabestatus und vollständiges Protokoll des Transfers,
• Anzahl und Art der geänderten oder übersprungenen Objekte,
• verfügbaren Speicher und verbliebene Teildateien,
• stichprobenartig Rechte, ACLs, xattrs und Hardlinks,
• Anwendbarkeit eines isolierten Wiederherstellungsstands.

Für den Restore-Test kopieren Sie einen ausgewählten Stand in ein neues, nicht produktives Verzeichnis. Starten Sie die Anwendung nicht ungeprüft gegen produktive Dienste. Prüfen Sie Dateibaum, Eigentümer und lesende Zugriffe; bei Datenbanken oder anderen zustandsbehafteten Anwendungen folgt zusätzlich deren eigenes Konsistenzwerkzeug.

Der Test braucht ein messbares Ergebnis: gewünschte Datei geöffnet, Archiv entpackt, Konfiguration eingelesen oder Dienst mit isolierten Abhängigkeiten gestartet. Dokumentieren Sie Dauer und fehlende Schritte. Ein erfolgreiches Transferprotokoll ist kein Wiederherstellungsnachweis.

Fazit

rsync ist zuverlässig, wenn Pfade, Metadaten und Löschgrenzen ausdrücklich feststehen. Trennen Sie Vorschau, Übertragung, Prüfung und Wiederherstellung. Für Backups ergänzen Sie versionierte Stände, eine unabhängige Zugriffs- und Fehlergrenze sowie einen echten Restore-Test. Erst der funktionierende Rückweg macht aus kopierten Dateien eine belastbare Sicherung.