Přesouvání stovek GB mezi mraky: Jak víte, že každý soubor dorazil?

Stručná odpověď

FileArk rozděluje knihovnu na záznamy po jednotlivých souborech a trvalé zprávy ve frontě. Pracovník zkopíruje jednu dodávku, uloží vrácené cílové ID, ověří velikost, přečte zpět přesně tento objekt a porovná SHA-256 se zdrojovým datovým zatížením. Záznam se ověří – a zpráva se potvrdí – až po úspěšné kontrole a aktualizaci databáze.

Proč měřítko mění význam slova „pracoval“

Deset souborů lze snadno zkontrolovat. Deset tisíc souborů není. Velká osobní knihovna může kombinovat drobné dokumenty, multigigabajtová videa, prázdné soubory, vnořené složky, názvy Unicode, archivované projekty a cloudové nativní formáty. Jedno selhání se může skrývat v působivě vypadajícím procentu.

Součty jsou užitečné, ale neúplné. Dvě knihovny mohou vykazovat stejnou zdánlivou velikost, zatímco v jedné chybí objekt nebo obsahuje zkrácený objekt vyvážený nějakým nesouvisejícím souborem. Počty souborů se také mohou lišit po exportu nativního dokumentu nebo vyloučených objektech poskytovatele.

Užitečnou jednotkou pravdy je souborová úloha: který zdrojový objekt byl přečten, který cílový objekt byl vytvořen, jaké bajty byly porovnány, kdy bylo ověření dokončeno a zda nějaký pokus zůstal nevyřešen.

Celý životní cyklus FileArk, anotovaný

Když je Start přijat, API nejprve zapíše úlohu skenování do MongoDB a poté publikuje trvalou zprávu skenování do trvalé fronty RabbitMQ s povoleným potvrzením vydavatele. Pokud se publikování nezdaří, úloha je označena jako Neúspěšná a rozhraní API hlásí, že nemohla bezpečně zařadit skenování do fronty.

Skener ověří oba poskytovatele, provede inventarizaci vybraného zdroje, zkontroluje konečnou cílovou kvótu proti zjištěným bajtům a pro každý zdrojový soubor vloží záznam do databáze. Publikuje zprávy o trvalé migraci a označí kontrolu za dokončenou až po úspěšném publikování.

Pracovník migrace používá ruční potvrzení a počet přednačtení jeden. Doručení zůstává nepotvrzeno, dokud je obsah přečten, nahrán, znovu přečten, ověřen a uložen. Zastavené připojení nebo proces tedy může vrátit nedokončenou práci do fronty.

Řádek databáze je položka kontrolního seznamu, nikoli účetnictví na jedno použití

Každý záznam souboru začíná Nevyřízeno, během pokusu se přesune do InProgress a dosáhne Nahráno až po ověření. Počet pokusů, čas posledního pokusu, podrobnosti o chybě, ID cílového objektu, souhrny SHA-256, metoda ověření a VerifiedAt zůstávají připojeny k záznamu.

Dokončené záznamy zůstávají v databázi jako průběh a auditní záznam. „Přeškrtnutí spisu“ znamená řízenou změnu stavu, nikoli vymazání důkazů. Duplicitní doručování ve frontě zkontroluje tento stav a okamžitě potvrdí záznam již označený Nahráno pomocí VerifiedAt.

Po třech neúspěšných pokusech se trvalý problém stane neúspěšným s časovým razítkem dokončení cyklu pokusů. Tím se zviditelní výjimky a zabrání se věčnému otáčení jedové zprávy, zatímco se řídicí panel jeví jako zaseknutý.

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

Proč může být soubor doručen více než jednou

Spolehlivé fronty obecně poskytují doručení alespoň jednou, nikoli magický příslib přesně jednou přes cloudové API, zprostředkovatele zpráv a databázi. K selhání může dojít poté, co OneDrive nebo Disk Google přijme nahrávání, ale předtím, než pracovník zapíše dokončení.

FileArk tuto nejistotu řeší pomocí idempotentních záznamů a obnovy cíle. Pracovník nejprve zkontroluje, zda je záznam již ověřen. Pokud ne, může použít uložené cílové ID nebo vyhledat očekávanou cílovou cestu a přesnou velikost pro přerušený výsledek, než se rozhodne znovu nahrát.

Kandidáti na obnovu jsou poté podrobeni stejnému ověření hash přesného objektu. Najít známý název souboru nestačí. Jde o to, přeměnit přerušený pokus zpět v důkaz, ne v optimistický úspěch.

Kapacita se kontroluje v místě určení a u pracovníka

Před publikováním úloh pro jednotlivé soubory skener sečte velikosti nezáporných zdrojových metadat a porovná požadavek s nahlášeným zbývajícím úložištěm cíle, kdykoli poskytovatel poskytne konečnou kvótu. Poddimenzovaný cíl selže při skenování místo toho, aby se práce přesunula do známé slepé uličky.

Obrázek je předběžná kontrola, nikoli záruka: aktivita účtu může během běhu spotřebovávat místo, zprávy o kvótách poskytovatelů se mohou zpožďovat a exportované cloudové nativní soubory nemusí mít konvenční velikost zdroje. Vynucení poskytovatele a zpracování chyb jednotlivých souborů zůstávají aktivní.

Disk vašeho počítače se nepoužívá pro přípravu. Na migračním workeru jsou soubory nad prahovou hodnotou paměti umístěny do izolovaného dočasného adresáře až poté, co má svazek místo pro očekávaný objekt plus rezervu dvou gigabajtů. Dočasný obsah je při čištění odstraněn bez ohledu na to, zda je pokus úspěšný nebo hází.

Proč je důležité ID cíle plus SHA-256

Název souboru není jedinečná identita. Cíl již může obsahovat dva soubory se stejným viditelným názvem nebo může chvíli trvat, než se usadí seznam metadat. Odpověď na nahrání poskytuje ID objektu poskytovatele a FileArk toto ID uloží před závěrečnou fází ověření.

Pracovník vypočítá SHA-256 ve zdrojovém datovém toku dat, nahraje jej, poté otevře přesný cílový objekt podle tohoto ID a znovu vypočítá SHA-256. Stejná velikost zachytí zjevné zkrácení; stejný kryptografický výtah je silnější kontrola na úrovni bajtů.

Pokryta je pouze reprezentace přeneseného souboru. Přehled nemůže ověřit pravidla sdílení, komentáře, verze, štítky, zkratky, nastavení uchovávání ani to, jak se uživateli vykresluje exportovaný dokument Google. To zůstávají akceptační úkoly.

Odstranění zdroje je záměrně mimo normální cestu úspěchu

Nejbezpečnější výchozí nastavení je pouze kopírování a možnost smazání FileArk je vypnutá, pokud ji nepovolíte. Pokud je smazání zakázáno, selhání ověření nemůže odstranit originál, protože smazání není nikdy požadováno.

Pokud záměrně povolíte odstranění po přesunutí, pracovník stále čeká na cílové ID, velikost a ověření SHA-256, než zavolá operaci odstranění zdrojového poskytovatele. Silnější provozní volbou pro nenahraditelné nebo velmi velké knihovny je stále ponechat tuto možnost vypnutou a používat období překrytí schválené lidmi.

Migrace odpovídá „dorazila ověřená kopie?“ Retence odpovídá „kdy může být stará kopie odstraněna?“ Zacházejte s nimi jako se samostatnými rozhodnutími se samostatnými důkazy.

V obou směrech funguje stejný model ovládání

U OneDrive na Disk Google se zdrojová datová část načte z Microsoft Graph a cílový objekt se ověří prostřednictvím Disku Google podle jeho vráceného ID. V případě Disku Google do OneDrive se zdroj stáhne nebo exportuje prostřednictvím Disku Google a nová položka OneDrive se načte zpět prostřednictvím aplikace Microsoft Graph.

Fronta, stavy databáze, omezené pokusy, kontrola před výstupem, zdrojový výtah, ID cíle, přehled cíle a pořadí potvrzení jsou směrově neutrální. Adaptéry poskytovatelů zpracovávají různá rozhraní API pro nahrávání, složky a obsah.

Asymetrií je obsahová sémantika. Nativní dokumenty Google potřebují export a obě platformy mají sdílení a verzi specifické pro službu. Obsah souboru ověřený bajty by neměl být nabízen jako úplný klon každé funkce spolupráce.

Použijte čtyřdílný akceptační plán

1. Odsouhlaste systémový záznam

   Počítání dokončené, nevyřízené, probíhající a neúspěšné. Žádná neúspěšná položka by neměla být odvolána, protože celkové procento je vysoké.

2. Vzorek podle rizika

   Otevřete soubory, které by nejvíce bolelo ztráta, plus velká média, archivy, staré dokumenty, neanglické názvy, vnořené cesty a převedené cloudové nativní soubory.

3. Ověřte chování cíle

   Otestujte přístup ze skutečných zařízení a uživatelů. Znovu vytvořte požadované sdílení a potvrďte, že se soubory Office nebo exportované soubory Google otevírají podle očekávání.

4. Držte období překrytí

   Udržujte zdroj dostupný a stabilní, zatímco běžné používání využívá cíl. Jakékoli rozhodnutí o zrušení nebo smazání udělejte později.

Časté dotazy

Používá FileArk frontu pro každý soubor?

Ano. Skener vytvoří nebo znovu použije záznam databáze pro každý zdrojový soubor a publikuje zprávu o trvalé migraci. Pracovníci vytáhnou tyto zprávy s ručním potvrzením.

Kdy je potvrzena zpráva ve frontě?

Po ověření ID cílového objektu, velikosti a SHA-256 a přetrvání stavu Nahráno a VerifiedAt. Nedokončené dodávky mohou být znovu doručeny.

Jsou dokončené záznamy souborů odstraněny z databáze?

Ne. Dokončení je přechod stavu na trvalém záznamu. Řádek uchovává identitu cíle, důkazy o ověření, načasování a informace o pokusech pro průběh a audit.

Může SHA-256 prokázat oprávnění a přesunuté verze?

Ne. Dokazuje to, že bajty cílového souboru odpovídají přenesené zdrojové užitečné zátěži. Sdílení, oprávnění, verze, komentáře, štítky, zkratky a nativní chování poskytovatele vyžadují samostatné ověření.

Ověřuje se OneDrive na Disk Google stejným způsobem jako naopak?

Základní pravidlo je stejné v obou směrech: přehled zdrojové užitečné zátěže, identita cílového objektu, velikost cíle, přehled opětovného stažení přesného objektu, trvalé ověření a poté potvrzení fronty.

Oficiální zdroje použité v tomto průvodci

• Výukové centrum Google Workspace: přechod z OneDrive na Google Drive
• Nápověda Google Drive: úložiště a chování souborů
• Podpora Microsoftu: nahrávání a ukládání souborů na OneDrive
• RabbitMQ: spotřebitelské poděkování a vydavatel potvrzuje
• RabbitMQ: bezpečnost a spolehlivost dat
• Google Drive API: obnovitelná nahrávání
• Microsoft Graph: vytvořte relaci nahrávání