Bash + rclone · OneDrive ↔ Google Drive · Посібник з експлуатації з відкритим кодом

Хмарне передавання лише з копіюванням у Bash за допомогою rclone

rclone уже підтримує розбиття хмарних результатів на сторінки, повторні спроби, відновлюване передавання та хеші провайдерів. Інженерне завдання полягає в тому, щоб об’єднати ці базові можливості в операційну процедуру, яка враховує місткість і безпечно припиняє роботу в разі помилки.

Оновлено ; 20 хв читання.

Коротка відповідь

FileArk — простіший керований варіант для великих міграцій або міграцій без нагляду: сервіс виконує передавання онлайн, протестований на робочих навантаженнях обсягом у кілька терабайтів і перевіряє кожен результат перед завершенням. Для операторів, які хочуть керувати шляхом даних з оболонки, ця обгортка на Bash із ліцензією MIT копіює обмежені пакети через локальне проміжне сховище, побайтово перевіряє обидва етапи й ніколи не видаляє файли із джерела.

Чому варто створити обгортку для rclone, а не розробляти заново клієнт кожного провайдера

rclone надає робочому процесу в оболонці зрілий рівень абстракції провайдерів, налаштування OAuth, розбиття результатів на сторінки, механізми повторних спроб, відновлюване передавання, керування паралельністю, команди інвентаризації та перевірки. Завдяки цьому обгортка може зосередитися на незмінних вимогах міграції: командах лише для копіювання, обмеженому проміжному сховищі, резервах місткості, детермінованих списках файлів і надійному збереженні прогресу.

Але це не робить завдання автоматичним. Оператор і далі відповідає за налаштування віддалених сховищ, захист токенів, доступність мережі, нагляд за процесом, локальний диск, журнали, обмеження провайдерів, перевірку об’єктів із помилками та приймання сховища призначення. FileArk призначений для користувачів, які хочуть виконувати цю процедуру як керований онлайн-процес, а не на власній робочій станції чи сервері.

Скрипт явно ніколи не викликає rclone move, sync, delete, purge або rmdirs. Для виявлення даних він використовує lsf і about, для кожного етапу — copy, а для повної побайтової перевірки — check --download. Видаляється лише перевірений файл із локального проміжного каталогу.

Завантажте версію на Bash і ліцензію MIT

Завантажити програму передавання на Bash і rclone
Обгортка лише для копіювання з обмеженнями пакетів, резервами в локальному сховищі та сховищі призначення, повною побайтовою перевіркою, контрольними точками, налаштуваннями повторних спроб і демонстраційним режимом без доступу до мережі.
fileark-cloud-transfer.sh · Bash 4+ · rclone · jq · ліцензія MIT

Завантажити ліцензію MIT
Повідомлення про дозвіл, що поширюється на обидва скрипти FileArk для перенесення вручну.
LICENSE-fileark-cloud-transfer.txt · MIT · звичайний текст

Запустіть демонстрацію для оператора без доступу до мережі

Термінал, у якому скрипт FileArk для хмарного передавання на Bash і rclone працює в демонстраційному режимі
Демонстрація показує, як один пакет обмеженого розміру проходить обидві межі перевірки. Вона не перевіряє конфігурацію rclone, не підключається до хмарних служб і не записує віддалені дані.

Демонстраційний режим можна безпечно запускати ще до встановлення rclone або jq, оскільки після розбору аргументів програма завершує роботу до перевірки залежностей. У виведених даних зазначено заборонені руйнівні операції, показано обидва резерви місткості, а наприкінці наведено кількість видалень із джерела.

Перевірте завантажений файл і виконайте базовий тест
chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

Установіть і налаштуйте залежності для оператора

Установіть актуальну версію rclone за офіційними інструкціями, а jq — за допомогою менеджера пакетів вашої операційної системи. Потрібен Bash 4 або новішої версії, оскільки оболонка використовує сувору обробку помилок і сучасні умовні вирази.

Запустіть rclone config і створіть два віддалені сховища з окремими назвами, наприклад onedrive: і gdrive:. Введіть власні ідентифікатор і секрет клієнта провайдера, якщо правила або обмеження частоти запитів вимагають окремих застосунків OAuth. rclone зберігає токени OAuth у своєму конфігураційному файлі. Захистіть цей файл суворими дозволами доступу й ніколи не додавайте його до комплекту зі скриптом.

Перш ніж запускати обгортку, перевірте кожне віддалене сховище за допомогою команди отримання списку лише для читання та команди перевірки квоти. Якщо потрібно охопити лише піддерево, використовуйте шляхи на зразок onedrive:Department/Archive.

Налаштуйте й перевірте обидва віддалені сховища
rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

Зафіксуйте детермінований реєстр до початку передавання байтів

Обгортка рекурсивно виконує rclone lsf із явно заданим роздільником-табуляцією та форматом sp, отримуючи розмір, після якого вказано шлях. Вона перевіряє, чи кожен розмір є числом, а кожен шлях — відносним, а потім вилучає шляхи, які вже є в перевіреній контрольній точці.

Версія на Bash відхиляє назви файлів, що містять символи табуляції, повернення каретки або нового рядка, оскільки списки --files-from-raw із розділенням новими рядками не можуть однозначно їх представити. Якщо такі назви є, скористайтеся версією на Python або спеціально розробленим форматом реєстру.

Контрольна точка на основі шляхів навмисно проста й зручна для перевірки. Вона передбачає, що шляхи в джерелі залишаються незмінними протягом запуску. Якщо можливо, заблокуйте запис у джерело. Якщо очікуються одночасні зміни, повторно сформуйте реєстр і узгодьте його.

Базова команда інвентаризації, яку використовує обгортка
rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

Зупиніть виконання до того, як пакет використає резерв

Кількість вільних байтів локального сховища визначається за допомогою df у файловій системі проміжного сховища. Кількість вільних байтів у сховищі призначення береться з rclone about --json: скрипт використовує значення free, якщо його надано, а інакше віднімає used від total. Перед початком роботи він перевіряє загальний обсяг байтів, що очікують на передавання, а перед кожним пакетом знову перевіряє місткість локального сховища та сховища призначення.

Деякі постачальники або типи облікових записів не передають через rclone дані про скінченну квоту. Оболонка повідомляє про це обмеження та продовжує роботу з урахуванням обмежень постачальника. Сприймайте це як вимогу до моніторингу, а не як підтвердження достатнього обсягу вільного місця.

Обмеження пакета не є жорстким максимумом для одного об’єкта. Один файл, більший за налаштований розмір пакета, може утворити окремий пакет, тому вільного місця на локальному диску має вистачати для найбільшого файлу та резерву. Повна перевірка сховища призначення зчитує з нього байти, але у версії на основі rclone не зберігає другу локальну копію.

Перевірте обидві сторони межі локального проміжного сховища

Кожен пакет проходить два незалежні етапи. Спочатку rclone копіює вибрані шляхи із джерела до локального проміжного сховища з параметром --ignore-existing, а потім check --download зчитує обидві сторони й порівнює фактичний вміст. Далі rclone копіює ці проміжні файли до сховища призначення й повторює таку саму повну побайтову перевірку.

Параметр --ignore-existing робить перервані запуски неруйнівними: наявний об’єкт не перезаписується. Перш ніж шлях буде додано до контрольної точки, перевірка все одно має завершитися успішно. Якщо наявний об’єкт у сховищі призначення відрізняється, rclone check завершується помилкою, а сувора обробка помилок Bash зупиняє запуск.

Використання --download працює повільніше та витрачає операції вихідного передавання й читання в постачальників, але дає змогу не покладатися лише на те, чи підтримують обидва постачальники спільний алгоритм хешування. Команда не змінює дані з жодної сторони.

Два етапи копіювання та перевірки
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

Перенесіть дані з OneDrive у Google Drive через обмежене проміжне сховище

У прикладі 15 GiB локального диска залишаються недоторканими, у Google Drive зберігається 10 GiB вільного місця, звичайний пакет обмежено 8 GiB або 200 файлами, а одночасно виконується чотири передавання. Вміст записується до нової датованої папки у сховищі призначення.

Спочатку використайте --dry-run. Ця команда інвентаризує джерело та попередньо перевіряє квоту призначення без завантаження чи передавання файлів. Оболонка виводить загальний обсяг даних, що очікують на перенесення, у байтах. Перед першим фактичним пакетом його слід звірити з визначеним обсягом перенесення.

Виконайте попередню перевірку, а потім перенесіть той самий обсяг даних
./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.

Змініть напрямок на зворотний, не використовуючи стан повторно

Обгортка не залежить від провайдера, оскільки за адаптери віддалених сховищ відповідає rclone. Поміняйте місцями аргументи віддалених сховищ, щоб скопіювати дані з Google Drive до OneDrive, і вкажіть для цього запуску нову папку призначення, шлях до проміжного сховища та файл контрольних точок.

Документи, Таблиці, Презентації та інші віртуальні формати Google потребують налаштування експорту в rclone і ретельної перевірки. Перевірте розширення експортованих файлів і порядок перетворення на тестовому наборі. Копіювання за допомогою оболонки не зберігає історію спільної роботи Google, ярлики, дозволи чи метадані, специфічні для Microsoft.

З Google Drive до 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

Створюйте контрольну точку лише після перевірки сховища призначення

Після успішного завершення перевірки сховища призначення обгортка додає кожен відносний шлях до текстового файлу контрольних точок. Потім вона видаляє відповідний файл із локального проміжного сховища та порожні локальні каталоги. Віддалене сховище-джерело залишається без змін.

Під час запуску дані до контрольної точки лише додаються, а її легко перевіряти стандартними інструментами. Зберігайте її разом із командним рядком, версією rclone, відбитком конфігурації, реєстром, журналами, часовими мітками та примітками про приймання. Не редагуйте її, щоб приховати збій, якщо файл у сховищі призначення не було незалежно перевірено.

Звичайна контрольна точка на основі шляху не може виявити вихідний об’єкт, вміст якого змінився без зміни шляху. Для змінюваних наборів даних призупиніть запис, окремо зафіксуйте ідентифікатори постачальника та метадані про зміну або скористайтеся суворішою контрольною точкою за ідентифікатором і розміром у версії на Python. Для регульованих або спільних перенесень використовуйте керований робочий процес із чітко визначеним контролем змін.

Вважайте кожне завершення з ненульовим кодом невирішеним пакетом

  • У суворому режимі робота завершується, якщо команда чи конвеєр дає збій або використовується невстановлена змінна; тимчасовий каталог реєстру видаляється автоматично.
  • rclone повторює спроби передавання в разі тимчасових збоїв, але стійкі помилки дозволів, квоти, мережі, конфліктів або цілісності зупиняють пакет.
  • Проміжні файли, не додані до контрольної точки, залишаються доступними для перевірки, а під час ідентичного повторного запуску перед перевіркою їхніх байтів застосовується --ignore-existing.
  • Файл у місці призначення, що має інший вміст, ніколи не перезаписується. Усуньте конфлікт або виберіть порожню кореневу папку призначення.
  • Не замінюйте невдале копіювання на rclone sync або move. Ці команди мають іншу семантику видалення.
  • Зберігайте журнали та контрольну точку до завершення ручного приймання сховища призначення.

Захистіть сервер, який стає площиною передавання даних

На сервері проміжного зберігання тимчасово містяться доступні для читання копії вихідних даних і токени оновлення OAuth. Використовуйте повнодискове шифрування, суворі дозволи на доступ до файлів, окремий обліковий запис операційної системи, оновлені залежності, контрольований доступ адміністраторів і політику зашифрованого резервного копіювання, яка не зберігатиме несподівано вміст проміжного сховища.

Не передавайте секрети через командний рядок, оскільки їх можуть розкрити списки процесів та історія оболонки. Захищена конфігурація rclone може приховувати токени під час зберігання, але не замінює захист хоста. Після приймання міграції видаліть дані токенів і залишки проміжних файлів відповідно до вашої політики зберігання.

Відстежуйте журнали аудиту провайдерів, вихідний мережевий трафік, стан диска, доступність inode, стан процесу та виведення rclone. Відкритий термінал не є наглядом за процесом: використовуйте схвалений диспетчер служб або термінальний мультиплексор і забезпечте надійне збереження журналів.

Завершуйте міграцію на підставі доказів, а не зеленого статусу команди

  • Архівуйте зафіксований реєстр, точну команду, контрольну суму скрипту, версію rclone, відбиток конфігурації віддалених сховищ і перевірену контрольну точку.
  • Звіряйте кількість файлів і відомий обсяг у байтах для кожної папки, а не лише загальний показник диска.
  • Відкрийте сформовану з урахуванням ризиків вибірку великих, малих, старих, нових, архівованих і конвертованих документів, а також документів із назвами в Unicode та глибокою вкладеністю.
  • Перевірте доступ до сховища призначення з репрезентативних облікових записів користувачів і окремо відтворіть необхідні налаштування спільного доступу.
  • Перевірте пропущені пакети, ярлики, посилання, нативні документи, конфлікти та попередження провайдерів.
  • Протягом певного періоду зберігайте вихідні дані паралельно та отримайте явне схвалення власника перед будь-яким подальшим рішенням щодо зберігання чи видалення.

Поширені запитання

Чому Bash-скрипт використовує rclone copy, а не sync?

Копіювання не видаляє об’єкти із джерела й не видаляє зі сховища призначення об’єкти, яких немає в джерелі. Синхронізація має іншу семантику узгодження та видалення, тому її навмисно не включено до цього робочого процесу.

Чи змінює rclone check --download дані в будь-якому з хмарних сховищ?

Ні. Команда читає та порівнює вміст файлів. Скрипт використовує її після кожного етапу копіювання, тому шлях додається до контрольної точки лише після того, як байти в місці призначення збігаються з байтами у проміжному сховищі.

Що станеться, якщо у сховищі призначення вже є файл?

Для копіювання використовується --ignore-existing, після чого виконується повна побайтова перевірка. Ідентичний об’єкт пройде перевірку, а відмінний спричинить помилку. Скрипт ніколи не перезаписує конфліктний об’єкт.

Чи може скрипт обробляти файли, більші за один пакет?

Так. Один завеликий файл утворює окремий пакет. У файловій системі проміжного сховища має бути достатньо місця для цього файлу та налаштованого локального резерву.

Чи переносяться дозволи, версії або хмарні дані спільної роботи?

Ні. Через rclone копіюються вміст файлів і шляхи. Контроль доступу, версії, мітки, коментарі, ярлики, посилання, правила зберігання та особливості роботи, притаманні постачальнику, потребують окремого планування й перевірки.

Офіційні ресурси, використані для цього посібника

Читати посібник