Large migrations · Verification · Dovada din spatele barei de progres

Mutarea a sute de GB între nori: de unde știi că fiecare fișier a sosit?

La 500 GB, „încărcarea părea terminată” nu este o dovadă. O migrare de încredere necesită un inventar durabil, o tranziție de stare pentru fiecare obiect, recuperare repetabilă după întreruperi și dovezi de la destinație în sine.

Actualizat ; 16 min de lectură.

Pe scurt

FileArk descompune biblioteca în înregistrări per fișier și mesaje durabile în coadă. Un lucrător copiază o livrare, stochează ID-ul de destinație returnat, validează dimensiunea, citește exact acel obiect înapoi și compară SHA-256 cu sarcina utilă sursă. Înregistrarea devine verificată – iar mesajul este confirmat – numai după ce aceste verificări și actualizarea bazei de date reușesc.

De ce scara schimbă sensul cuvântului „lucrat”

Zece fișiere sunt ușor de inspectat. Zece mii de fișiere nu sunt. O bibliotecă personală mare poate combina documente minuscule, videoclipuri de mai mulți gigabyte, fișiere goale, foldere imbricate, nume Unicode, proiecte arhivate și formate native din cloud. Un eșec se poate ascunde în interiorul unui procent impresionant.

Totalurile sunt utile, dar incomplete. Două biblioteci pot afișa aceeași dimensiune aparentă în timp ce una îi lipsește un obiect sau conține un obiect trunchiat echilibrat de un fișier care nu are legătură. Numărul de fișiere poate diferi și după exportul documentelor native sau obiectele furnizorului excluse.

Unitatea utilă a adevărului este munca de fișier: ce obiect sursă a fost citit, ce obiect destinație a fost creat, ce octeți au fost comparați, când s-a încheiat verificarea și dacă vreo încercare rămâne nerezolvată.

Ciclul de viață complet al FileArk, adnotat

Ciclul de viață adnotat care arată baza de date a scanerului de configurare a browserului FileArk lucrător durabil la coadă și verificarea SHA-256
Browserul pornește fluxul de control; scanerul, coada persistentă, baza de date și lucrătorul transportă migrarea de lungă durată.

Când Start este acceptat, API-ul scrie mai întâi o lucrare de scanare în MongoDB și apoi publică un mesaj de scanare persistentă într-o coadă RabbitMQ durabilă cu confirmarea editorului activată. Dacă publicarea eșuează, lucrarea este marcată Eșuată și API-ul raportează că nu a putut pune în așteptare scanarea în siguranță.

Scanerul autentifică ambii furnizori, inventariază sursa selectată, verifică cota de destinație finită față de octeții descoperiți și ridică o înregistrare a bazei de date pentru fiecare fișier sursă. Publică mesaje persistente de migrare și marchează scanarea finalizată numai după ce aceste publicări reușesc.

Lucrătorul de migrare folosește confirmări manuale și un număr de preluare de unu. O livrare rămâne neconfirmată în timp ce conținutul este citit, încărcat, recitit, verificat și persistat. Prin urmare, o conexiune sau un proces oprit poate returna lucrările neterminate în coadă.

Un rând de bază de date este un element din lista de verificare, nu o evidență de unică folosință

Fiecare înregistrare de fișier începe În așteptare, trece la InProgress în timpul unei încercări și ajunge la Încărcat numai după verificare. Numărul încercărilor, timpul ultimei încercări, detaliile erorii, ID-ul obiectului destinație, ambele rezumate SHA-256, metoda de verificare și VerifiedAt rămân atașate înregistrării.

Înregistrările finalizate rămân în baza de date ca progres și urmărire de audit. „Închiderea unui fișier” înseamnă o schimbare controlată a stării, fără ștergerea dovezilor. Livrările duplicate în coadă inspectează starea respectivă și confirmă imediat o înregistrare deja marcată Încărcat cu VerifiedAt.

După trei încercări nereușite, o problemă persistentă devine Eșuată cu un marcaj temporal de finalizare pentru ciclul de încercare. Acest lucru face excepțiile vizibile și împiedică un mesaj otrăvitor să se rotească pentru totdeauna în timp ce tabloul de bord pare blocat.

Poarta de finalizare pentru un dosar
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

De ce un fișier poate fi livrat de mai multe ori

Cozile de încredere asigură, în general, livrarea cel puțin o dată, nu o promisiune magică exact o dată printr-un API cloud, un broker de mesaje și o bază de date. Se poate produce o blocare după ce OneDrive sau Google Drive acceptă o încărcare, dar înainte ca lucrătorul să scrie finalizarea.

FileArk gestionează această incertitudine cu înregistrări idempotente și recuperarea destinației. Lucrătorul verifică mai întâi dacă înregistrarea este deja verificată. Dacă nu, poate utiliza ID-ul destinației stocat sau poate căuta calea de destinație așteptată și dimensiunea exactă pentru rezultatul întrerupt înainte de a decide să încarce din nou.

Candidații de recuperare sunt apoi supuși aceleiași verificări hash exact-obiect. Găsirea unui nume de fișier familiar nu este suficientă. Ideea este să transformi o încercare întreruptă înapoi în dovezi, nu într-un succes optimist.

Capacitatea se verifică la destinație și pe lucrător

Înainte ca lucrările pe fișier să fie publicate, scanerul totalizează dimensiunile metadatelor sursei nenegative și compară cerințele cu spațiul de stocare rămas raportat al destinației ori de câte ori furnizorul furnizează o cotă limitată. O destinație subdimensionată nu reușește scanarea în loc să alimenteze lucrările într-o fundătură cunoscută.

Cifra este o verificare preliminară, nu o garanție: activitatea contului poate consuma spațiu în timpul unei rulări, rapoartele privind cotele furnizorului pot rămâne în întârziere și fișierele exportate native din cloud pot să nu aibă o dimensiune convențională a sursei. Aplicarea furnizorului și gestionarea erorilor pe fișier rămân active.

Discul computerului nu este folosit pentru punere în scenă. Pe lucrătorul de migrare, fișierele peste pragul de memorie sunt plasate într-un director temporar izolat numai după ce volumul are spațiu pentru obiectul așteptat plus o rezervă de doi gigabyte. Conținutul temporar este eliminat în timpul curățării, indiferent dacă încercarea reușește sau aruncă.

De ce contează ID-ul destinației plus SHA-256

Un nume de fișier nu este o identitate unică. Este posibil ca destinația să conțină deja două fișiere cu același nume vizibil sau stabilirea listei cu metadate poate dura timp. Răspunsul de încărcare oferă un ID de obiect al furnizorului, iar FileArk stochează acel ID înainte de etapa finală de verificare.

Lucrătorul calculează SHA-256 în fluxul de încărcare utilă sursă, îl încarcă, apoi deschide obiectul destinație exact după acel ID și calculează din nou SHA-256. Mărimea egală prinde trunchierea evidentă; rezumatul criptografic egal este verificarea mai puternică la nivel de octeți.

Numai reprezentarea fișierului transferat este acoperită. Un rezumat nu poate valida regulile de partajare, comentariile, versiunile, etichetele, comenzile rapide, setările de păstrare sau modul în care un document Google exportat este redat pentru un utilizator. Acestea rămân sarcini de acceptare.

Ștergerea sursei este în mod intenționat în afara căii normale de succes

Cea mai sigură variantă implicită este doar pentru copiere, iar opțiunea de ștergere a FileArk este dezactivată dacă nu o activați. Cu ștergerea dezactivată, un eșec de verificare nu poate elimina originalul, deoarece ștergerea nu este niciodată solicitată.

Dacă activați în mod deliberat ștergerea după mutare, lucrătorul încă așteaptă ID-ul destinației, dimensiunea și validarea SHA-256 înainte de a apela operația de ștergere a furnizorului sursă. Alegerea operațională mai puternică pentru bibliotecile de neînlocuit sau foarte mari este să păstrați opțiunea dezactivată și să folosiți o perioadă de suprapunere aprobată de om.

Migrația răspunde „a sosit o copie verificată?” Reținerea răspunde „când poate fi eliminată copia veche?” Tratează-le ca decizii separate cu dovezi separate.

Același model de control funcționează în ambele direcții

Pentru OneDrive la Google Drive, sarcina utilă sursă este citită din Microsoft Graph și obiectul destinație este verificat prin Google Drive prin ID-ul returnat. Pentru Google Drive în OneDrive, sursa este descărcată sau exportată prin Google Drive și noul element OneDrive este citit înapoi prin Microsoft Graph.

Coada, stările bazei de date, încercările delimitate, verificarea prealabilă a capacității, rezumatul sursă, ID-ul destinației, rezumatul destinației și ordinea de confirmare sunt neutre din punct de vedere al direcției. Adaptoarele furnizorului gestionează diferitele API-uri de încărcare, foldere și conținut.

Asimetria este semantica conținutului. Documentele native Google trebuie exportate, iar ambele platforme au un comportament de partajare și versiune specifică serviciului. Conținutul fișierului verificat pe octeți nu ar trebui să fie comercializat ca o clonă completă a fiecărei caracteristici de colaborare.

Utilizați un plan de acceptare din patru părți

  1. Reconciliați înregistrarea sistemului __FILERK_0015__ Capacitatea se verifică la destinație și pe lucrător __FILERK_0016__ Este OneDrive pe Google Drive verificat în același mod ca și invers? __FILERK_0017__ La 500 GB, „încărcarea părea terminată” nu este o dovadă. O migrare de încredere necesită un inventar durabil, o tranziție de stare pentru fiecare obiect, recuperare repetabilă după întreruperi și dovezi de la destinație în sine. __FILERK_0018__ coadă mare de migrare în cloud __FILERK_0019__ Lucrătorul de migrare folosește confirmări manuale și un număr de preluare de unu. O livrare rămâne neconfirmată în timp ce conținutul este citit, încărcat, recitit, verificat și persistat. Prin urmare, o conexiune sau un proces oprit poate returna lucrările neterminate în coadă.

    Numărări de examinare finalizată, în așteptare, în curs și nereușite. Niciun articol eșuat nu trebuie eliminat deoarece procentul total este mare.

  2. Eșantion după risc

    Deschideți fișierele care ar răni cel mai mult de pierdut, plus medii mari, arhive, documente vechi, nume non-engleze, căi imbricate și fișiere convertite native din cloud.

  3. Validați comportamentul destinației

    Testați accesul de pe dispozitive și utilizatori reali. Reconstruiți partajarea necesară și confirmați că fișierele Office sau Google exportate se deschid conform așteptărilor.

  4. Țineți o perioadă de suprapunere

    Păstrați sursa disponibilă și stabilă în timp ce utilizarea normală exercită destinația. Luați orice decizie de anulare sau ștergere mai târziu.

Întrebări frecvente

FileArk folosește o coadă pentru fiecare fișier?

Da. Scanerul creează sau reutiliza o înregistrare a bazei de date pentru fiecare fișier sursă și publică un mesaj de migrare persistent. Lucrătorii retrag acele mesaje cu confirmare manuală.

Când este confirmat un mesaj în coadă?

După ce ID-ul obiectului destinație, dimensiunea și SHA-256 au fost verificate și starea Încărcat și VerifiedAt a fost menținută. Livrările neterminate pot fi relivrate.

Înregistrările fișierelor finalizate sunt șterse din baza de date?

Nu. Finalizarea este o tranziție de stat pe evidența durabilă. Rândul păstrează identitatea destinației, dovezile de verificare, calendarul și informațiile despre încercare pentru progres și audit.

Poate SHA-256 să dovedească permisiunile și versiunile mutate?

Nu. Demonstrează că octeții fișierului destinație se potrivesc cu sarcina utilă sursă transferată. Partajarea, permisiunile, versiunile, comentariile, etichetele, comenzile rapide și comportamentul nativ al furnizorului necesită validare separată.

Este OneDrive pe Google Drive verificat în același mod ca și invers?

Regula de bază este aceeași în ambele direcții: rezumatul sarcinii utile sursă, identitatea obiectului destinație, dimensiunea destinației, rezumatul re-descărcării obiectului exact, verificarea persistentă, apoi confirmarea cozii.

Resurse oficiale folosite pentru acest ghid

Citește ghidul