Warum kopiert ein Rsync-Spiegel versehentliche Löschungen in das Backup?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Why Does an Rsync Mirror Copy Accidental Deletions to the Backup?

Ein rsync-Spiegel kopiert versehentliche Löschungen, weil ein Spiegel darauf ausgelegt ist, das Ziel an die aktuelle Quelle anzupassen. Wenn der Auftrag verwendet wird --delete oder einer verwandten Löschoption wird eine auf dem Heim-NAS fehlende Datei als zusätzliche Datei auf dem Backup-Ziel behandelt und während der Synchronisierung entfernt. Dieses Verhalten ist für einen Spiegel korrekt, aber unsicher als einzige Wiederherstellungshistorie.

Rsync folgt einer Spiegelregel, bewahrt aber nicht jede frühere Version

Ohne eine Löschoption kopiert rsync normalerweise neue und geänderte Dateien, lässt aber nur im Ziel vorhandene Dateien stehen. Mit --delete wird das Ziel mit der Quelle abgeglichen. Eine kurze Erklärung der Option besagt, dass das Löschen einer Datei in der Quelle sie auch im Ziel entfernt, sodass das Ziel ein echter Spiegel bleibt.

Für ein ZimaSpace-Heim-NAS bedeutet dies, dass ein gelöschtes Familienfoto, ein umbenannter Medienordner, eine entfernte Container-Konfiguration oder ein vorübergehend fehlender Mount beim nächsten geplanten Lauf auf dem USB- oder Remote-Spiegel reflektiert wird.

Das Löschen beginnt mit einem fehlenden Quellpfad

Rsync weiß nicht, ob eine Datei verschwunden ist, weil Sie sie absichtlich gelöscht haben, eine App sie bereinigt hat, ein Benutzer einen Fehler gemacht hat, Ransomware den Baum verändert hat oder ein Quell-Datensatz nicht eingebunden werden konnte. Es vergleicht den sichtbaren Quellbaum mit dem Zielbaum. Wenn ein Objekt nur auf der Empfängerseite existiert und Löschen aktiviert ist, wird es zum Löschkandidaten.

Quellereignis	Was rsync sieht	Spiegelergebnis mit aktiviertem Löschen
Benutzer löscht einen Fotoordner	Ordner fehlt in der Quelle	Ordner wird aus dem Spiegel entfernt
Container-App löscht alte Medien	Dateien fehlen im App-Daten-Pfad	Dateien werden aus dem Spiegel entfernt
NAS-Datenpool kann nicht eingebunden werden	Quellpfad kann leer erscheinen	Große Löschmengen können vorgeschlagen werden
Änderungen am Freigabepfad	Alter Quellbaum wird nicht mehr gescannt	Alter Zielinhalt kann entfernt werden

Das Timing des Löschens ändert, wann Dateien entfernt werden, nicht ob sie entfernt werden.

Die zugehörigen Optionen steuern die Phase der Übertragung. --delete-before entfernt nur im Ziel vorhandene Dateien vor dem Kopieren, --delete-during löscht während der Verarbeitung der Verzeichnisse, und --delete-after wartet, bis die Übertragungen abgeschlossen sind. Sie beeinflussen das Verhalten des freien Speicherplatzes und die Fehleranfälligkeit, verwandeln den Spiegel jedoch nicht in ein versioniertes Backup.

Nutzen Sie das Timing bewusst. Das Löschen vor der Übertragung kann Kapazität freigeben, entfernt aber den vorherigen Spiegelzustand früher. Das Löschen nach der Übertragung bewahrt den alten Zielinhalt länger, aber das Endergebnis entspricht dennoch der Quelle, wenn der Auftrag abgeschlossen ist.

Ein fehlender Mount kann wie eine Massenlöschung aussehen

Einer der gefährlichsten Fälle bei Heimservern tritt auf, wenn der geplante Quellpfad nach dem Ausfall des echten Speicherpools noch als leeres Verzeichnis existiert. Rsync kann dann eine leere Quelle mit einem gefüllten Ziel vergleichen. Ein vorgeschlagener Schutz ist, einen Trockenlauf durchzuführen und die geplanten Löschungen zu zählen, bevor die echte Synchronisation erlaubt wird.

Lass den Job auf einem Heim-NAS fehlschlagen, wenn der erwartete Quell-Mount, die Dateisystem-UUID, das Markierungsverzeichnis oder die Mindestanzahl an Dateien fehlt. Lass das Vorhandensein eines leeren Pfads nicht als gesunde Quelle gelten.

Pause den Job, bevor du versuchst, eine gelöschte Datei wiederherzustellen

Deaktiviere die geplante rsync-Aufgabe sofort.
Führe den Befehl nicht erneut aus, um „zu sehen, ob es sich von selbst behebt“.
Überprüfe Snapshots, Papierkörbe, versionierte Backup-Repositories und die zweite Offline-Kopie.
Wenn der Spiegel die Datei noch enthält, kopiere sie vor dem nächsten Lauf in einen Quarantänepfad außerhalb des rsync-Ziels.
Bestätige, ob die Quelllöschung beabsichtigt war, bevor du sie in die Live-Freigabe wiederherstellst.

Der ZimaSpace-Artikel über das Aufbewahren von Familienfotos in mehreren unabhängigen Kopien ist hier relevant: Ein synchronisierter Spiegel sollte eine Ebene sein, nicht der einzige Ort, an dem eine ältere Datei erhalten bleiben kann.

Vorschau des genauen Löschsatzes

Führe denselben Befehl mit --dry-run, ausführlicher Auflistung und Löschberichterstattung aus. Überprüfe die Quell- und Zielpfade, abschließende Schrägstriche, Ausschlüsse, den Mount-Status und die Anzahl der geplanten Löschungen. Ein aktueller rsync-Sicherheitsartikel betont, dass ein Spiegel versehentliche Löschungen oder Ransomware-Schäden reproduzieren kann und daher eine separate Verlaufsebene benötigt.

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

Behandle eine unerwartet hohe Anzahl von Löschvorgängen als fehlgeschlagenen Vorab-Check. Stoppe und überprüfe, ob das beabsichtigte NAS-Dataset gemountet ist und ob der Befehl nicht auf ein übergeordnetes Verzeichnis oder das falsche Wechsellaufwerk zielt.

Verschobene gelöschte Zieldateien in einen Wiederherstellungsbereich

Wenn Sie einen Spiegel benötigen, aber auch ein kurzes Wiederherstellungsfenster wünschen, kombinieren Sie Löschung mit einem Backup-Verzeichnis oder einer Snapshot-Ebene. Rsync kann ersetzte oder gelöschte Zieldateien in ein datiertes Wiederherstellungsverzeichnis verschieben, anstatt sie sofort zu zerstören. Die Community empfiehlt gelöschte Dateien an einem separaten Ort mit eigener Aufräumrichtlinie aufzubewahren.

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

Testen Sie den Befehl zuerst mit nicht-kritischen Daten. Das Wiederherstellungsverzeichnis muss außerhalb des gespiegelten Teilbaums liegen, sonst könnte ein zukünftiger Lauf es als Teil der Quelle behandeln oder es durch dieselbe Richtlinie löschen.

Verwenden Sie versionierte Snapshots, wenn vergangene Zustände wichtig sind

Ein aktueller Spiegel beantwortet die Frage „Wie sieht die Quelle jetzt aus?“ Ein Backup beantwortet „Wie sah die Quelle vor dem Fehler aus?“ Wenn Sie beides brauchen, behalten Sie den Spiegel für schnellen Zugriff und fügen Sie Dateisystem-Snapshots, Hardlink-Snapshot-Verzeichnisse, ein versioniertes Backup-Tool oder eine zweite Offline-Festplatte hinzu.

Ein Bericht über versehentliche rsync-Löschungen beschreibt die zugrunde liegende Schwäche klar: Ein handgefertigter rsync-Workflow benötigt explizite Rotation und Löschschutzmaßnahmen. Verlassen Sie sich nicht auf ein einziges veränderliches Ziel, das sowohl exakte Synchronisation als auch Langzeithistorie bieten soll.

FAQ

Wenn ich entferne `--delete`, wird der Spiegel zum Backup?

Nicht allein. Nur im Ziel vorhandene Dateien bleiben erhalten, aber überschriebene Dateien können trotzdem ihre vorherigen Inhalte verlieren, und es gibt keinen sauberen Wiederherstellungspunkt für ein bestimmtes Datum. Fügen Sie Snapshots oder ein versioniertes Backup-Repository hinzu.

Welche Löschzeitoption ist am sichersten?

--delete-after verzögert Löschungen bis zum Abschluss der Übertragungen, wodurch der alte Zielzustand während des Laufs länger erhalten bleibt. Es löscht jedoch am Ende weiterhin nur im Ziel vorhandene Dateien, daher bleiben Vorabprüfungen und Versionshistorie notwendig.

Wie stoppe ich eine unerwartete Massenlöschung?

Deaktivieren Sie den Zeitplan, führen Sie einen Trockenlauf mit Lösch-Ausgabe durch, überprüfen Sie den Quell-Mount und Pfad und setzen Sie eine Lösch-Anzahl-Schwelle oder eine Marker-Datei-Prüfung. Führen Sie den Live-Befehl nicht erneut aus, bis die vorgeschlagene Löschliste verstanden ist.

Fazit

Rsync spiegelt versehentliche Löschungen, da Löschoptionen das Backup-Ziel an die sichtbare NAS-Quelle anpassen. Schützen Sie einen ZimaSpace Home-Server-Workflow, indem Sie Mounts überprüfen, Löschvorgänge vorschauen, entfernte Dateien isolieren und versionierte oder Offline-Wiederherstellungspunkte behalten. Ein Spiegel kann nützlich sein, aber ein exakter Spiegel ohne Historie bietet keinen ausreichenden Schutz vor menschlichen Fehlern.