Spostare centinaia di GB tra cloud: come fai a sapere che ogni file è arrivato?

In breve

FileArk suddivide la libreria in record per file e messaggi in coda durevoli. Un lavoratore copia una consegna, memorizza l'ID di destinazione restituito, convalida la dimensione, rilegge l'oggetto esatto e confronta SHA-256 con il payload di origine. Il record viene verificato e il messaggio viene riconosciuto solo dopo che tali controlli e l'aggiornamento del database hanno esito positivo.

Perché la scala cambia il significato di “lavorato”

Dieci file sono facili da ispezionare. Diecimila file non lo sono. Una grande libreria personale può combinare piccoli documenti, video multi-gigabyte, file vuoti, cartelle nidificate, nomi Unicode, progetti archiviati e formati nativi del cloud. Un fallimento può nascondersi all’interno di una percentuale dall’aspetto impressionante.

I totali sono utili ma incompleti. Due librerie possono mostrare la stessa dimensione apparente mentre in una manca un oggetto o contiene un oggetto troncato bilanciato da qualche file non correlato. I conteggi dei file possono variare anche dopo l'esportazione del documento nativo o dopo l'esclusione degli oggetti del provider.

L'unità di verità utile è il lavoro del file: quale oggetto di origine è stato letto, quale oggetto di destinazione è stato creato, quali byte sono stati confrontati, quando è stata completata la verifica e se qualche tentativo rimane irrisolto.

L'intero ciclo di vita di FileArk, annotato

Quando viene accettato l'avvio, l'API scrive prima un processo di scansione su MongoDB e quindi pubblica un messaggio di scansione persistente su una coda RabbitMQ durevole con la conferma dell'editore abilitata. Se la pubblicazione fallisce, il lavoro viene contrassegnato come Non riuscito e l'API segnala che non è possibile accodare in modo sicuro la scansione.

Lo scanner autentica entrambi i provider, inventaria la fonte selezionata, controlla la quota di destinazione finita rispetto ai byte rilevati e inserisce un record del database per ciascun file di origine. Pubblica messaggi di migrazione persistenti e contrassegna la scansione come completata solo dopo che tali pubblicazioni hanno esito positivo.

L'operatore di migrazione utilizza i riconoscimenti manuali e un conteggio di prelettura pari a uno. Una consegna rimane non confermata mentre il contenuto viene letto, caricato, riletto, verificato e reso persistente. Una connessione o un processo interrotto può quindi restituire alla coda il lavoro non completato.

Una riga del database è un elemento della lista di controllo, non una contabilità usa e getta

Ogni record di file inizia in sospeso, passa a In corso durante un tentativo e raggiunge Caricato solo dopo la verifica. Il conteggio dei tentativi, l'ora dell'ultimo tentativo, i dettagli dell'errore, l'ID dell'oggetto di destinazione, entrambi i digest SHA-256, il metodo di verifica e VerifiedAt rimangono allegati al record.

I record completati rimangono nel database come stato di avanzamento e traccia di controllo. “Cancellare un file” significa un cambiamento di stato controllato, non la cancellazione delle prove. Le consegne in coda duplicate controllano tale stato e riconoscono immediatamente un record già contrassegnato come Caricato con VerifiedAt.

Dopo tre tentativi non riusciti, un problema persistente diventa Non riuscito con un timestamp di completamento per il ciclo di tentativi. Ciò rende visibili le eccezioni e impedisce a un messaggio non elaborabile di girare all'infinito mentre il dashboard appare bloccato.

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

Perché un file può essere consegnato più di una volta

Le code affidabili generalmente forniscono la consegna almeno una volta, non una promessa magica esattamente una volta attraverso un'API cloud, un broker di messaggi e un database. Può verificarsi un arresto anomalo del sistema dopo che OneDrive o Google Drive accettano un caricamento ma prima che il lavoratore scriva il completamento.

FileArk gestisce questa incertezza con record idempotenti e ripristino della destinazione. Il lavoratore controlla innanzitutto se il record è già verificato. In caso contrario, può utilizzare l'ID di destinazione memorizzato o cercare il percorso di destinazione previsto e la dimensione esatta per il risultato interrotto prima di decidere di caricare nuovamente.

I candidati al ripristino vengono quindi sottoposti alla stessa verifica dell'hash dell'oggetto esatto. Trovare un nome file familiare non è sufficiente. Il punto è riconvertire un tentativo interrotto in una prova, non in un ottimistico successo.

La capacità viene controllata a destinazione e sul lavoratore

Prima che i lavori per file vengano pubblicati, lo scanner calcola il totale delle dimensioni dei metadati di origine non negativi e confronta i requisiti con lo spazio di archiviazione rimanente segnalato dalla destinazione ogni volta che il provider fornisce una quota finita. Una destinazione sottodimensionata non supera la scansione invece di inserire il lavoro in un vicolo cieco noto.

La cifra è una verifica preliminare, non una garanzia: l'attività dell'account può consumare spazio durante un'esecuzione, i report sulle quote del provider possono subire ritardi e i file nativi del cloud esportati potrebbero non avere una dimensione di origine convenzionale. L'applicazione del provider e la gestione degli errori per file rimangono attive.

Il disco del tuo computer non viene utilizzato per lo staging. Sul lavoratore di migrazione, i file al di sopra della soglia di memoria vengono inseriti in una directory temporanea isolata solo dopo che il volume ha spazio per l'oggetto previsto più una riserva di due gigabyte. Il contenuto temporaneo viene rimosso durante la pulizia indipendentemente dal fatto che il tentativo abbia esito positivo o negativo.

Perché l'ID di destinazione più SHA-256 è importante

Un nome file non è un'identità univoca. La destinazione potrebbe già contenere due file con lo stesso nome visibile oppure l'elenco dei metadati potrebbe richiedere del tempo per essere sistemato. La risposta al caricamento fornisce un ID oggetto del provider e FileArk memorizza tale ID prima della fase di verifica finale.

Il lavoratore calcola SHA-256 attraverso il flusso del payload di origine, lo carica, quindi apre l'oggetto di destinazione esatto in base a quell'ID e calcola nuovamente SHA-256. La dimensione uguale rileva il troncamento evidente; il digest crittografico uguale è il controllo a livello di byte più potente.

È coperta solo la rappresentazione del file trasferito. Un digest non può convalidare regole di condivisione, commenti, versioni, etichette, scorciatoie, impostazioni di conservazione o il modo in cui un documento Google esportato viene visualizzato per un utente. Quelli rimangono compiti di accettazione.

L'eliminazione dell'origine è intenzionalmente al di fuori del normale percorso di successo

L'impostazione predefinita più sicura è di sola copia e l'opzione di eliminazione di FileArk è disattivata a meno che non la abiliti. Con l'eliminazione disabilitata, un errore di verifica non può rimuovere l'originale perché l'eliminazione non viene mai richiesta.

Se abiliti deliberatamente l'eliminazione dopo lo spostamento, il lavoratore attende comunque la convalida dell'ID di destinazione, della dimensione e dello SHA-256 prima di chiamare l'operazione di eliminazione del provider di origine. La scelta operativa più forte per le biblioteche insostituibili o molto grandi è ancora quella di mantenere disattivata l’opzione e utilizzare un periodo di sovrapposizione approvato dall’uomo.

La migrazione risponde "è arrivata una copia verificata?" La conservazione risponde “quando potrà essere rimossa la vecchia copia?” Trattateli come decisioni separate con prove separate.

Lo stesso modello di controllo funziona in entrambe le direzioni

Per OneDrive su Google Drive, il payload di origine viene letto da Microsoft Graph e l'oggetto di destinazione viene verificato tramite Google Drive in base al relativo ID restituito. Per Google Drive su OneDrive, l'origine viene scaricata o esportata tramite Google Drive e il nuovo elemento OneDrive viene riletto tramite Microsoft Graph.

La coda, gli stati del database, i tentativi limitati, il preflight della capacità, il digest di origine, l'ID di destinazione, il digest di destinazione e l'ordine di riconoscimento sono indipendenti dalla direzione. Gli adattatori del provider gestiscono le diverse API di caricamento, cartella e contenuto.

L’asimmetria è la semantica del contenuto. I documenti nativi di Google devono essere esportati ed entrambe le piattaforme hanno una condivisione e un comportamento della versione specifici del servizio. Il contenuto dei file con verifica dei byte non deve essere commercializzato come un clone completo di ogni funzionalità di collaborazione.

Utilizzare un piano di accettazione in quattro parti

1. Riconciliare il record di sistema

   Revisione dei conteggi completati, in sospeso, in corso e non riusciti. Nessun elemento fallito dovrebbe essere scartato perché la percentuale complessiva è elevata.

2. Campione per rischio

   Apri i file che sarebbe più doloroso perdere, oltre a file multimediali di grandi dimensioni, archivi, vecchi documenti, nomi non inglesi, percorsi nidificati e file nativi del cloud convertiti.

3. Convalidare il comportamento della destinazione

   Testa l'accesso da dispositivi e utenti reali. Ricostruisci la condivisione richiesta e verifica che i file di Office o di Google esportati si aprano come previsto.

4. Tieni un periodo di sovrapposizione

   Mantenere la fonte disponibile e stabile mentre l'uso normale esercita la destinazione. Prendere qualsiasi decisione di cancellazione o cancellazione in un secondo momento.

Domande frequenti

FileArk utilizza una coda per ogni file?

Sì. Lo scanner crea o riutilizza un record di database per file di origine e pubblica un messaggio di migrazione persistente. I lavoratori estraggono questi messaggi con il riconoscimento manuale.

Quando viene riconosciuto un messaggio in coda?

Dopo che l'ID dell'oggetto di destinazione, le dimensioni e il codice SHA-256 sono stati verificati e lo stato Caricato e VerifiedAt è stato reso permanente. Le consegne non completate possono essere riconsegnate.

I record dei file completati vengono eliminati dal database?

No. Il completamento è una transizione di stato nel registro durevole. La riga conserva l'identità della destinazione, le prove di verifica, i tempi e le informazioni sui tentativi per l'avanzamento e l'audit.

SHA-256 può dimostrare che le autorizzazioni e le versioni sono state spostate?

No. Dimostra che i byte del file di destinazione corrispondono al payload di origine trasferito. La condivisione, le autorizzazioni, le versioni, i commenti, le etichette, le scorciatoie e il comportamento nativo del provider richiedono una convalida separata.

OneDrive per Google Drive viene verificato allo stesso modo del contrario?

La regola principale è la stessa in entrambe le direzioni: digest del payload di origine, identità dell'oggetto di destinazione, dimensione di destinazione, digest di nuovo download dell'oggetto esatto, verifica persistente, quindi riconoscimento della coda.

Risorse ufficiali utilizzate per questa guida

• Centro didattico di Google Workspace: passare da OneDrive a Google Drive
• Guida di Google Drive: spazio di archiviazione e comportamento dei file
• Supporto tecnico Microsoft: caricare e salvare file in OneDrive
• RabbitMQ: riconoscimenti da parte dei consumatori e conferme da parte dell'editore
• RabbitMQ: sicurezza e affidabilità dei dati
• API Google Drive: caricamenti ripristinabili
• Microsoft Graph: crea una sessione di caricamento