Transfer między chmurami wyłącznie przez kopiowanie w Bash z rclone

Krótka odpowiedź

FileArk to prostsze, zarządzane rozwiązanie do dużych lub nienadzorowanych migracji: przeprowadza transfer online, został przetestowany z obciążeniami obejmującymi wiele terabajtów i sprawdza każdy wynik przed zakończeniem. Operatorom, którzy chcą kontrolować przepływ danych z poziomu powłoki, ten objęty licencją MIT skrypt opakowujący Bash umożliwia kopiowanie ograniczonych partii przez lokalny obszar przejściowy, weryfikuje oba etapy bajt po bajcie i nigdy nie usuwa plików źródłowych.

Dlaczego warto użyć skryptu opakowującego rclone zamiast odtwarzać klienta każdego dostawcy

rclone zapewnia skryptom powłoki dojrzałą warstwę abstrakcji dostawców, konfigurację OAuth, stronicowanie, mechanizmy ponawiania prób, wznawialne transfery, kontrolę współbieżności oraz polecenia do tworzenia spisów i weryfikacji. Dzięki temu skrypt opakowujący może skupić się na niezmiennych zasadach migracji: poleceniach wyłącznie kopiujących, ograniczonym obszarze przejściowym, rezerwach pojemności, deterministycznych listach plików i trwałym zapisie postępu.

Nie oznacza to, że zadanie jest automatyczne. Operator nadal odpowiada za konfigurację zdalnych magazynów, bezpieczeństwo tokenów, dostępność sieci, nadzorowanie procesu, dysk lokalny, dzienniki, limity dostawców, przegląd obiektów zakończonych błędem oraz odbiór miejsca docelowego. FileArk jest przeznaczony dla użytkowników, którzy wolą, aby ta procedura działała jako zarządzany proces online, a nie na ich stacji roboczej lub serwerze.

Skrypt nigdy nie wywołuje poleceń rclone move, sync, delete, purge ani rmdirs. Do wykrywania danych używa lsf i about, do każdego etapu — copy, a do pełnej weryfikacji bajt po bajcie — check --download. Usuwany jest wyłącznie zweryfikowany plik z lokalnego katalogu przejściowego.

Pobierz wersję Bash i licencję MIT

Uruchom demonstrację dla operatora bez dostępu do sieci

Tryb demonstracyjny można bezpiecznie uruchomić przed zainstalowaniem rclone lub jq, ponieważ po przeanalizowaniu argumentów program kończy działanie przed sprawdzeniem zależności. Dane wyjściowe wymieniają zabronione operacje destrukcyjne, pokazują obie rezerwy pojemności, a na końcu podają liczbę usunięć ze źródła.

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

Zainstaluj i skonfiguruj zależności wymagane przez operatora

Zainstaluj aktualną wersję rclone zgodnie z oficjalnymi instrukcjami, a jq — za pomocą menedżera pakietów systemu operacyjnego. Wymagany jest Bash 4 lub nowszy, ponieważ skrypt opakowujący korzysta z rygorystycznej obsługi błędów i nowoczesnych wyrażeń warunkowych.

Uruchom rclone config i utwórz dwa zdalne magazyny o niezależnych nazwach, na przykład onedrive: i gdrive:. Jeśli zasady lub limity szybkości wymagają osobnych aplikacji OAuth, wprowadź własny identyfikator klienta i klucz tajny dostawcy. rclone przechowuje tokeny OAuth w swoim pliku konfiguracyjnym. Zabezpiecz ten plik restrykcyjnymi uprawnieniami i nigdy nie dołączaj go do skryptu.

Przed uruchomieniem skryptu opakowującego sprawdź każdy zdalny magazyn za pomocą polecenia wyświetlającego listę tylko do odczytu oraz polecenia sprawdzającego limit. Jeśli zakres obejmuje tylko część drzewa, użyj ścieżek takich jak onedrive:Department/Archive.

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

Utwórz niezmienny, deterministyczny spis przed rozpoczęciem przesyłania danych

Skrypt opakowujący rekurencyjnie używa polecenia rclone lsf z jawnym separatorem tabulacji i formatem sp, co daje rozmiar, a po nim ścieżkę. Sprawdza, czy każdy rozmiar jest liczbą, a każda ścieżka jest względna, po czym wyklucza ścieżki już obecne w zweryfikowanym punkcie kontrolnym.

Wersja Bash odrzuca nazwy plików zawierające tabulatory, znaki powrotu karetki lub znaki nowego wiersza, ponieważ rozdzielane znakami nowego wiersza listy --files-from-raw nie mogą ich jednoznacznie reprezentować. Jeśli takie nazwy występują, użyj wersji Python lub specjalnie zaprojektowanego formatu spisu.

Punkt kontrolny oparty na ścieżkach jest celowo prosty i łatwy do sprawdzenia. Zakłada, że ścieżki źródłowe pozostają niezmienne podczas działania programu. Jeśli to możliwe, wstrzymaj zapisy w źródle. Gdy spodziewasz się równoczesnych zmian, ponownie wygeneruj spis i uzgodnij różnice.

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

\t' > "$inventory"

Przerwij działanie, zanim partia wykorzysta rezerwę

Liczba wolnych bajtów lokalnych pochodzi z polecenia df uruchomionego dla systemu plików obszaru przejściowego. Liczba wolnych bajtów w miejscu docelowym pochodzi z rclone about --json: skrypt używa wartości free, jeśli jest dostępna, a w przeciwnym razie odejmuje used od total. Przed rozpoczęciem pracy sprawdza łączny rozmiar oczekujących danych, a przed każdą partią ponownie sprawdza pojemność lokalną i docelową.

Niektórzy dostawcy lub niektóre typy kont nie udostępniają za pośrednictwem rclone informacji o skończonym limicie miejsca. Skrypt opakowujący wyświetla tę informację i kontynuuje działanie z uwzględnieniem ograniczeń egzekwowanych przez dostawcę. Traktuj to jako wymóg monitorowania, a nie dowód, że dostępna przestrzeń jest wystarczająca.

Limit partii nie jest nieprzekraczalnym maksimum dla pojedynczego obiektu. Jeden plik większy niż skonfigurowana partia może utworzyć własną partię, dlatego ilość wolnego miejsca lokalnego musi wystarczyć na największy plik oraz rezerwę. Pełna weryfikacja miejsca docelowego odczytuje z niego bajty, ale w wersji opartej na rclone nie zachowuje drugiej kopii lokalnej.

Zweryfikuj dane po obu stronach lokalnego obszaru przejściowego

Każda partia przechodzi przez dwa niezależne etapy. Najpierw rclone kopiuje wybrane ścieżki źródłowe do lokalnego obszaru przejściowego z opcją --ignore-existing, a następnie check --download odczytuje dane po obu stronach i porównuje ich rzeczywistą zawartość. W drugim etapie rclone kopiuje te ścieżki z obszaru przejściowego do miejsca docelowego i powtarza tę samą pełną kontrolę bajt po bajcie.

Opcja --ignore-existing sprawia, że przerwane uruchomienia nie powodują destrukcyjnych zmian: istniejący obiekt nie jest nadpisywany. Ścieżka może trafić do punktu kontrolnego dopiero po pomyślnej weryfikacji. Jeśli istniejący obiekt docelowy jest inny, polecenie rclone check kończy się niepowodzeniem, a ścisła obsługa błędów w Bash zatrzymuje program.

Użycie opcji --download działa wolniej i wykorzystuje operacje odczytu oraz transfer wychodzący u dostawcy, ale pozwala uniknąć polegania wyłącznie na tym, czy obaj dostawcy udostępniają wspólny algorytm skrótu. Polecenie nie modyfikuje danych po żadnej ze stron.

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

Uruchom transfer z OneDrive do Google Drive z ograniczonym obszarem przejściowym

W tym przykładzie 15 GiB dysku lokalnego pozostaje nienaruszone, w Google Drive zachowywane jest 10 GiB wolnego miejsca, zwykła partia jest ograniczona do 8 GiB lub 200 plików, a transfery odbywają się w czterech równoległych wątkach. Zawartość docelowa jest zapisywana w nowym folderze z datą.

Najpierw użyj opcji --dry-run. Przeprowadza ona inwentaryzację źródła i wstępnie sprawdza limit miejsca docelowego bez pobierania ani przesyłania danych. Skrypt opakowujący wyświetla łączną liczbę bajtów oczekujących na transfer. Przed uruchomieniem pierwszej rzeczywistej partii należy ją uzgodnić z zakresem migracji.

./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.

Odwróć kierunek bez ponownego używania stanu

Skrypt opakowujący jest niezależny od dostawcy, ponieważ to rclone obsługuje adaptery zdalnych magazynów. Zamień miejscami argumenty zdalnych magazynów, aby skopiować dane z Google Drive do OneDrive, a dla tego uruchomienia wskaż nowy folder docelowy, ścieżkę obszaru przejściowego i plik punktów kontrolnych.

Dokumenty, Arkusze i Prezentacje Google oraz inne formaty wirtualne wymagają skonfigurowania eksportu w rclone i dokładnego sprawdzenia. Potwierdź rozszerzenia eksportowanych plików i sposób konwersji na zestawie testowym. Kopiowanie za pomocą skryptu powłoki nie zachowuje historii współpracy Google, skrótów, uprawnień ani metadanych specyficznych dla 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

Zapisuj punkt kontrolny dopiero po weryfikacji miejsca docelowego

Po pomyślnym zakończeniu kontroli miejsca docelowego skrypt opakowujący dopisuje każdą ścieżkę względną do tekstowego pliku punktów kontrolnych. Następnie usuwa dany plik z lokalnego obszaru przejściowego oraz puste katalogi lokalne. Zdalny magazyn źródłowy pozostaje nienaruszony.

Podczas działania programu dane są tylko dopisywane do punktu kontrolnego, który można łatwo audytować za pomocą standardowych narzędzi. Zachowaj go wraz z wierszem polecenia, wersją rclone, odciskiem konfiguracji, spisem, dziennikami, znacznikami czasu i uwagami dotyczącymi odbioru. Nie edytuj go w celu ukrycia błędu, chyba że plik docelowy został niezależnie zweryfikowany.

Punkt kontrolny oparty wyłącznie na ścieżce nie wykryje obiektu źródłowego, którego zawartość zmieniła się bez zmiany ścieżki. W przypadku modyfikowalnych zbiorów danych wstrzymaj zapisy, osobno zarejestruj identyfikatory dostawcy i metadane modyfikacji albo użyj dostępnego w wersji Python bardziej rygorystycznego punktu kontrolnego opartego na identyfikatorze i rozmiarze. W przypadku migracji regulowanych lub obejmujących współpracę użyj zarządzanego procesu z jawną kontrolą zmian.

Każdy niezerowy kod wyjścia traktuj jako nierozstrzygniętą partię

• Tryb ścisły kończy działanie po błędzie polecenia lub potoku albo w przypadku użycia niezdefiniowanej zmiennej. Tymczasowy katalog spisu jest usuwany automatycznie.
• rclone ponawia przejściowo nieudane transfery, ale trwałe błędy uprawnień, limitu, sieci, konfliktu lub integralności zatrzymują partię.
• Pliki w obszarze przejściowym, które nie trafiły do punktu kontrolnego, pozostają dostępne do sprawdzenia, a identyczne ponowne uruchomienie używa opcji --ignore-existing przed sprawdzeniem ich bajtów.
• Różniący się plik docelowy nigdy nie jest zastępowany. Rozwiąż konflikt lub wybierz czysty katalog główny miejsca docelowego.
• Nie zastępuj nieudanego kopiowania poleceniem rclone sync ani move. Te polecenia mają inne zasady usuwania danych.
• Zachowaj dzienniki i punkt kontrolny do czasu zakończenia ręcznego odbioru miejsca docelowego.

Zabezpiecz host, który stanie się płaszczyzną danych

Host przejściowy tymczasowo zawiera możliwe do odczytania kopie danych źródłowych oraz tokeny odświeżania OAuth. Stosuj szyfrowanie całego dysku, restrykcyjne uprawnienia do plików, dedykowane konto systemu operacyjnego, aktualne zależności, kontrolowany dostęp administratorów oraz zasady tworzenia szyfrowanych kopii zapasowych, które nie przechowują nieoczekiwanie zawartości obszaru przejściowego.

Nie podawaj danych poufnych w wierszu polecenia, ponieważ mogą je ujawnić listy procesów i historia powłoki. Chroniona konfiguracja rclone może maskować tokeny przechowywane na dysku, ale nie zastępuje zabezpieczeń hosta. Po odbiorze migracji usuń dane tokenów i pozostałości obszaru przejściowego zgodnie z zasadami przechowywania danych.

Monitoruj dzienniki audytu dostawców, ruch wychodzący z sieci, stan dysku, dostępność i-węzłów, stan procesu oraz dane wyjściowe rclone. Pozostawienie otwartego terminala nie jest nadzorowaniem procesu. Użyj zatwierdzonego menedżera usług lub multipleksera terminala i zadbaj o trwałe przechowywanie dzienników.

Zakończ migrację na podstawie dowodów, a nie zielonego statusu polecenia

• Zarchiwizuj niezmienny spis, dokładne polecenie, sumę kontrolną skryptu, wersję rclone, odcisk konfiguracji zdalnych magazynów oraz zweryfikowany punkt kontrolny.
• Uzgodnij liczbę plików i znaną liczbę bajtów dla każdego folderu, a nie tylko dla całego dysku.
• Otwórz dobraną na podstawie ryzyka próbkę dokumentów: dużych, małych, starych, nowych, zawierających znaki Unicode, głęboko zagnieżdżonych, zarchiwizowanych i przekonwertowanych.
• Przetestuj dostęp do miejsca docelowego z reprezentatywnych kont użytkowników i osobno odtwórz wymagane udostępnienia.
• Sprawdź pominięte pakiety, skróty, łącza, dokumenty natywne, konflikty i ostrzeżenia dostawców.
• Zachowaj okres, w którym dane źródłowe pozostają dostępne równolegle, i uzyskaj jednoznaczną akceptację właściciela przed podjęciem późniejszej decyzji o przechowywaniu lub usunięciu danych.

Najczęściej zadawane pytania

Dlaczego skrypt Bash używa polecenia rclone copy zamiast sync?

Kopiowanie nie usuwa obiektów źródłowych ani obiektów docelowych, których nie ma w źródle. Synchronizacja ma inne zasady uzgadniania i usuwania danych, dlatego celowo nie wchodzi w zakres tej procedury.

Czy rclone check --download zmienia dane w którejkolwiek chmurze?

Nie. Proces odczytuje i porównuje zawartość plików. Skrypt używa go po każdym etapie kopiowania, dzięki czemu ścieżka zostaje zapisana w punkcie kontrolnym dopiero wtedy, gdy bajty w miejscu docelowym są zgodne z bajtami w obszarze przejściowym.

Co się stanie, jeśli miejsce docelowe już zawiera plik?

Kopiowanie używa opcji --ignore-existing, po czym następuje pełna weryfikacja bajt po bajcie. Identyczny obiekt może przejść weryfikację, natomiast inny obiekt powoduje jej niepowodzenie. Skrypt nigdy nie nadpisuje pliku powodującego konflikt.

Czy skrypt obsługuje pliki większe niż jedna partia?

Tak. Pojedynczy plik przekraczający limit utworzy osobną partię. System plików obszaru przejściowego musi mieć miejsce na ten plik oraz skonfigurowaną rezerwę lokalną.

Czy ten proces przenosi uprawnienia, wersje lub dane współpracy natywne dla chmury?

Nie. Proces kopiuje za pomocą rclone zawartość plików i ich ścieżki. Kontrola dostępu, wersje, etykiety, komentarze, skróty, linki, reguły przechowywania i zachowania natywne dla dostawcy wymagają osobnego zaplanowania i zweryfikowania.

Oficjalne źródła wykorzystane w tym poradniku

• Centrum edukacyjne Google Workspace: przejście z OneDrive na Google Drive
• Pomoc Google Drive: miejsce na dane i obsługa plików
• Pomoc techniczna Microsoft: przekazywanie i zapisywanie plików w OneDrive
• Dokumentacja polecenia rclone copy
• rclone check i pełna weryfikacja bajt po bajcie
• Formaty inwentaryzacji rclone lsf
• Dane o limicie zwracane przez rclone about