Warum lädt ein Cloud-Synchronisierungsauftrag zuvor gelöschte Dateien erneut hoch, nachdem seine Statusdatenbank wiederhergestellt wurde?

Eine wiederhergestellte Synchronisierungsdatenbank kann gelöschte Dateien erneut hochladen, wenn sie die Löschdatensätze nicht mehr enthält, die eine beabsichtigte Entfernung von neu entdeckten lokalen Daten unterschieden haben.

Die Zwei-Wege-Synchronisierung basiert auf mehr als den aktuell sichtbaren Dateien. Sie verwaltet einen Index oder eine Datenbank mit früheren Pfaden, Versionen, Geräte-IDs, Löschmarkierungen und dem Synchronisierungsstatus. Wenn eine ältere Datenbank wiederhergestellt wird, während neuere lokale Dateien oder ein neuerer Cloud-Status bestehen bleiben, entsteht ein zeitlicher Widerspruch: Der Client kann eine erhaltene lokale Kopie als neu scannen oder die Remote-Löschung als Konflikt interpretieren. Halten Sie alle Synchronisierungsteilnehmer an, bevor Sie entscheiden, welche Zeitlinie maßgeblich ist.

Bestätigen, welche Datenbank und welcher Dateibaum wiederhergestellt wurden

Notieren Sie den Zeitpunkt der Datenbanksicherung, den Zeitpunkt des lokalen Dateibaums, den Cloud-Status, die Client-Konfiguration, die Geräteidentität und das erste Ereignis des erneuten Uploads. Prüfen Sie, ob Datenbank und Dateien vom selben Wiederherstellungspunkt stammen.

Das Wiederherstellungsverfahren von Nextcloud erfordert die Wiederherstellung von Datenbank und Datenverzeichnis als ein konsistentes System, da die Wiederherstellung nur einer Ebene Metadaten erzeugt, die nicht mehr zu den gespeicherten Dateien passen.

Wenn die Datenbank älter als die Löschung ist, der lokale Baum jedoch eine ältere erhaltene Kopie enthält, ist ein erneuter Upload vorhersehbar. Bewahren Sie alle drei Zustände auf, bevor Sie einen weiteren automatischen Synchronisierungslauf zulassen.

Prüfen, ob Löschmarkierungen zurückgesetzt wurden

Ermitteln Sie, ob der wiederhergestellte Zustand das Löschereignis, die Dateiversion, die ID des Remote-Elements und das Gerät enthält, das die Datei ursprünglich entfernt hat. Vergleichen Sie die Protokolle unmittelbar vor und nach der Löschung.

Syncthing verwaltet eine lokale Indexdatenbank und weist darauf hin, dass ein Zurücksetzen der Datenbank einen vollständigen Neuscan und eine erneute Synchronisierung erzwingt. Wenn später ein älterer eingebundener Dateibaum erscheint, können inkonsistente Versionen entstehen.

Eine Löschung, die nur in der neueren Datenbank vorhanden war, fehlt nach dem Zurücksetzen. Beim nächsten Scan wird die verbleibende Datei erkannt, aber der historische Hinweis, dass sie gelöscht bleiben sollte, fehlt.

Statusbehaftete Bisync- oder Zwei-Wege-Listendateien prüfen

Suchen Sie bei Tools wie Rclone Bisync beide vorherigen Listen, das Arbeitsverzeichnis, den Sperrstatus und den letzten erfolgreichen Lauf. Behandeln Sie eine neue Resynchronisierung nicht als gleichwertig mit der Fortsetzung aus einem gültigen Status.

Rclone dokumentiert, dass Bisync über aufeinanderfolgende Läufe hinweg statusbehaftet ist und Arbeitsdaten getrennt von den synchronisierten Ordnern speichert.

Durch das Wiederherstellen oder Löschen dieser Listen kann die Unterscheidung zwischen „seit dem letzten Lauf gelöscht“ und „nur auf dieser Seite vorhanden“ verloren gehen. Führen Sie einen Probelauf durch und speichern Sie beide Listen, bevor Sie den Status neu erstellen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Server-Fingerabdruck nach der Wiederherstellung einer Datenbank aktualisieren

Prüfen Sie, ob die Serverplattform eine Wiederherstellungsmarkierung bereitstellt, die Clients über die Wiederherstellung der Datenbank informiert. Wenden Sie sie an, bevor die Clients erneut eine Verbindung herstellen.

ownCloud weist Administratoren an, nach der Wiederherstellung maintenance:data-fingerprint auszuführen, damit Desktop- und Mobilclients den wiederhergestellten Serverstatus erkennen können.

Ohne einen geänderten Wiederherstellungs-Fingerabdruck können Clients mit Annahmen fortfahren, die für die spätere Datenbank erstellt wurden. Dies kann zu Konflikten, erneuten Uploads oder Versuchen führen, auf dem Server wiederhergestellte Objekte zu löschen.

Lokale Kopien ermitteln, die die Cloud-Löschung überlebt haben

Durchsuchen Sie jedes synchronisierte Gerät, jeden Offline-Ordner, jeden ausgeschlossenen Pfad, den Papierkorb, das Konfliktverzeichnis und jeden temporären Wiederherstellungsordner nach Kopien der gelöschten Datei.

Dropbox erklärt, dass das Löschen eines Elements es auf synchronisierten Geräten entfernen kann, während Kopien, die an anderer Stelle gespeichert sind oder nicht mehr am selben Synchronisierungsstatus teilnehmen, erhalten bleiben können.

Eine erhaltene lokale Datei wird zum möglichen Upload-Kandidaten, wenn die wiederhergestellte Datenbank sie nicht mehr als früher gelöschtes Objekt erkennt. Ermitteln Sie ihren Hash und verschieben Sie sie zur Quarantäne außerhalb des Synchronisierungsstamms, bevor Sie den Abgleich durchführen.

Clients anhalten, bevor der Synchronisierungsstatus zurückgesetzt oder neu erstellt wird

Stoppen Sie die Synchronisierungs-Worker des Servers und halten Sie alle Desktop-, Mobil-, Container- und geplanten Synchronisierungsclients an. Verbinden Sie zuerst einen maßgeblichen Endpunkt erneut.

Das OneDrive-Verfahren von Microsoft zum Zurücksetzen besagt, dass der Client seine lokale DAT-Datei neu erstellt. Dies verdeutlicht, warum ein Zurücksetzen den Clientstatus ändert, aber nicht festlegt, welche historische Dateiversion maßgeblich sein soll.

Ein Zurücksetzen ersetzt nicht die Entscheidung für die richtige Zeitlinie. Wenn mehrere Clients gleichzeitig einen Neuscan durchführen, kann einer eine alte lokale Kopie hochladen, während ein anderer die Löschung weitergibt.

Einen Ordner mit einem Probelauf und einer unabhängigen Sicherung abgleichen

Exportieren Sie die wiederhergestellte Datenbank, kopieren Sie alle konfliktbehafteten lokalen Dateien außerhalb der Synchronisierungsstämme, wählen Sie den maßgeblichen Zustand und testen Sie zunächst einen kleinen Ordner, bevor Sie die gesamte Bibliothek wieder synchronisieren.

Der 3-2-1-Sicherungsleitfaden von ZimaSpace definiert die angrenzende Grenze: Der Synchronisierungsstatus ist keine unabhängige Wiederherstellungskopie, wenn er Löschungen erneut ausführen oder veraltete Daten erneut hochladen kann.

Das Problem ist gelöst, wenn gelöschte Dateien gelöscht bleiben, beabsichtigte erhaltene Dateien einmal hochgeladen werden, Konflikte dokumentiert sind und eine zweite kontrollierte Synchronisierung keine unerwartete Wiederherstellung hervorruft.

Häufig gestellte Fragen

Wird mit der Datenbank auch der Löschverlauf wiederhergestellt?

Nur bis zum Zeitpunkt der Datenbanksicherung. Löschungen, die danach aufgezeichnet wurden, fehlen, sofern sie nicht in einem anderen Protokoll oder auf einem anderen Endpunkt erhalten geblieben sind.

Sollten während der Wiederherstellung alle Synchronisierungsclients verbunden bleiben?

Nein. Halten Sie sie an und verbinden Sie zuerst einen maßgeblichen Endpunkt, damit ältere Clients nicht sofort veraltete Dateien erneut einführen können.

Wird ein vollständiger Neuscan das Problem sicher beheben?

Ein Neuscan erstellt den aktuell vorhandenen Zustand neu, kann jedoch keine fehlende historische Absicht erschließen. Er kann erhaltene Dateien erneut hochladen, sofern nicht zuvor der maßgebliche Zustand festgelegt wurde.