Large migrations · Verification · Het bewijs achter de voortgangsbalk

Honderden GB tussen clouds verplaatsen: hoe weet u of elk bestand is aangekomen?

Bij 500 GB is “de upload leek voltooid” geen bewijs. Voor een betrouwbare migratie is een duurzame inventarisatie nodig, een statusovergang voor elk object, herhaalbaar herstel na onderbrekingen en bewijs van de bestemming zelf.

Bijgewerkt ; 16 minuten leestijd.

Kort antwoord

FileArk verdeelt de bibliotheek in records per bestand en duurzame wachtrijberichten. Een medewerker kopieert één levering, slaat de geretourneerde bestemmings-ID op, valideert de grootte, leest dat exacte object terug en vergelijkt SHA-256 met de bronpayload. Het record wordt pas geverifieerd (en het bericht wordt bevestigd) nadat deze controles en de database-update zijn geslaagd.

Waarom schaal de betekenis van ‘werkte’ verandert

Tien dossiers zijn eenvoudig in te zien. Tienduizend bestanden zijn dat niet. Een grote persoonlijke bibliotheek kan kleine documenten, video's van meerdere gigabytes, lege bestanden, geneste mappen, Unicode-namen, gearchiveerde projecten en cloud-native formaten combineren. Eén mislukking kan zich schuilhouden in een indrukwekkend ogend percentage.

Totalen zijn nuttig maar onvolledig. Twee bibliotheken kunnen dezelfde schijnbare grootte weergeven, terwijl de ene een object mist of een afgeknot object bevat, in evenwicht gehouden door een niet-gerelateerd bestand. Het aantal bestanden kan ook verschillen na het exporteren van oorspronkelijke documenten of uitgesloten providerobjecten.

De bruikbare waarheidseenheid is de bestandstaak: welk bronobject is gelezen, welk bestemmingsobject is gemaakt, welke bytes zijn vergeleken, wanneer de verificatie is voltooid en of er nog een poging onopgelost is.

De volledige FileArk-levenscyclus, geannoteerd

Geannoteerde levenscyclus met FileArk-browserinstellingen, scannerdatabase, duurzame wachtrijwerker en SHA-256-verificatie
De browser start de controlestroom; de scanner, de permanente wachtrij, de database en de werker dragen de langlopende migratie uit.

Wanneer Start wordt geaccepteerd, schrijft de API eerst een scantaak naar MongoDB en publiceert vervolgens een persistent scanbericht naar een duurzame RabbitMQ-wachtrij met uitgeversbevestiging ingeschakeld. Als het publiceren mislukt, wordt de taak gemarkeerd als Mislukt en meldt de API dat de scan niet veilig in de wachtrij kon worden geplaatst.

De scanner authenticeert beide providers, inventariseert de geselecteerde bron, vergelijkt het eindige bestemmingsquotum met de ontdekte bytes en voegt voor elk bronbestand een databaserecord toe. Het publiceert persistente migratieberichten en markeert de scan pas als voltooid nadat deze publicaties zijn geslaagd.

De migratiewerker gebruikt handmatige bevestigingen en een vooraf ophaaltelling van één. Een levering blijft onbevestigd terwijl de inhoud wordt gelezen, geüpload, opnieuw gelezen, geverifieerd en bewaard. Een gestopte verbinding of proces kan daardoor onvoltooid werk terug in de wachtrij plaatsen.

Een databaserij is een checklistitem en geen wegwerpboekhouding

Elke bestandsrecord begint in behandeling, wordt tijdens een poging verplaatst naar InProgress en bereikt pas geüpload na verificatie. Aantal pogingen, tijd van laatste poging, foutdetails, bestemmingsobject-ID, zowel SHA-256-samenvattingen, verificatiemethode als VerifiedAt blijven aan de record gekoppeld.

Voltooide records blijven in de database als voortgangs- en audittrail. “Een bestand doorstrepen” betekent een gecontroleerde statusverandering, niet het verwijderen van het bewijsmateriaal. Dubbele wachtrijleveringen inspecteren die status en bevestigen onmiddellijk een record dat al is gemarkeerd als Geüpload met VerifiedAt.

Na drie mislukte pogingen wordt een aanhoudend probleem Mislukt, met een voltooiingstijdstempel voor de pogingscyclus. Dit maakt uitzonderingen zichtbaar en voorkomt dat een gifbericht voor altijd blijft ronddraaien terwijl het dashboard vast lijkt te zitten.

De voltooiingspoort voor één bestand
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

Waarom een bestand meerdere keren kan worden aangeleverd

Betrouwbare wachtrijen bieden over het algemeen een levering van minstens één keer, en niet een magische belofte van precies één keer via een cloud-API, een berichtenmakelaar en een database. Er kan een crash optreden nadat OneDrive of Google Drive een upload heeft geaccepteerd, maar voordat de medewerker voltooiing schrijft.

FileArk gaat met die onzekerheid om met idempotente records en bestemmingsherstel. De werknemer controleert eerst of het record al is geverifieerd. Als dit niet het geval is, kan het de opgeslagen bestemmings-ID gebruiken of het verwachte bestemmingspad en de exacte grootte doorzoeken op het onderbroken resultaat voordat wordt besloten opnieuw te uploaden.

Herstelkandidaten worden vervolgens onderworpen aan dezelfde hash-verificatie van het exacte object. Het vinden van een bekende bestandsnaam is niet voldoende. Het gaat erom een ​​onderbroken poging weer om te zetten in bewijs, en niet in een optimistisch succes.

De capaciteit wordt gecontroleerd op de bestemming en bij de werknemer

Voordat taken per bestand worden gepubliceerd, telt de scanner de niet-negatieve omvang van de bronmetagegevens op en vergelijkt de vereiste met de gerapporteerde resterende opslagruimte van de bestemming wanneer de provider een eindig quotum levert. Een te kleine bestemming voldoet niet aan de scan, in plaats van dat het werk op een doodlopende weg belandt.

Het cijfer is een preflight en geen garantie: accountactiviteit kan ruimte in beslag nemen tijdens een run, de quotarapporten van providers kunnen vertraging oplopen en geëxporteerde cloud-native bestanden hebben mogelijk geen conventionele brongrootte. Het afdwingen van providers en het afhandelen van fouten per bestand blijven actief.

Uw computerschijf wordt niet gebruikt voor staging. Op de migratiewerker worden bestanden boven de geheugendrempel pas in een geïsoleerde tijdelijke map geplaatst nadat het volume ruimte heeft voor het verwachte object plus een reserve van twee gigabyte. Tijdelijke inhoud wordt tijdens het opschonen verwijderd, ongeacht of de poging slaagt of mislukt.

Waarom bestemmings-ID plus SHA-256 belangrijk zijn

Een bestandsnaam is geen unieke identiteit. De bestemming bevat mogelijk al twee bestanden met dezelfde zichtbare naam, of het kan enige tijd duren voordat de vermelding van de metagegevens is verwerkt. Het uploadantwoord levert een providerobject-ID op, en FileArk slaat die ID op vóór de laatste verificatiefase.

De werknemer berekent SHA-256 voor de bronpayloadstroom, uploadt deze, opent vervolgens het exacte doelobject met die ID en berekent SHA-256 opnieuw. Gelijke grootte vangt duidelijke afknotting op; gelijke cryptografische samenvatting is de sterkere controle op byteniveau.

Alleen de overgedragen bestandsweergave is gedekt. Een samenvatting kan geen regels voor delen, opmerkingen, versies, labels, snelkoppelingen, bewaarinstellingen of hoe een geëxporteerd Google-document voor een gebruiker wordt weergegeven, valideren. Dat blijven acceptatietaken.

Het verwijderen van de bron valt opzettelijk buiten het normale succespad

De veiligste standaard is alleen kopiëren en de verwijderoptie van FileArk is uitgeschakeld tenzij u deze inschakelt. Als verwijderen is uitgeschakeld, kan een verificatiefout het origineel niet verwijderen, omdat er nooit om verwijdering is verzocht.

Als u opzettelijk verwijderen na verplaatsing inschakelt, wacht de werknemer nog steeds op validatie van de bestemmings-ID, grootte en SHA-256 voordat hij de verwijderbewerking van de bronprovider aanroept. De sterkere operationele keuze voor onvervangbare of zeer grote bibliotheken is nog steeds om de optie uit te schakelen en een door mensen goedgekeurde overlapperiode te gebruiken.

Migratieantwoorden: "Is er een geverifieerd exemplaar aangekomen?" Retentieantwoorden “wanneer mag de oude kopie worden verwijderd?” Behandel ze als afzonderlijke beslissingen met afzonderlijk bewijsmateriaal.

Hetzelfde controlemodel werkt in beide richtingen

Voor OneDrive naar Google Drive wordt de bronpayload gelezen uit Microsoft Graph en wordt het bestemmingsobject geverifieerd via Google Drive aan de hand van de geretourneerde ID. Voor Google Drive naar OneDrive wordt de bron gedownload of geëxporteerd via Google Drive en wordt het nieuwe OneDrive-item teruggelezen via Microsoft Graph.

De wachtrij, databasestatussen, begrensde pogingen, capaciteitspreflight, bronsamenvatting, bestemmings-ID, bestemmingssamenvatting en bevestigingsvolgorde zijn richtingsneutraal. Provideradapters verwerken de verschillende upload-, map- en inhoud-API's.

De asymmetrie is inhoudsemantiek. Google-native documenten moeten worden geëxporteerd en beide platforms hebben servicespecifiek deel- en versiegedrag. Byte-geverifieerde bestandsinhoud mag niet op de markt worden gebracht als een volledige kloon van elke samenwerkingsfunctie.

Gebruik een vierdelig acceptatieplan

  1. Stem het systeemrecord af

    Beoordeel voltooide, in behandeling zijnde, lopende en mislukte tellingen. Geen enkel mislukt item mag worden weggewuifd omdat het totale percentage hoog is.

  2. Steekproef op risico

    Open de bestanden die het meeste pijn zouden doen als ze verloren zouden gaan, plus grote media, archieven, oude documenten, niet-Engelse namen, geneste paden en geconverteerde cloud-native bestanden.

  3. Valideer het bestemmingsgedrag

    Test de toegang vanaf echte apparaten en gebruikers. Bouw het vereiste delen opnieuw op en bevestig dat Office- of geëxporteerde Google-bestanden openen zoals verwacht.

  4. Houd een overlapperiode aan

    Houd de bron beschikbaar en stabiel terwijl normaal gebruik de bestemming uitoefent. Neem later een besluit tot annulering of verwijdering.

Veelgestelde vragen

Gebruikt FileArk een wachtrij voor elk bestand?

Ja. De scanner maakt of hergebruikt per bronbestand een databaserecord en publiceert een persistent migratiebericht. Werknemers halen deze berichten op met handmatige bevestiging.

Wanneer wordt een wachtrijbericht bevestigd?

Nadat het doelobject-ID, de grootte en SHA-256 zijn geverifieerd en de status Uploaded en VerifiedAt behouden zijn gebleven. Onvoltooide leveringen kunnen opnieuw worden afgeleverd.

Worden voltooide dossierrecords uit de database verwijderd?

Nee. Voltooiing is een statusovergang op het duurzame record. De rij bewaart de bestemmingsidentiteit, verificatiebewijs, timing en pogingsinformatie voor voortgang en audit.

Kan SHA-256 bewijzen dat machtigingen en versies zijn verplaatst?

Nee. Het bewijst dat de bytes van het doelbestand overeenkomen met de overgedragen bronpayload. Delen, machtigingen, versies, opmerkingen, labels, snelkoppelingen en provider-native gedrag vereisen afzonderlijke validatie.

Wordt OneDrive naar Google Drive op dezelfde manier geverifieerd als andersom?

De kernregel is in beide richtingen hetzelfde: samenvatting van de bronpayload, de identiteit van het doelobject, de grootte van de bestemming, de samenvatting van het exacte object opnieuw downloaden, aanhoudende verificatie en vervolgens bevestiging van de wachtrij.

Officiële bronnen die voor deze handleiding zijn gebruikt

Handleiding lezen