Przenoszenie setek GB między chmurami: skąd wiesz, że przybył każdy plik?

Krótka odpowiedź

FileArk dzieli bibliotekę na rekordy dotyczące poszczególnych plików i trwałe komunikaty w kolejce. Pracownik kopiuje jedną dostawę, przechowuje zwrócony identyfikator miejsca docelowego, sprawdza rozmiar, odczytuje dokładnie ten obiekt i porównuje SHA-256 z ładunkiem źródłowym. Rekord zostanie zweryfikowany – a wiadomość zostanie potwierdzona – dopiero po pomyślnym zakończeniu tych kontroli i aktualizacji bazy danych.

Dlaczego skala zmienia znaczenie słowa „przepracowany”

Dziesięć plików można łatwo sprawdzić. Dziesięć tysięcy plików nie jest. Duża biblioteka osobista może łączyć małe dokumenty, wielogigabajtowe filmy, puste pliki, zagnieżdżone foldery, nazwy Unicode, zarchiwizowane projekty i formaty natywne w chmurze. Jedna porażka może ukryć się w imponująco wyglądającym procencie.

Sumy są przydatne, ale niekompletne. Dwie biblioteki mogą wykazywać ten sam pozorny rozmiar, podczas gdy w jednej brakuje obiektu lub zawiera on obcięty obiekt zrównoważony przez jakiś niepowiązany plik. Liczba plików może się także różnić w przypadku eksportu dokumentów natywnych lub wykluczonych obiektów dostawców.

Przydatną jednostką prawdy jest zadanie pliku: który obiekt źródłowy został odczytany, jaki obiekt docelowy został utworzony, jakie bajty porównano, kiedy weryfikacja została zakończona i czy jakakolwiek próba pozostała nierozwiązana.

Pełny cykl życia FileArk, z adnotacją

Po zaakceptowaniu opcji Start interfejs API najpierw zapisuje zadanie skanowania w MongoDB, a następnie publikuje trwały komunikat skanowania w trwałej kolejce RabbitMQ z włączonym potwierdzeniem wydawcy. Jeśli publikowanie nie powiedzie się, zadanie zostanie oznaczone jako Nieudane, a interfejs API zgłosi, że nie można bezpiecznie umieścić w kolejce skanowania.

Skaner uwierzytelnia obu dostawców, inwentaryzuje wybrane źródło, sprawdza skończony limit miejsca docelowego pod kątem wykrytych bajtów i wstawia rekord bazy danych dla każdego pliku źródłowego. Publikuje trwałe komunikaty o migracji i oznacza zakończenie skanowania dopiero po pomyślnym opublikowaniu.

Proces roboczy migracji korzysta z ręcznych potwierdzeń, a liczba pobrań z wyprzedzeniem wynosi jeden. Dostarczenie pozostaje niepotwierdzone, dopóki treść jest czytana, przesyłana, ponownie czytana, weryfikowana i utrwalana. Zatrzymane połączenie lub proces może zatem zwrócić niedokończoną pracę do kolejki.

Wiersz bazy danych to pozycja listy kontrolnej, a nie jednorazowa księgowość

Każdy rekord pliku rozpoczyna się od Oczekiwania, podczas próby przechodzi do InProgress i osiąga Przesłany dopiero po weryfikacji. Liczba prób, czas ostatniej próby, szczegóły błędu, identyfikator obiektu docelowego, skróty SHA-256, metoda weryfikacji i VerifiedAt pozostają dołączone do rekordu.

Ukończone zapisy pozostają w bazie danych jako ścieżka postępu i audytu. „Skreślenie akt” oznacza kontrolowaną zmianę stanu, a nie usunięcie materiału dowodowego. Zduplikowane dostawy w kolejce sprawdzają ten stan i natychmiast potwierdzają rekord już oznaczony jako Przesłany za pomocą VerifiedAt.

Po trzech nieudanych próbach utrzymujący się problem zostaje zakończony niepowodzeniem i zawiera znacznik czasu zakończenia cyklu prób. Dzięki temu wyjątki są widoczne i zapobiegają ciągłemu wyświetlaniu trującego komunikatu, gdy pulpit nawigacyjny wydaje się zablokowany.

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

Dlaczego plik może zostać dostarczony więcej niż raz

Niezawodne kolejki zazwyczaj zapewniają dostawę co najmniej raz, a nie magiczną obietnicę dostarczenia dokładnie raz w interfejsie API chmury, brokerze komunikatów i bazie danych. Awaria może wystąpić po zaakceptowaniu przesyłania w usłudze OneDrive lub Google Drive, ale zanim pracownik zapisze zakończenie.

FileArk radzi sobie z tą niepewnością dzięki rekordom idempotentnym i odzyskiwaniu miejsc docelowych. Pracownik najpierw sprawdza, czy zapis jest już zweryfikowany. Jeśli nie, może użyć zapisanego identyfikatora miejsca docelowego lub przeszukać oczekiwaną ścieżkę docelową i dokładny rozmiar przerwanego wyniku przed podjęciem decyzji o ponownym przesłaniu.

Kandydaci do odzyskiwania są następnie poddawani tej samej weryfikacji skrótu dokładnego obiektu. Znalezienie znanej nazwy pliku nie wystarczy. Chodzi o to, aby przerwaną próbę zamienić z powrotem w dowód, a nie w optymistyczny sukces.

Wydajność sprawdzana jest w miejscu przeznaczenia i u pracownika

Przed opublikowaniem zadań dla poszczególnych plików skaner sumuje nieujemne rozmiary metadanych źródłowych i porównuje wymagania z raportowaną pozostałą pamięcią w miejscu docelowym, gdy dostawca zapewnia skończoną ilość miejsca. Niewymiarowe miejsce docelowe nie zostanie przeskanowane, zamiast skierować pracę w znany ślepy zaułek.

Liczba ta dotyczy wstępnej inspekcji, a nie gwarancji: aktywność konta może zużywać miejsce w trakcie działania, raporty dotyczące przydziału dostawcy mogą być opóźnione, a wyeksportowane pliki natywne w chmurze mogą nie mieć konwencjonalnego rozmiaru źródłowego. Wymuszanie dostawcy i obsługa błędów poszczególnych plików pozostają aktywne.

Dysk komputera nie jest używany do przemieszczania. W procesie migracji pliki przekraczające próg pamięci są umieszczane w izolowanym katalogu tymczasowym dopiero wtedy, gdy na woluminie znajdzie się miejsce na oczekiwany obiekt plus dwugigabajtowa rezerwa. Treść tymczasowa jest usuwana podczas czyszczenia niezależnie od tego, czy próba się powiedzie, czy zakończy się niepowodzeniem.

Dlaczego identyfikator miejsca docelowego i SHA-256 mają znaczenie

Nazwa pliku nie jest unikalną tożsamością. Miejsce docelowe może już zawierać dwa pliki o tej samej widocznej nazwie lub ustalenie metadanych może zająć trochę czasu. Odpowiedź przesyłania zapewnia identyfikator obiektu dostawcy, a FileArk przechowuje ten identyfikator przed końcowym etapem weryfikacji.

Proces roboczy oblicza SHA-256 w źródłowym strumieniu ładunku, przesyła go, następnie otwiera dokładny obiekt docelowy według tego identyfikatora i ponownie oblicza SHA-256. Równy rozmiar łapie oczywiste obcięcie; równy skrót kryptograficzny to silniejsza kontrola na poziomie bajtów.

Uwzględniona jest tylko reprezentacja przesłanego pliku. Podsumowanie nie może zweryfikować reguł udostępniania, komentarzy, wersji, etykiet, skrótów, ustawień przechowywania ani sposobu renderowania wyeksportowanego dokumentu Google dla użytkownika. To pozostają zadania akceptacyjne.

Usunięcie źródła celowo wykracza poza normalną ścieżkę sukcesu

Najbezpieczniejszym ustawieniem domyślnym jest tylko kopiowanie, a opcja usuwania FileArk jest wyłączona, chyba że ją włączysz. Jeśli usuwanie jest wyłączone, w przypadku niepowodzenia weryfikacji nie można usunąć oryginału, ponieważ nigdy nie jest wymagane usunięcie.

Jeśli celowo włączysz funkcję usuwania po przeniesieniu, proces roboczy nadal czeka na identyfikator miejsca docelowego, rozmiar i weryfikację SHA-256 przed wywołaniem operacji usuwania dostawcy źródłowego. W przypadku niezastąpionych lub bardzo dużych bibliotek w dalszym ciągu lepszym wyborem operacyjnym jest wyłączenie tej opcji i stosowanie zatwierdzonego przez człowieka okresu nakładania się.

Odpowiedzi dotyczące migracji „czy dotarła zweryfikowana kopia?” Retencja odpowiada na pytanie: „kiedy można usunąć starą kopię?” Traktuj je jako odrębne decyzje z odrębnymi dowodami.

Ten sam model sterowania działa w obie strony

W przypadku usługi OneDrive na Dysku Google ładunek źródłowy jest odczytywany z Microsoft Graph, a obiekt docelowy jest weryfikowany na Dysku Google na podstawie zwróconego identyfikatora. W przypadku Dysku Google do OneDrive źródło jest pobierane lub eksportowane za pośrednictwem Dysku Google, a nowy element OneDrive jest odczytywany z powrotem za pomocą Microsoft Graph.

Kolejka, stany bazy danych, ograniczone próby, wstępna inspekcja pojemności, skrót źródłowy, identyfikator miejsca docelowego, skrót miejsca docelowego i kolejność potwierdzeń są neutralne pod względem kierunku. Adaptery dostawców obsługują różne interfejsy API przesyłania, folderów i zawartości.

Asymetria to semantyka treści. Dokumenty natywne Google wymagają eksportu, a obie platformy udostępniają i zachowują wersję w zależności od usługi. Zawartość pliku zweryfikowana pod kątem bajtów nie powinna być sprzedawana jako kompletny klon każdej funkcji współpracy.

Użyj czteroczęściowego planu akceptacji

1. Uzgodnij rekord systemowy

   Liczniki zakończone, oczekujące, w toku i zakończone niepowodzeniem. Nie należy odrzucać żadnego nieudanego elementu, ponieważ ogólny odsetek jest wysoki.

2. Próbka według ryzyka

   Otwórz pliki, których utrata byłaby najbardziej bolesna, a także duże multimedia, archiwa, stare dokumenty, nazwy inne niż angielskie, zagnieżdżone ścieżki i przekonwertowane pliki natywne w chmurze.

3. Sprawdź zachowanie miejsca docelowego

   Testuj dostęp z rzeczywistych urządzeń i użytkowników. Odbuduj wymagane udostępnianie i potwierdź, że pliki pakietu Office lub wyeksportowane pliki Google otwierają się zgodnie z oczekiwaniami.

4. Przytrzymaj okres nakładania się

   Zapewnij dostępność i stabilność źródła podczas normalnego użytkowania w miejscu docelowym. Podejmij decyzję o anulowaniu lub usunięciu później.

Najczęściej zadawane pytania

Czy FileArk używa kolejki dla każdego pliku?

Tak. Skaner tworzy lub ponownie wykorzystuje rekord bazy danych dla każdego pliku źródłowego i publikuje trwały komunikat o migracji. Pracownicy pobierają te wiadomości z ręcznym potwierdzeniem.

Kiedy wiadomość w kolejce jest potwierdzana?

Po zweryfikowaniu identyfikatora obiektu docelowego, rozmiaru i SHA-256 oraz utrwaleniu stanu Uploaded i VerifiedAt. Niedokończone dostawy można ponownie dostarczyć.

Czy zakończone zapisy akt są usuwane z bazy danych?

Nie. Zakończenie oznacza zmianę stanu w trwałym zapisie. W wierszu znajdują się informacje o tożsamości miejsca docelowego, dowodach weryfikacji, czasie i próbach na potrzeby postępu i audytu.

Czy SHA-256 może udowodnić przeniesienie uprawnień i wersji?

Nie. To dowodzi, że bajty pliku docelowego odpowiadają przesłanemu ładunkowi źródłowemu. Udostępnianie, uprawnienia, wersje, komentarze, etykiety, skróty i zachowanie natywne dostawcy wymagają osobnej weryfikacji.

Czy usługa OneDrive na Dysk Google jest weryfikowana w ten sam sposób, jak w odwrotnej kolejności?

Podstawowa zasada jest taka sama w obu kierunkach: podsumowanie ładunku źródłowego, tożsamość obiektu docelowego, rozmiar docelowy, podsumowanie ponownego pobrania dokładnego obiektu, trwała weryfikacja, a następnie potwierdzenie w kolejce.

Oficjalne źródła wykorzystane w tym poradniku

• Centrum edukacyjne Google Workspace: przejście z OneDrive na Google Drive
• Pomoc Google Drive: miejsce na dane i obsługa plików
• Pomoc techniczna Microsoft: przekazywanie i zapisywanie plików w OneDrive
• RabbitMQ: podziękowania od konsumentów i potwierdzenie wydawcy
• RabbitMQ: bezpieczeństwo i niezawodność danych
• Google Drive API: wznawialne przesyłanie
• Microsoft Graph: utwórz sesję przesyłania