Bash + rclone · OneDrive ↔ Google Drive · Ghid operațional open-source

Transfer în cloud exclusiv prin copiere, în Bash cu rclone

rclone gestionează deja paginarea în cloud, reîncercările, transferurile reluabile și hashurile furnizorilor. Sarcina tehnică este de a include aceste primitive într-o procedură operațională care se oprește în siguranță la eroare și ține cont de capacitate.

Actualizat ; 20 min de lectură.

Pe scurt

FileArk este opțiunea gestionată mai simplă pentru migrări mari sau nesupravegheate: efectuează transferul online, a fost testat cu volume de lucru de mai mulți terabyți și verifică fiecare rezultat înainte de finalizare. Pentru operatorii care doresc să controleze calea datelor prin shell, acest script wrapper Bash cu licență MIT copiază loturi limitate printr-o zonă de stocare intermediară locală, verifică octet cu octet ambele segmente și nu șterge niciodată fișierele sursă.

De ce să includeți rclone într-un script wrapper în loc să reconstruiți clientul fiecărui furnizor

rclone oferă unui flux de lucru shell o abstractizare matură a furnizorilor, configurare OAuth, paginare, mecanisme de reîncercare, transferuri reluabile, controlul concurenței, comenzi pentru inventariere și comenzi pentru verificare. Astfel, scriptul wrapper se poate concentra asupra proprietăților esențiale ale migrării: comenzi care doar copiază, stocare intermediară limitată, rezerve de capacitate, liste deterministe de fișiere și progres persistent.

Acest lucru nu automatizează operațiunea. Operatorul rămâne responsabil pentru configurarea stocărilor la distanță, securitatea tokenurilor, disponibilitatea rețelei, supravegherea procesului, discul local, jurnalele, limitele furnizorilor, examinarea obiectelor eșuate și acceptarea destinației. FileArk se adresează utilizatorilor care doresc ca această procedură să fie efectuată ca un flux de lucru online gestionat, nu pe stația lor de lucru sau pe serverul lor.

Scriptul nu apelează niciodată în mod explicit rclone move, sync, delete, purge sau rmdirs. Folosește lsf și about pentru detectare, copy pentru fiecare segment și check --download pentru verificarea integrală a octeților. Singura eliminare este cea a unui fișier verificat din directorul local de stocare intermediară.

Descărcați ediția Bash și licența MIT

Descărcați programul de transfer Bash și rclone
Un script wrapper care doar copiază, cu limite pentru loturi, rezerve locale și la destinație, verificarea integrală a octeților, puncte de control, controlul reîncercărilor și o demonstrație fără acces la rețea.
fileark-cloud-transfer.sh · Bash 4+ · rclone · jq · licență MIT

Descărcați licența MIT
Notificare privind permisiunea, aplicabilă ambelor scripturi FileArk pentru transfer manual.
LICENSE-fileark-cloud-transfer.txt · MIT · text simplu

Rulați demonstrația pentru operator fără acces la rețea

Terminal care rulează în modul demonstrativ scriptul FileArk pentru transfer în cloud cu Bash și rclone
Demonstrația prezintă un singur lot limitat care trece prin ambele etape de verificare. Nu inspectează configurația rclone, nu contactează niciun serviciu cloud și nu scrie date la distanță.

Demonstrația poate fi rulată în siguranță înainte de instalarea rclone sau jq, deoarece analiza argumentelor se încheie înainte de verificarea dependențelor. Rezultatul afișat enumeră operațiunile distructive interzise, prezintă ambele rezerve de capacitate și se încheie cu numărul de ștergeri din sursă.

Inspectați și testați rapid fișierul descărcat
chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

Instalați și configurați dependențele necesare operatorului

Instalați o versiune recentă de rclone urmând instrucțiunile oficiale și instalați jq folosind managerul de pachete al sistemului de operare. Este necesar Bash 4 sau o versiune mai nouă, deoarece scriptul de încadrare folosește gestionarea strictă a erorilor și expresii condiționale moderne.

Rulați rclone config și creați două stocări la distanță cu nume distincte, de exemplu onedrive: și gdrive:. Introduceți propriul ID de client și secret de client pentru furnizor atunci când politicile sau limitele de rată necesită aplicații OAuth dedicate. rclone stochează tokenurile OAuth în fișierul său de configurare; protejați fișierul prin permisiuni restrictive și nu îl includeți niciodată împreună cu scriptul.

Confirmați fiecare stocare la distanță printr-o comandă de listare doar în citire și una pentru cotă înainte de a rula scriptul wrapper. Folosiți căi precum onedrive:Department/Archive atunci când operațiunea vizează doar un subarbore.

Configurați și inspectați ambele stocări la distanță
rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

Fixați un inventar determinist înainte de a transfera octeți

Scriptul wrapper folosește recursiv rclone lsf, cu un tabulator explicit ca separator și formatul sp, generând dimensiunea urmată de cale. Acesta validează că fiecare dimensiune este numerică și fiecare cale este relativă, apoi exclude căile deja prezente în punctul de control verificat.

Ediția Bash respinge numele de fișiere care conțin tabulatori, retururi de car sau linii noi, deoarece listele --files-from-raw delimitate prin linii noi nu le pot reprezenta fără ambiguitate. Folosiți ediția Python sau un format de inventar creat special atunci când există astfel de nume.

Un punct de control bazat pe căi este intenționat simplu și ușor de inspectat. Acesta presupune că toate căile sursă rămân neschimbate pe durata rulării. Dacă este posibil, suspendați scrierile în sursă sau regenerați și reconciliați inventarul atunci când sunt așteptate modificări simultane.

Operația de bază pentru inventariere folosită de scriptul wrapper
rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

Opriți procesul înainte ca un lot să consume rezerva

Numărul de octeți liberi local este obținut prin df pe sistemul de fișiere folosit pentru stocarea intermediară. Numărul de octeți liberi la destinație este obținut prin rclone about --json: scriptul folosește valoarea free atunci când este furnizată, iar în caz contrar calculează total minus used. Acesta verifică numărul total de octeți în așteptare înainte de începerea operațiunii și verifică din nou capacitatea locală și cea de la destinație înaintea fiecărui lot.

Unii furnizori sau unele tipuri de conturi nu publică prin rclone o cotă finită. Scriptul de încadrare afișează această limitare și continuă sub restricțiile impuse de furnizor. Tratați situația ca pe o cerință de monitorizare, nu ca pe o dovadă că există spațiu suficient.

Limita lotului nu este o limită maximă strictă pentru un singur obiect. Un fișier mai mare decât dimensiunea configurată a lotului poate forma propriul lot, astfel că spațiul local liber trebuie să acopere cel mai mare fișier plus rezerva. Verificarea completă a destinației citește octeții de la destinație, dar ediția rclone nu păstrează o a doua copie locală.

Verificați fiecare parte a zonei locale de stocare intermediară

Fiecare lot parcurge două segmente independente. Mai întâi, rclone copiază căile sursă selectate în zona de stocare intermediară locală folosind --ignore-existing, apoi check --download citește ambele părți și compară conținutul efectiv. În al doilea rând, rclone copiază căile din zona de stocare intermediară la destinație și repetă aceeași verificare integrală a octeților.

--ignore-existing face ca reluarea rulărilor întrerupte să nu fie distructivă: un obiect existent nu este suprascris. Verificarea trebuie totuși să reușească înainte ca acea cale să poată fi adăugată la punctul de control. Dacă obiectul existent la destinație este diferit, rclone check eșuează, iar gestionarea strictă a erorilor în Bash oprește rularea.

Utilizarea opțiunii --download este mai lentă și consumă operațiuni de ieșire/citire ale furnizorului, dar evită dependența exclusivă de disponibilitatea unui algoritm hash comun oferit de ambii furnizori. Comanda nu modifică niciuna dintre părți.

Cele două segmente de copiere și verificare
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

Transferați din OneDrive în Google Drive cu stocare intermediară limitată

Exemplul păstrează neutilizați 15 GiB de pe discul local, menține 10 GiB liberi în Google Drive, limitează un lot obișnuit la 8 GiB sau 200 de fișiere și folosește patru transferuri simultane. Conținutul de la destinație este scris într-un folder nou, denumit cu data curentă.

Folosiți mai întâi --dry-run. Această opțiune inventariază sursa și verifică preliminar cota destinației, fără descărcări sau încărcări. Scriptul de încadrare afișează numărul total de octeți în așteptare, care trebuie comparat cu domeniul migrării înainte de primul lot efectiv.

Efectuați verificările preliminare, apoi procesați același domeniu
./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.

Inversați direcția fără a reutiliza starea

Scriptul wrapper este independent de furnizor, deoarece rclone gestionează adaptoarele pentru stocările la distanță. Inversați argumentele stocărilor la distanță pentru a copia Google Drive în OneDrive și folosiți pentru acea rulare un folder de destinație, o cale de stocare intermediară și un fișier de puncte de control noi.

Documentele, foile de calcul, prezentările și alte formate virtuale native Google necesită configurarea exportului în rclone și o verificare atentă. Confirmați extensiile exportate și comportamentul conversiei folosind un set de testare. Copierea prin shell nu păstrează istoricul colaborării Google, comenzile rapide, permisiunile sau metadatele specifice Microsoft.

Din Google Drive în OneDrive
./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

Creați punctul de control numai după verificarea destinației

După încheierea cu succes a verificării destinației, scriptul wrapper adaugă fiecare cale relativă într-un punct de control în format text simplu. Apoi șterge fișierul respectiv din zona de stocare intermediară locală și elimină directoarele locale goale. Stocarea la distanță sursă rămâne neatinsă.

În timpul unei rulări, punctul de control permite doar adăugarea de date și poate fi auditat ușor cu instrumente standard. Păstrați-l împreună cu linia de comandă, versiunea rclone, amprenta configurației, inventarul, jurnalele, marcajele temporale și notele de acceptare. Nu îl editați pentru a ascunde un eșec decât dacă fișierul de la destinație a fost verificat independent.

Un punct de reluare bazat exclusiv pe cale nu poate detecta un obiect sursă al cărui conținut se modifică fără ca și calea să se schimbe. Pentru seturile de date modificabile, suspendați scrierile, înregistrați separat ID-urile furnizorului și metadatele de modificare sau utilizați punctul de reluare mai strict, bazat pe ID și dimensiune, din ediția Python. Pentru migrările reglementate sau colaborative, utilizați un flux de lucru gestionat, cu un proces explicit de control al modificărilor.

Tratați fiecare cod de ieșire diferit de zero ca pe un lot nerezolvat

  • Modul strict oprește rularea atunci când eșuează o comandă, o conductă de comenzi sau accesarea unei variabile nesetate; directorul temporar al inventarului este eliminat automat.
  • rclone reîncearcă transferurile afectate de erori temporare, dar erorile persistente de permisiune, cotă, rețea, conflict sau integritate opresc lotul.
  • Fișierele din zona de stocare intermediară care nu au fost adăugate la punctul de control rămân disponibile pentru inspectare, iar o reluare identică folosește --ignore-existing înainte de a le verifica octeții.
  • Un fișier diferit de la destinație nu este suprascris niciodată. Rezolvați conflictul sau alegeți o rădăcină de destinație neutilizată.
  • Nu transformați o copiere eșuată într-o comandă rclone sync sau move. Aceste comenzi au o semantică diferită pentru ștergere.
  • Păstrați jurnalele și punctul de control până la finalizarea acceptării manuale a destinației.

Securizați sistemul gazdă care devine planul de date

Sistemul gazdă folosit pentru stocarea intermediară conține temporar copii lizibile ale datelor sursă și tokenuri OAuth de reîmprospătare. Utilizați criptarea integrală a discului, permisiuni restrictive pentru fișiere, un cont dedicat în sistemul de operare, dependențe actualizate, acces controlat pentru administratori și o politică de backup criptat care să nu păstreze în mod neașteptat conținutul intermediar.

Evitați secretele în linia de comandă, deoarece listele de procese și istoricul shellului le pot expune. Configurația protejată a rclone poate face tokenurile stocate mai greu de descifrat, dar nu înlocuiește securitatea sistemului-gazdă. După acceptarea migrării, eliminați datele tokenurilor și resturile din zona de stocare intermediară conform politicii dvs. de păstrare.

Monitorizați jurnalele de audit ale furnizorilor, traficul de ieșire din rețea, starea discurilor, disponibilitatea inodurilor, starea procesului și rezultatele rclone. Un terminal lăsat deschis nu înseamnă supravegherea procesului; folosiți un manager de servicii sau un multiplexor de terminal aprobat și păstrați jurnalele în mod persistent.

Încheiați migrarea pe baza dovezilor, nu doar a unei comenzi reușite

  • Arhivați inventarul fixat, comanda exactă, suma de control a scriptului, versiunea rclone, amprenta configurației stocărilor la distanță și punctul de control verificat.
  • Comparați numărul de fișiere și octeții cunoscuți pentru fiecare dosar, nu doar totalul unității.
  • Deschideți un eșantion selectat în funcție de risc, care să includă documente mari, mici, vechi, noi, cu caractere Unicode, imbricate profund, arhivate și convertite.
  • Testați accesul la destinație din conturi de utilizator reprezentative și recreați separat permisiunile de partajare necesare.
  • Examinați pachetele omise, scurtăturile, linkurile, documentele în format nativ, conflictele și avertismentele furnizorilor.
  • Mențineți o perioadă de suprapunere cu sursa și obțineți acceptul explicit al proprietarului înaintea oricărei decizii ulterioare privind păstrarea sau ștergerea.

Întrebări frecvente

De ce scriptul Bash folosește rclone copy în loc de sync?

Copierea nu șterge obiectele sursă și nici obiectele de la destinație care lipsesc din sursă. Sincronizarea are o semantică diferită pentru reconciliere și ștergere, astfel că este exclusă intenționat din acest flux de lucru.

Comanda rclone check --download modifică vreunul dintre cele două servicii cloud?

Nu. Comanda citește și compară conținutul fișierelor. Scriptul o folosește după fiecare etapă de copiere, astfel încât o cale să fie înregistrată ca punct de reluare numai după ce octeții de la destinație corespund celor din stocarea intermediară.

Ce se întâmplă dacă destinația conține deja un fișier?

Copierea folosește --ignore-existing, urmat de verificarea integrală a octeților. Un obiect identic poate trece verificarea; un obiect diferit determină eșecul verificării. Scriptul nu suprascrie niciodată fișierul aflat în conflict.

Poate scriptul gestiona fișiere mai mari decât un lot?

Da. Un fișier supradimensionat devine un lot separat. Sistemul de fișiere folosit pentru stocarea intermediară trebuie să aibă spațiu pentru acel fișier și pentru rezerva locală configurată.

Sunt migrate permisiunile, versiunile sau datele de colaborare native platformei cloud?

Nu. Prin rclone sunt copiate conținutul fișierelor și căile acestora. Controlul accesului, versiunile, etichetele, comentariile, comenzile rapide, linkurile, regulile de păstrare și comportamentul specific furnizorului necesită planificare și verificare separate.

Resurse oficiale folosite pentru acest ghid

Citește ghidul