Large migrations · Verification · Der Beweis hinter dem Fortschrittsbalken

Hunderte GB zwischen Clouds verschieben: Woher wissen Sie, dass jede Datei angekommen ist?

Bei 500 GB ist „der Upload schien abgeschlossen“ kein Beweis. Eine zuverlässige Migration erfordert eine dauerhafte Bestandsaufnahme, einen Zustandsübergang für jedes Objekt, eine wiederholbare Wiederherstellung nach Unterbrechungen und einen Nachweis vom Ziel selbst.

Aktualisiert ; 16 Min. Lesezeit.

Kurzantwort

FileArk unterteilt die Bibliothek in Datensätze pro Datei und dauerhafte Warteschlangennachrichten. Ein Mitarbeiter kopiert eine Lieferung, speichert die zurückgegebene Ziel-ID, validiert die Größe, liest genau dieses Objekt zurück und vergleicht SHA-256 mit der Quellnutzlast. Erst wenn diese Prüfungen und die Datenbankaktualisierung erfolgreich waren, wird der Datensatz überprüft und die Nachricht bestätigt.

Warum Maßstab die Bedeutung von „bearbeitet“ verändert

Zehn Dateien sind leicht einsehbar. Zehntausend Dateien sind es nicht. Eine große persönliche Bibliothek kann winzige Dokumente, Videos mit mehreren Gigabyte, leere Dateien, verschachtelte Ordner, Unicode-Namen, archivierte Projekte und Cloud-native Formate kombinieren. Ein Fehler kann sich in einem beeindruckend aussehenden Prozentsatz verbergen.

Summen sind nützlich, aber unvollständig. Zwei Bibliotheken können die gleiche scheinbare Größe aufweisen, während in einer ein Objekt fehlt oder ein abgeschnittenes Objekt enthält, das durch eine nicht verwandte Datei ausgeglichen wird. Die Dateianzahl kann auch nach dem Export nativer Dokumente oder nach ausgeschlossenen Anbieterobjekten unterschiedlich sein.

Die nützliche Wahrheitseinheit ist der Dateiauftrag: welches Quellobjekt gelesen wurde, welches Zielobjekt erstellt wurde, welche Bytes verglichen wurden, wann die Überprüfung abgeschlossen wurde und ob ein Versuch ungelöst bleibt.

Der gesamte FileArk-Lebenszyklus, kommentiert

Kommentierter Lebenszyklus, der den dauerhaften Warteschlangen-Worker für die Einrichtung des Browsers FileArk, den Scanner, die Datenbank und die SHA-256-Überprüfung zeigt
Der Browser startet den Kontrollfluss; Der Scanner, die persistente Warteschlange, die Datenbank und der Worker tragen die langwierige Migration.

Wenn „Start“ akzeptiert wird, schreibt die API zunächst einen Scanauftrag in MongoDB und veröffentlicht dann eine persistente Scannachricht in einer dauerhaften RabbitMQ-Warteschlange mit aktivierter Herausgeberbestätigung. Wenn die Veröffentlichung fehlschlägt, wird der Job als „Fehlgeschlagen“ markiert und die API meldet, dass der Scan nicht sicher in die Warteschlange gestellt werden konnte.

Der Scanner authentifiziert beide Anbieter, inventarisiert die ausgewählte Quelle, vergleicht das endliche Zielkontingent mit den erkannten Bytes und fügt für jede Quelldatei einen Datenbankeintrag hinzu. Es veröffentlicht persistente Migrationsmeldungen und markiert den Scan erst dann als abgeschlossen, wenn diese Veröffentlichungen erfolgreich waren.

Der Migrationsarbeiter verwendet manuelle Bestätigungen und einen Prefetch-Zähler von eins. Eine Zustellung bleibt unbestätigt, während Inhalte gelesen, hochgeladen, erneut gelesen, überprüft und gespeichert werden. Eine gestoppte Verbindung oder ein gestoppter Prozess kann daher unvollendete Arbeit in die Warteschlange zurückbringen.

Eine Datenbankzeile ist ein Checklistenelement und keine Wegwerfbuchhaltung

Jeder Dateieintrag beginnt mit „Ausstehend“, wechselt während eines Versuchs zu „In Bearbeitung“ und erreicht den Status „Hochgeladen“ erst nach der Überprüfung. Versuchsanzahl, Zeitpunkt des letzten Versuchs, Fehlerdetails, Zielobjekt-ID, beide SHA-256-Digests, Überprüfungsmethode und VerifiedAt bleiben dem Datensatz zugeordnet.

Abgeschlossene Datensätze bleiben als Fortschritts- und Prüfprotokoll in der Datenbank erhalten. „Eine Akte durchstreichen“ bedeutet eine kontrollierte Zustandsänderung, nicht das Löschen der Beweise. Doppelte Warteschlangenlieferungen überprüfen diesen Status und bestätigen sofort einen Datensatz, der bereits als „Hochgeladen mit VerifiedAt“ markiert ist.

Nach drei erfolglosen Versuchen wird ein anhaltendes Problem zu „Fehlgeschlagen“ mit einem Abschlusszeitstempel für den Versuchszyklus. Dies macht Ausnahmen sichtbar und verhindert, dass eine fehlerhafte Meldung ewig weiterläuft, während das Dashboard hängen bleibt.

Das Abschlusstor für eine Datei
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

Warum eine Datei mehr als einmal geliefert werden kann

Zuverlässige Warteschlangen bieten im Allgemeinen eine mindestens einmalige Zustellung und kein magisches Versprechen, genau einmal über eine Cloud-API, einen Nachrichtenbroker und eine Datenbank hinweg zuzustellen. Ein Absturz kann auftreten, nachdem OneDrive oder Google Drive einen Upload akzeptiert, aber bevor der Mitarbeiter den Abschluss schreibt.

FileArk bewältigt diese Unsicherheit mit idempotenten Datensätzen und Zielwiederherstellung. Der Mitarbeiter prüft zunächst, ob der Datensatz bereits verifiziert ist. Wenn nicht, kann es die gespeicherte Ziel-ID verwenden oder den erwarteten Zielpfad und die genaue Größe für das unterbrochene Ergebnis durchsuchen, bevor es sich für einen erneuten Upload entscheidet.

Wiederherstellungskandidaten werden dann derselben exakten Objekt-Hash-Verifizierung unterzogen. Es reicht nicht aus, einen bekannten Dateinamen zu finden. Es geht darum, einen abgebrochenen Versuch wieder in Beweise umzuwandeln, nicht in einen optimistischen Erfolg.

Die Kapazität wird am Zielort und beim Arbeiter überprüft

Bevor Aufträge pro Datei veröffentlicht werden, summiert der Scanner die nicht-negativen Quellmetadatengrößen und vergleicht den Bedarf mit dem gemeldeten verbleibenden Speicher des Ziels, wenn der Anbieter ein begrenztes Kontingent bereitstellt. Ein zu kleines Ziel schlägt beim Scan fehl, anstatt die Arbeit in eine bekannte Sackgasse zu leiten.

Bei der Zahl handelt es sich um einen Preflight-Wert und nicht um eine Garantie: Kontoaktivitäten können während eines Laufs Speicherplatz verbrauchen, Anbieterkontingentberichte können verzögert sein und exportierte Cloud-native-Dateien haben möglicherweise keine herkömmliche Quellgröße. Die Anbieterdurchsetzung und die Fehlerbehandlung pro Datei bleiben aktiv.

Ihre Computerfestplatte wird nicht für das Staging verwendet. Auf dem Migrations-Worker werden Dateien über dem Speicherschwellenwert erst dann in einem isolierten temporären Verzeichnis abgelegt, wenn das Volume Platz für das erwartete Objekt plus eine Reserve von zwei Gigabyte bietet. Temporäre Inhalte werden bei der Bereinigung entfernt, unabhängig davon, ob der Versuch erfolgreich ist oder nicht.

Warum Ziel-ID plus SHA-256 wichtig sind

Ein Dateiname ist keine eindeutige Identität. Das Ziel enthält möglicherweise bereits zwei Dateien mit demselben sichtbaren Namen, oder es kann einige Zeit dauern, bis die Metadatenliste eingerichtet ist. Die Upload-Antwort stellt eine Anbieterobjekt-ID bereit und FileArk speichert diese ID vor der letzten Überprüfungsphase.

Der Worker berechnet SHA-256 über den gesamten Quell-Nutzdatenstrom, lädt ihn hoch, öffnet dann das genaue Zielobjekt mit dieser ID und berechnet SHA-256 erneut. Gleiche Größe fängt offensichtliche Kürzungen ab; Gleicher kryptografischer Digest ist die stärkere Prüfung auf Byteebene.

Es wird nur die übertragene Dateidarstellung abgedeckt. Ein Digest kann keine Freigaberegeln, Kommentare, Versionen, Beschriftungen, Verknüpfungen, Aufbewahrungseinstellungen oder die Art und Weise, wie ein exportiertes Google-Dokument für einen Benutzer gerendert wird, validieren. Das bleiben Abnahmeaufgaben. __FILERK_0013__ Hunderte GB zwischen Clouds verschieben: Woher wissen Sie, dass jede Datei angekommen ist?

Das Löschen der Quelle liegt absichtlich außerhalb des normalen Erfolgspfads

Die sicherste Standardeinstellung ist „Nur kopieren“ und die Löschoption von FileArk ist deaktiviert, sofern Sie sie nicht aktivieren. Wenn die Löschung deaktiviert ist, kann das Original bei einem Verifizierungsfehler nicht entfernt werden, da die Löschung nie angefordert wird.

Wenn Sie das Löschen nach dem Verschieben absichtlich aktivieren, wartet der Worker immer noch auf die Ziel-ID, die Größe und die SHA-256-Validierung, bevor er den Löschvorgang des Quellanbieters aufruft. Die bessere betriebliche Wahl für unersetzliche oder sehr große Bibliotheken besteht immer noch darin, die Option auszulassen und einen vom Menschen genehmigten Überlappungszeitraum zu verwenden.

Migrationsantworten: „Ist eine verifizierte Kopie angekommen?“ Aufbewahrungsantworten: „Wann darf die alte Kopie entfernt werden?“ Behandeln Sie sie als separate Entscheidungen mit separaten Beweisen.

Das gleiche Steuerungsmodell funktioniert in beide Richtungen

Für OneDrive zu Google Drive wird die Quellnutzlast aus Microsoft Graph gelesen und das Zielobjekt wird über Google Drive anhand seiner zurückgegebenen ID überprüft. Für Google Drive zu OneDrive wird die Quelle über Google Drive heruntergeladen oder exportiert und das neue OneDrive-Element wird über Microsoft Graph zurückgelesen.

Die Warteschlange, die Datenbankstatus, die begrenzten Versuche, der Kapazitäts-Preflight, der Quell-Digest, die Ziel-ID, der Ziel-Digest und die Bestätigungsreihenfolge sind richtungsneutral. Anbieteradapter verarbeiten die verschiedenen Upload-, Ordner- und Inhalts-APIs.

Die Asymmetrie ist Inhaltssemantik. Google-native Dokumente müssen exportiert werden, und beide Plattformen verfügen über dienstspezifisches Freigabe- und Versionsverhalten. Byte-verifizierte Dateiinhalte sollten nicht als vollständiger Klon aller Kollaborationsfunktionen vermarktet werden.

Verwenden Sie einen vierteiligen Abnahmeplan

  1. Gleichen Sie den Systemdatensatz ab

    Überprüfung abgeschlossen, ausstehend, in Bearbeitung und fehlgeschlagene Zählungen. Kein fehlgeschlagener Artikel sollte abgewiesen werden, da der Gesamtprozentsatz hoch ist.

  2. Probe nach Risiko __FILERK_0013__ Kommentierter Lebenszyklus, der den dauerhaften Warteschlangen-Worker für die Einrichtung des Browsers FileArk, den Scanner, die Datenbank und die SHA-256-Überprüfung zeigt

    Öffnen Sie die Dateien, deren Verlust am meisten schaden würde, sowie große Medien, Archive, alte Dokumente, nicht-englische Namen, verschachtelte Pfade und konvertierte Cloud-native-Dateien.

  3. Zielverhalten validieren

    Testen Sie den Zugriff von echten Geräten und Benutzern. Erstellen Sie die erforderliche Freigabe neu und bestätigen Sie, dass Office- oder exportierte Google-Dateien wie erwartet geöffnet werden.

  4. Halten Sie einen Überschneidungszeitraum ein

    Halten Sie die Quelle verfügbar und stabil, während der normale Gebrauch das Ziel belastet. Treffen Sie später eine Entscheidung über die Stornierung oder Löschung.

Häufig gestellte Fragen

Verwendet FileArk eine Warteschlange für jede Datei?

Ja. Der Scanner erstellt oder verwendet einen Datenbankeintrag pro Quelldatei wieder und veröffentlicht eine dauerhafte Migrationsnachricht. Mitarbeiter rufen diese Nachrichten mit manueller Bestätigung ab.

Wann wird eine Warteschlangennachricht bestätigt?

Nachdem die Zielobjekt-ID, die Größe und SHA-256 überprüft wurden und der Uploaded- und VerifiedAt-Status beibehalten wurde. Unvollendete Lieferungen können nachgeliefert werden.

Werden abgeschlossene Akteneinträge aus der Datenbank gelöscht?

Nein. Der Abschluss ist ein Zustandsübergang im dauerhaften Datensatz. In der Zeile werden Zielidentität, Verifizierungsnachweise, Zeitpunkt und Versuchsinformationen für Fortschritt und Prüfung gespeichert.

Kann SHA-256 verschobene Berechtigungen und Versionen nachweisen?

Nein. Es wird bewiesen, dass die Bytes der Zieldatei mit den übertragenen Quellnutzdaten übereinstimmen. Freigabe, Berechtigungen, Versionen, Kommentare, Beschriftungen, Verknüpfungen und anbieternatives Verhalten erfordern eine separate Validierung.

Wird die Verifizierung von OneDrive zu Google Drive auf die gleiche Weise durchgeführt wie umgekehrt?

Die Grundregel ist in beiden Richtungen dieselbe: Quell-Payload-Digest, Zielobjektidentität, Zielgröße, Digest für erneutes Herunterladen des genauen Objekts, dauerhafte Überprüfung und dann Warteschlangenbestätigung.

Für diese Anleitung verwendete offizielle Ressourcen

Anleitung lesen