Large migrations · Verification · Beviset bakom förloppsindikatorn

Flytta hundratals GB mellan molnen: Hur vet du att varje fil kom?

Vid 500 GB är "uppladdningen såg klar" inget bevis. En pålitlig migrering kräver en hållbar inventering, en tillståndsövergång för varje objekt, repeterbar återställning efter avbrott och bevis från själva destinationen.

Uppdaterad ; 16 minuters läsning.

Kort svar

FileArk delar upp biblioteket i per-fil-poster och varaktiga kömeddelanden. En arbetare kopierar en leverans, lagrar det returnerade destinations-ID:t, validerar storlek, läser tillbaka det exakta objektet och jämför SHA-256 med källnyttolasten. Posten verifieras – och meddelandet bekräftas – först efter att dessa kontroller och databasuppdateringen har lyckats.

Varför skala ändrar innebörden av "arbetat"

Tio filer är lätta att inspektera. Det är inte tiotusen filer. Ett stort personligt bibliotek kan kombinera små dokument, multi-gigabyte videor, tomma filer, kapslade mappar, Unicode-namn, arkiverade projekt och molnbaserade format. Ett misslyckande kan gömma sig i en imponerande andel.

Summor är användbara men ofullständiga. Två bibliotek kan visa samma skenbara storlek medan ett saknar ett objekt eller innehåller ett trunkerat objekt balanserat av någon orelaterade fil. Filantal kan också skilja sig efter ursprunglig dokumentexport eller exkluderade leverantörsobjekt.

Den användbara sanningsenheten är filjobbet: vilket källobjekt som lästes, vilket destinationsobjekt skapades, vilka bytes som jämfördes, när verifieringen slutfördes och om något försök förblir olöst.

Hela FileArks livscykel, kommenterad

Kommenterad livscykel som visar FileArk webbläsarinställningar skannerdatabas hållbar köarbetare och SHA-256-verifiering
Webbläsaren startar kontrollflödet; skannern, beständig kö, databasen och arbetaren bär den långvariga migreringen.

När Start accepteras, skriver API:et först ett skanningsjobb till MongoDB och publicerar sedan ett beständigt skanningsmeddelande till en hållbar RabbitMQ-kö med utgivarbekräftelse aktiverad. Om publiceringen misslyckas markeras jobbet Misslyckat och API:et rapporterar att det inte kunde köa skanningen på ett säkert sätt.

Skannern autentiserar båda leverantörerna, inventerar den valda källan, kontrollerar den ändliga destinationskvoten mot upptäckta bytes och upphäver en databaspost för varje källfil. Den publicerar beständiga migreringsmeddelanden och markerar genomsökningen som slutförd först efter att dessa publiceringar har lyckats.

Migreringsarbetaren använder manuella bekräftelser och ett förhämtningsantal på en. En leverans förblir obekräftad medan innehåll läses, laddas upp, läses på nytt, verifieras och bevaras. En stoppad anslutning eller process kan därför returnera oavslutat arbete till kön.

En databasrad är en checklista, inte engångsbokföring

Varje filpost startar Väntande, flyttas till InProgress under ett försök och når Uppladdat först efter verifiering. Antal försök, senaste försökstid, feldetaljer, destinationsobjekt-ID, både SHA-256-sammandrag, verifieringsmetod och VerifiedAt förblir bifogade till posten.

Slutförda poster stannar i databasen som framsteg och revisionsspår. "Att korsa en fil" betyder en kontrollerad tillståndsändring, inte att ta bort bevisen. Dubblettköleveranser inspekterar det tillståndet och bekräftar omedelbart en post som redan är märkt Uppladdad med VerifiedAt.

Efter tre misslyckade försök blir ett ihållande problem Misslyckat med en slutförandetidsstämpel för försökscykeln. Detta gör undantag synliga och förhindrar att ett giftmeddelande snurrar för alltid medan instrumentbrädan verkar ha fastnat.

Kompletteringsporten för en fil
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

Varför en fil kan levereras mer än en gång

Pålitliga köer ger i allmänhet minst en gång leverans, inte ett magiskt exakt-engångslöfte över ett moln-API, en meddelandeförmedlare och en databas. En krasch kan inträffa efter att OneDrive eller Google Drive har accepterat en uppladdning men innan arbetaren skriver slutförande.

FileArk hanterar den osäkerheten med idempotenta poster och destinationsåterställning. Arbetaren kontrollerar först om posten redan är verifierad. Om inte, kan den använda det lagrade destinations-ID:t eller söka efter den förväntade destinationsvägen och den exakta storleken för det avbrutna resultatet innan det bestämmer sig för att ladda upp igen.

Återställningskandidater utsätts sedan för samma hashverifiering med exakt objekt. Det räcker inte att hitta ett bekant filnamn. Poängen är att omvandla ett avbrutet försök tillbaka till bevis, inte till en optimistisk framgång.

Kapaciteten kontrolleras på destinationen och på arbetaren

Innan jobb per fil publiceras summerar skannern icke-negativa källmetadatastorlekar och jämför kravet med destinationens rapporterade återstående lagring närhelst leverantören tillhandahåller en begränsad kvot. En underdimensionerad destination misslyckas med skanningen istället för att mata in arbete i en känd återvändsgränd.

Siffran är en preflight, inte en garanti: kontoaktivitet kan konsumera utrymme under en körning, leverantörskvotrapporter kan släpa och exporterade molnbaserade filer kanske inte har en konventionell källstorlek. Tillämpning av leverantörer och felhantering per fil förblir aktiva.

Din datordisk används inte för iscensättning. På migreringsarbetaren placeras filer över minneströskeln i en isolerad temporär katalog först efter att volymen har plats för det förväntade objektet plus en reserv på två gigabyte. Tillfälligt innehåll tas bort vid rensning oavsett om försöket lyckas eller kastas.

Varför destinations-ID plus SHA-256 är viktiga

Ett filnamn är inte en unik identitet. Destinationen kan redan innehålla två filer med samma synliga namn, eller så kan metadatalistan ta tid att lösa. Uppladdningssvaret tillhandahåller ett leverantörsobjekt-ID, och FileArk lagrar detta ID innan det slutliga verifieringsskedet.

Arbetaren beräknar SHA-256 över källnyttolastströmmen, laddar upp den, öppnar sedan det exakta målobjektet med det ID:t och beräknar SHA-256 igen. Lika storlek fångar uppenbar trunkering; lika kryptografisk sammanfattning är den starkare kontrollen på bytenivå.

Endast den överförda filrepresentationen täcks. En sammanfattning kan inte validera delningsregler, kommentarer, versioner, etiketter, genvägar, lagringsinställningar eller hur ett exporterat Google-dokument renderas för en användare. Dessa förblir acceptansuppgifter.

Källborttagning är avsiktligt utanför den normala framgångsvägen

Den säkraste standarden är endast kopiering, och FileArks raderingsalternativ är avstängt om du inte aktiverar det. Med borttagning inaktiverad kan ett verifieringsfel inte ta bort originalet eftersom radering aldrig begärs.

Om du medvetet aktiverar radering-efter-flyttning, väntar arbetaren fortfarande på destinations-ID, storlek och SHA-256-validering innan han anropar källleverantörens borttagningsåtgärd. Det starkare operativa valet för oersättliga eller mycket stora bibliotek är fortfarande att hålla alternativet avstängt och använda en mänskligt godkänd överlappningsperiod.

Migrationen svarar "kom en verifierad kopia?" Retention svarar "när kan den gamla kopian tas bort?" Behandla dem som separata beslut med separata bevis.

Samma styrmodell fungerar i båda riktningarna

För OneDrive till Google Drive läses källnyttolasten från Microsoft Graph och målobjektet verifieras via Google Drive av dess returnerade ID. För Google Drive till OneDrive laddas eller exporteras källan via Google Drive och det nya OneDrive-objektet läses tillbaka via Microsoft Graph.

Kön, databastillstånd, begränsningsförsök, kapacitetspreflight, källsammandrag, destinations-ID, destinationssammandrag och bekräftelseordning är riktningsneutrala. Provideradaptrar hanterar de olika uppladdnings-, mapp- och innehålls-API:erna.

Asymmetrin är innehållssemantik. Google-baserade dokument behöver exporteras, och båda plattformarna har tjänstespecifik delning och versionsbeteende. Byte-verifierat filinnehåll bör inte marknadsföras som en komplett klon av varje samarbetsfunktion.

Använd en acceptplan i fyra delar

  1. Stäm av systemposten

    Granskning slutförd, väntande, pågående och misslyckad räkning. Inget misslyckat objekt ska viftas bort eftersom den totala procentandelen är hög.

  2. Prov av risk

    Öppna de filer som skulle göra mest ont att förlora, plus stora media, arkiv, gamla dokument, icke-engelska namn, kapslade sökvägar och konverterade molnbaserade filer.

  3. Validera destinationsbeteende

    Testa åtkomst från riktiga enheter och användare. Återskapa nödvändig delning och bekräfta att Office- eller exporterade Google-filer öppnas som förväntat.

  4. Håll en överlappningsperiod

    Håll källan tillgänglig och stabil medan normal användning utövar destinationen. Beslut om avbokning eller radering senare.

Vanliga frågor

Använder FileArk en kö för varje fil?

Ja. Skannern skapar eller återanvänder en databaspost per källfil och publicerar ett beständigt migreringsmeddelande. Arbetarna drar dessa meddelanden med manuell bekräftelse.

När kvitteras ett kömeddelande?

Efter att målobjektets ID, storlek och SHA-256 har verifierats och tillståndet Uploaded and VerifiedAt har behållits. Oavslutade leveranser kan omlevereras.

Raderas färdiga filposter från databasen?

Nej. Slutförande är en tillståndsövergång på den varaktiga posten. Raden behåller destinationsidentitet, verifieringsbevis, timing och försöksinformation för framsteg och revision.

Kan SHA-256 bevisa att behörigheter och versioner har flyttats?

Nej. Det bevisar att destinationsfilbyten matchar den överförda källnyttolasten. Delning, behörigheter, versioner, kommentarer, etiketter, genvägar och leverantörsbaserat beteende behöver separat validering.

Verifieras OneDrive till Google Drive på samma sätt som det omvända?

Kärnregeln är densamma i båda riktningarna: källnyttolastsammandrag, destinationsobjektidentitet, destinationsstorlek, exakt-objekt åternedladdningssammanfattning, ihållande verifiering, sedan köbekräftelse.

Officiella resurser som använts för den här guiden

Läs guiden