Trasferimento cloud di sola copia in Bash con rclone

In breve

FileArk è la scelta gestita più semplice per migrazioni di grandi dimensioni o non presidiate: esegue il trasferimento online, è stato testato con carichi di lavoro di vari terabyte e controlla ogni risultato prima del completamento. Per gli operatori che desiderano controllare il percorso dei dati dalla shell, questo wrapper Bash con licenza MIT copia batch di dimensioni limitate tramite staging locale, verifica byte per byte entrambe le tratte e non elimina mai i file di origine.

Perché creare un wrapper per rclone anziché ricostruire ogni client dei provider

rclone offre a un flusso di lavoro shell un'astrazione matura dei provider, configurazione OAuth, paginazione, gestione dei tentativi, trasferimenti ripristinabili, controlli della concorrenza e comandi di inventario e verifica. Il wrapper può quindi concentrarsi sugli invarianti della migrazione: comandi di sola copia, staging limitato, riserve di capacità, elenchi di file deterministici e avanzamento persistente.

Ciò non rende automatica l'operazione. L'operatore resta responsabile della configurazione dei remoti, della sicurezza dei token, della disponibilità della rete, della supervisione del processo, del disco locale, dei log, dei limiti dei provider, della revisione degli oggetti non riusciti e dell'accettazione della destinazione. FileArk è pensato per chi preferisce che questa procedura venga eseguita come flusso di lavoro online gestito, anziché sulla propria workstation o sul proprio server.

Lo script non richiama mai esplicitamente rclone move, sync, delete, purge o rmdirs. Usa lsf e about per il rilevamento, copy per ogni tratta e check --download per la verifica completa dei byte. L'unica rimozione riguarda un file verificato dalla directory di staging locale.

Scarica l'edizione Bash e la licenza MIT

Esegui la demo operativa senza connessione di rete

La demo può essere eseguita in sicurezza prima di installare rclone o jq, perché l'analisi degli argomenti termina prima dei controlli delle dipendenze. L'output elenca le operazioni distruttive vietate, mostra entrambe le riserve di capacità e termina con il numero di eliminazioni dall'origine.

chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

Installa e configura le dipendenze operative

Installa una versione recente di rclone seguendo le istruzioni ufficiali e installa jq tramite il gestore dei pacchetti del sistema operativo. È richiesto Bash 4 o una versione successiva perché il wrapper usa una gestione rigorosa degli errori ed espressioni condizionali moderne.

Esegui rclone config e crea due remoti con nomi distinti, ad esempio onedrive: e gdrive:. Inserisci l'ID client e il segreto del tuo provider quando i criteri o i limiti di frequenza richiedono applicazioni OAuth dedicate. rclone archivia i token OAuth nel proprio file di configurazione: proteggilo con autorizzazioni restrittive e non distribuirlo mai insieme allo script.

Prima di eseguire il wrapper, verifica ogni remoto con un comando di elenco in sola lettura e uno per la quota. Usa percorsi come onedrive:Department/Archive quando l'ambito comprende solo un sottoalbero.

rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

Bloccare un inventario deterministico prima di trasferire i byte

Il wrapper usa rclone lsf in modo ricorsivo, con un separatore di tabulazione esplicito e il formato sp, producendo prima la dimensione e poi il percorso. Verifica che ogni dimensione sia numerica e ogni percorso sia relativo, quindi esclude i percorsi già presenti nel checkpoint verificato.

L'edizione Bash rifiuta i nomi di file contenenti tabulazioni, ritorni a capo o nuove righe, perché gli elenchi --files-from-raw delimitati da nuove righe non possono rappresentarli senza ambiguità. Quando sono presenti nomi di questo tipo, usa l'edizione Python o un formato di inventario apposito.

Un checkpoint basato sui percorsi è volutamente semplice e ispezionabile. Presuppone che i percorsi di origine rimangano invariati durante l'esecuzione. Se possibile, blocca le scritture sull'origine oppure rigenera e riconcilia l'inventario quando sono previste modifiche simultanee.

rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

Interrompi l'operazione prima che un batch consumi la riserva

I byte liberi locali vengono ricavati da df sul file system di staging. I byte liberi nella destinazione provengono da rclone about --json: lo script usa free quando disponibile, altrimenti sottrae used da total. Controlla il totale dei byte in sospeso prima di iniziare e ricontrolla la capacità locale e quella di destinazione prima di ogni batch.

Alcuni provider o tipi di account non comunicano una quota finita tramite rclone. Il wrapper segnala questa limitazione e prosegue applicando i vincoli del provider. Considerala un requisito di monitoraggio, non una prova che lo spazio sia sufficiente.

Il limite del batch non è un massimo rigido per un singolo oggetto. Un file più grande del batch configurato può costituire un batch a sé, quindi lo spazio libero locale deve essere sufficiente per il file più grande più la riserva. La verifica completa della destinazione legge i byte dalla destinazione, ma nell'edizione rclone non conserva una seconda copia locale.

Verifica entrambi i lati del confine dell'area di staging locale

Ogni batch percorre due tratte indipendenti. Innanzitutto, rclone copia i percorsi di origine selezionati nello staging locale con --ignore-existing, quindi check --download legge entrambi i lati e confronta il contenuto effettivo. Successivamente, rclone copia i percorsi dallo staging alla destinazione e ripete la stessa verifica completa dei byte.

--ignore-existing rende non distruttive le esecuzioni interrotte: un oggetto esistente non viene sovrascritto. La verifica deve comunque riuscire prima che il percorso possa essere registrato nel checkpoint. Se la destinazione esistente è diversa, rclone check non riesce e la gestione rigorosa degli errori di Bash interrompe l'esecuzione.

L'uso di --download è più lento e comporta operazioni di lettura e traffico in uscita presso il provider, ma evita di dipendere esclusivamente dalla disponibilità di un algoritmo di hash comune esposto da entrambi i provider. Il comando non modifica nessuno dei due lati.

rclone copy "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" --one-way --download

rclone copy "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" --one-way --download

Esegui il trasferimento da OneDrive a Google Drive con un'area di staging limitata

L'esempio lascia intatti 15 GiB di disco locale, mantiene 10 GiB liberi su Google Drive, limita un batch normale a 8 GiB o 200 file e usa quattro trasferimenti simultanei. Il contenuto di destinazione viene scritto in una nuova cartella con data.

Usa prima --dry-run. Esegue l'inventario dell'origine e il controllo preliminare della quota della destinazione senza scaricare né caricare dati. Il wrapper mostra tutti i byte in attesa, che devono essere confrontati con l'ambito della migrazione prima del primo batch effettivo.

./fileark-cloud-transfer.sh \
  --source onedrive: \
  --destination gdrive: \
  --destination-folder "OneDrive archive 2026-07-25" \
  --staging-dir /srv/fileark-staging \
  --state-file ./onedrive-to-google-verified.txt \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --transfers 4 \
  --checkers 8 \
  --dry-run

# Remove only --dry-run after reviewing the preflight.

Inverti la direzione senza riutilizzare lo stato

Il wrapper è indipendente dal provider perché rclone gestisce gli adattatori remoti. Inverti gli argomenti dei remoti per copiare Google Drive in OneDrive e assegna all'esecuzione una nuova cartella di destinazione, un percorso di staging e un file di checkpoint.

Documenti, Fogli, Presentazioni e altri formati virtuali nativi di Google richiedono la configurazione dell'esportazione in rclone e un'attenta verifica. Conferma le estensioni esportate e il comportamento della conversione con un set di prova. Una copia tramite shell non conserva la cronologia della collaborazione di Google, le scorciatoie, le autorizzazioni o i metadati specifici di Microsoft.

./fileark-cloud-transfer.sh \
  --source gdrive: \
  --destination onedrive: \
  --destination-folder "Google archive 2026-07-25" \
  --staging-dir /srv/google-staging \
  --state-file ./google-to-onedrive-verified.txt \
  --batch-gib 8 \
  --local-reserve-gib 15

Registrare il checkpoint solo dopo la verifica della destinazione

Dopo che il controllo della destinazione è terminato correttamente, il wrapper aggiunge ogni percorso relativo a un checkpoint in testo normale. Elimina quindi il file dallo staging locale e rimuove le directory locali vuote. Il remoto di origine rimane intatto.

Durante un'esecuzione, il checkpoint è di sola aggiunta ed è facile da verificare con gli strumenti standard. Conservalo insieme a riga di comando, versione di rclone, impronta digitale della configurazione, inventario, log, timestamp e note di accettazione. Non modificarlo per nascondere un errore, a meno che il file di destinazione non sia stato verificato in modo indipendente.

Un checkpoint basato sul solo percorso non può rilevare un oggetto di origine il cui contenuto cambia senza che cambi il percorso. Per i set di dati modificabili, sospendi le scritture, acquisisci separatamente gli ID del provider e i metadati di modifica oppure usa il checkpoint più rigoroso basato su ID e dimensioni dell'edizione Python. Per le migrazioni regolamentate o collaborative, usa un flusso di lavoro gestito con un controllo esplicito delle modifiche.

Trattare ogni uscita diversa da zero come un batch irrisolto

• La modalità rigorosa interrompe l'esecuzione quando non riesce un comando o una pipeline oppure quando viene usata una variabile non impostata; la directory temporanea dell'inventario viene rimossa automaticamente.
• rclone riprova i trasferimenti in caso di errori temporanei, ma gli errori persistenti relativi ad autorizzazioni, quota, rete, conflitti o integrità interrompono il batch.
• I file nello staging non registrati nel checkpoint rimangono disponibili per l'ispezione e una nuova esecuzione identica usa --ignore-existing prima di verificarne i byte.
• Un file di destinazione con contenuto diverso non viene mai sovrascritto. Risolvi il conflitto o scegli una radice di destinazione vuota.
• Non trasformare una copia non riuscita in rclone sync o move. Questi comandi hanno una diversa semantica di eliminazione.
• Conserva i log e il checkpoint finché l'accettazione manuale della destinazione non è completa.

Proteggi l'host che diventa il piano dati

L'host di staging contiene temporaneamente copie leggibili dei dati di origine e token di aggiornamento OAuth. Usa la crittografia completa del disco, autorizzazioni restrittive per i file, un account dedicato del sistema operativo, dipendenze aggiornate con le patch, accesso controllato degli amministratori e una politica di backup crittografato che non conservi in modo imprevisto i contenuti di staging.

Evita di inserire segreti nella riga di comando, perché gli elenchi dei processi e la cronologia della shell possono esporli. La configurazione protetta di rclone può offuscare i token archiviati, ma non sostituisce la sicurezza dell'host. Dopo l'accettazione della migrazione, rimuovi il materiale dei token e i residui dello staging in base ai tuoi criteri di conservazione.

Monitora i log di controllo dei provider, il traffico di rete in uscita, lo stato del disco, la disponibilità degli inode, lo stato del processo e l'output di rclone. Lasciare aperto un terminale non equivale a supervisionare il processo: usa un gestore di servizi o un multiplexer di terminale approvato e conserva i log in modo persistente.

Concludere la migrazione con prove, non con un comando riuscito

• Archivia l'inventario bloccato, il comando esatto, il checksum dello script, la versione di rclone, l'impronta digitale della configurazione dei remoti e il checkpoint verificato.
• Riconcilia il numero di file e i byte noti per cartella, non solo sul totale dell'unità.
• Apri un campione basato sul rischio di documenti grandi, piccoli, vecchi, nuovi, Unicode, profondamente annidati, archiviati e convertiti.
• Verifica l'accesso alla destinazione da account utente rappresentativi e ricrea separatamente le condivisioni necessarie.
• Esamina pacchetti ignorati, scorciatoie, collegamenti, documenti nativi, conflitti e avvisi dei provider.
• Mantieni un periodo di sovrapposizione con l'origine e ottieni l'accettazione esplicita del proprietario prima di qualsiasi successiva decisione sulla conservazione o eliminazione.

Domande frequenti

Perché lo script Bash usa rclone copy anziché sync?

La copia non elimina gli oggetti di origine né rimuove dalla destinazione gli oggetti assenti nell'origine. La sincronizzazione ha una diversa semantica di riconciliazione ed eliminazione, quindi è volutamente esclusa da questo flusso di lavoro.

rclone check --download modifica uno dei due cloud?

No. Legge e confronta il contenuto dei file. Lo script lo usa dopo ogni fase di copia, in modo che venga creato un checkpoint per un percorso solo dopo che i byte nella destinazione corrispondono a quelli nell'area di staging.

Cosa succede quando la destinazione contiene già un file?

La copia usa --ignore-existing, seguita da una verifica completa dei byte. Un oggetto identico può superarla; un oggetto diverso fa fallire il controllo. Lo script non sovrascrive mai il file in conflitto.

Lo script può gestire file più grandi di un batch?

Sì. Un singolo file di dimensioni eccessive forma un batch a sé stante. Il file system di staging deve avere spazio sufficiente per quel file e per la riserva locale configurata.

Questa procedura migra autorizzazioni, versioni o dati di collaborazione nativi del cloud?

No. Copia il contenuto e i percorsi dei file tramite rclone. Controllo degli accessi, versioni, etichette, commenti, scorciatoie, collegamenti, regole di conservazione e comportamenti nativi del provider richiedono una pianificazione e una verifica separate.

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
• Documentazione di riferimento del comando rclone copy
• rclone check e verifica completa dei byte
• Formati di inventario di rclone lsf
• Output della quota di rclone about