Warum kopiert Remote Sync nach dem Wiederverbinden einen gesamten Ordner erneut?

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.

Remote-Sync kopiert einen gesamten Ordner neu, wenn der Client nicht mehr nachweisen kann, dass die lokalen und entfernten Dateien identisch sind.

Nachdem ein Laptop, NAS, eingebundener Share oder entfernter Peer wieder verbunden ist, kann die Sync-Engine ihren Index neu aufbauen, eine andere Dateisystem-Identität erkennen, gespeicherte Hashes verlieren, geänderte Zeitstempel feststellen, umbenannte Dateien als neue Objekte behandeln oder mit einer veralteten Datenbank vergleichen. Die korrekte Diagnose schützt zuerst beide Kopien und bestimmt dann, ob der Client neu scannt, neu hasht, neu herunterlädt oder tatsächlich Daten erneut überträgt, bevor eine Bibliothek zurückgesetzt wird.

Bestätigen, ob der Client scannt, hasht oder überträgt

Erfassen Sie Netzwerkdurchsatz, Festplattenzugriffe, CPU-Auslastung, Client-Status und Log-Meldungen während des scheinbaren Neukopierens. Ein vollständiger Scan oder Prüfsummenlauf kann stundenlang beschäftigt aussehen, ohne den gesamten Ordner über das Internet zu senden.

Eine rclone-Diskussion beschreibt, wie der Prüfsummenmodus bei jedem Lauf die Prüfsummenverarbeitung wiederholen kann. Dieses Verhalten verbraucht Speicher und CPU, unterscheidet sich aber von einer echten Netzwerknachübertragung.

Verwenden Sie Übertragungszähler pro Datei oder Paketanzahlen, um das Ereignis zu klassifizieren. Wenn nur Metadaten und Hashes gelesen werden, optimieren Sie den Scan-Zustand; wenn volle Nutzdaten erneut übertragen werden, fahren Sie mit Identitäts-, Index-, Zeitstempel- und Umbenennungstests fort.

Prüfen, ob die Sync-Datenbank oder der Index neu aufgebaut wurde

Untersuchen Sie die Client-Logs rund um die Wiederverbindung auf Datenbankmigration, Korruption, fehlenden Index, Reset, Rescan oder Erststart-Meldungen. Vergleichen Sie das Client-Konfigurationsverzeichnis und den Datenbank-Zeitstempel mit dem letzten erfolgreichen Sync.

Ein Syncthing-Supportfall erklärt, dass eine beschädigte Index-Datenbank möglicherweise neu aufgebaut werden muss, wodurch das Gerät so reagiert, als wären Ordner neu hinzugefügt worden, und möglicherweise ein großer initialer Rescan ausgelöst wird.

Sichern Sie die Datenbank, bevor Sie sie löschen oder zurücksetzen. Wenn das Neukopieren unmittelbar nach einer App-Neuinstallation, Container-Neuerstellung, Profil-Reset oder Datenbankverlust begann, bewahren Sie die guten Daten und verwenden Sie den vom Client unterstützten Workflow zum Wiederverbinden mit einem bestehenden Ordner.

Datei-Identität über den Dateinamen hinaus vergleichen

Wählen Sie mehrere Dateien aus, die der Client neu kopieren möchte, und vergleichen Sie Größe, Änderungszeit, Prüfsumme, Berechtigungen, Eigentümer, Groß-/Kleinschreibung, erweiterte Attribute und Pfad auf beiden Seiten. Notieren Sie, welches Feld abweicht.

FreeFileSync-Nutzer diskutieren das Speichern von Prüfsummen, da Größe und Zeitstempel allein nicht immer beweisen, dass gepaarte Dateien identisch bleiben, während Prüfsummen-Datenbanken eigene Zustandsanforderungen hinzufügen. Dies zeigt, warum Dateivergleichs-Metadaten nach dem Wiederverbinden wichtig sind.

Wenn Inhalts-Hashes übereinstimmen, aber Zeitstempel oder Berechtigungen abweichen, korrigieren Sie Uhrzeit, Metadaten-Erhalt oder Vergleichseinstellungen, anstatt Inhalte erneut zu übertragen. Wenn Hashes abweichen, bestimmen Sie, welche Seite maßgeblich ist, bevor Sie automatisches Überschreiben zulassen.

-15% OFF

Prüfen, ob der Ordner unter einer anderen Identität wieder verbunden wurde

Vergleichen Sie den eingebundenen Pfad, die Dateisystem-UUID, den Netzwerk-Share-Namen, Laufwerksbuchstaben, Volumenkennung, Container-Bind-Mount und Groß-/Kleinschreibung vor und nach der Trennung. Ein bekannter Ordnerpfad kann auf ein anderes Laufwerk oder ein leeres lokales Verzeichnis zeigen.

Sync-Tools speichern die Ordner-Identität oft in einer lokalen Datenbank, anstatt sich nur auf den angezeigten Pfad zu verlassen. Ein neu eingebundener NAS-Share, ein ausgetauschtes USB-Laufwerk, ein geändertes Docker-Volume oder ein neu erstelltes Client-Profil kann daher wie ein brandneues Ziel aussehen.

Stoppen Sie die Synchronisierung, wenn der erwartete Mount fehlt oder der Ordner auf lokalen Fallback-Speicher zeigt. Stellen Sie den ursprünglichen Mount wieder her und prüfen Sie Beispiel-Dateien, bevor Sie die Bibliothek wieder verbinden, um Löschungen oder doppelte Downloads zu vermeiden.

Testen, ob Verschiebungen und Umbenennungen erkannt werden

Wählen Sie einen kleinen Ordner, benennen Sie ihn um, während beide Peers verbunden sind, und beobachten Sie, ob der Client eine Metadatenverschiebung durchführt oder jede Datei als neuen Inhalt hochlädt. Wiederholen Sie dies nach Trennung und Wiederverbindung.

Eine Syncthing-Feature-Diskussion weist darauf hin, dass Verschiebungen oder Umbenennungen als neue Übertragungen behandelt werden können, wenn das Tool die geänderten Pfade nicht über seinen bestehenden Index zuordnen kann, was Lösch- und Neuhochladeverhalten erzeugt.

Wenn das Neukopieren einer übergeordneten Ordnerumbenennung folgt, lassen Sie den Client den Indexaustausch abschließen, bevor Sie weitere Änderungen vornehmen. Vermeiden Sie bei großen Bibliotheken gleichzeitige Massenumbenennungen auf mehreren Peers und halten Sie Versionsverwaltung oder Backup-Schutz aktiviert.

Sicher wieder verbinden, ohne die gute Kopie zurückzusetzen

Erstellen Sie ein Backup oder Snapshot der maßgeblichen Seite, pausieren Sie die Synchronisierung und testen Sie einen kleinen Unterordner mit der bestehenden-Ordner- oder Neuverknüpfungsfunktion des Clients. Klicken Sie nicht auf einen generischen Reset- oder Resync-Button, bevor Sie dessen Wirkung verstehen.

Der ZimaSpace-Leitfaden zum sicheren Wiederherstellen eines einzelnen freigegebenen Ordners vermittelt dasselbe Eindämmungsprinzip zum Schutz unbetroffener Daten.

Das Problem ist nur gelöst, wenn das Wiederverbinden den Index bewahrt, vorhandene Dateien ohne Nutzdatenübertragung vergleicht, nur echte Änderungen anwendet und eine weitere Trennung übersteht. Wenn die Datenbank wiederholt beschädigt wird oder verschwindet, beheben Sie das Speicher-, Abschalt-, Container-Persistenz- oder Client-Installationsproblem, anstatt wiederkehrende Vollsynchronisierungen zu akzeptieren.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.