Bash と rclone によるコピー専用のクラウド転送

簡単な回答

大規模な移行や無人での移行には、よりシンプルなマネージド型の選択肢として FileArk を利用できます。転送をオンラインで実行し、複数テラバイト規模の処理でテストされており、完了前に各結果を確認します。データ経路をシェルから制御したい運用担当者向けには、この MIT ライセンスの Bash ラッパーが、上限を設定したバッチをローカルステージング経由でコピーし、両区間をバイト単位で検証します。ソースファイルを削除することはありません。

プロバイダーごとのクライアントを再構築せず、rclone をラップする理由

rclone は、シェルのワークフローに成熟したプロバイダー抽象化、OAuth 設定、ページネーション、再試行処理、再開可能な転送、同時実行制御、インベントリコマンド、検証コマンドを提供します。そのためラッパーは、コピー専用の動詞、上限付きのステージング、容量リザーブ、再現可能なファイルリスト、永続的な進捗記録といった、移行時に維持すべき条件に集中できます。

ただし、それだけで処理が自動化されるわけではありません。リモート設定、トークンのセキュリティ、ネットワークの稼働状況、プロセスの監視、ローカルディスク、ログ、プロバイダーの制限、失敗したオブジェクトの確認、転送先の受け入れ確認は、引き続き運用担当者が管理する必要があります。FileArk は、この手順をワークステーションやサーバー上ではなく、マネージドなオンラインワークフローとして実行したいユーザー向けのサービスです。

このスクリプトは、rclone move、sync、delete、purge、rmdirs を明示的に一切呼び出しません。検出には lsf と about、各区間のコピーには copy、全バイト検証には check --download を使用します。削除されるのは、ローカルステージングディレクトリ内の検証済みファイルだけです。

Bash 版と MIT ライセンスをダウンロード

ネットワーク接続不要の運用者向けデモを実行する

このデモでは、引数解析の段階で依存関係の確認前に終了するため、rclone や jq をインストールする前でも安全に実行できます。出力には、禁止されている破壊的操作と2種類の容量リザーブが示され、最後にソースの削除件数が表示されます。

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: など、それぞれ異なる名前のリモートを2つ作成します。ポリシーまたはレート制限により専用の OAuth アプリケーションが必要な場合は、ご自身のプロバイダーのクライアント ID とシークレットを入力してください。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

データ転送前に再現可能なインベントリを確定する

ラッパーは、明示的なタブ区切りと sp 形式を指定して rclone lsf を再帰的に実行し、サイズ、パスの順で出力します。各サイズが数値であり、各パスが相対パスであることを検証してから、検証済みチェックポイントにすでに存在するパスを除外します。

改行区切りの --files-from-raw リストでは、タブ、キャリッジリターン、改行を含むファイル名を曖昧さなく表現できないため、Bash 版はそのようなファイル名を拒否します。該当する名前がある場合は、Python 版または専用のインベントリ形式を使用してください。

パスによるチェックポイントは、意図的に単純で確認しやすい設計になっています。実行中にソースパスが変わらないことを前提としています。可能であればソースへの書き込みを停止してください。同時変更が予想される場合は、インベントリを再生成して差異を照合してください。

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

\t' > "$inventory"

バッチが予約容量を消費する前に処理を中止する

ローカルの空きバイト数は、ステージング先のファイルシステムに対する df から取得します。転送先の空きバイト数は rclone about --json から取得します。free が返された場合はその値を使用し、それ以外の場合は total から used を差し引きます。処理前に保留中データの合計バイト数を確認し、さらに各バッチの開始前にもローカルと転送先の容量を再確認します。

一部のプロバイダーまたはアカウント種別では、rclone を通じて有限のクォータが公開されません。ラッパーはこの制限を表示し、プロバイダー側の制限に従って処理を続行します。これは十分な空き容量があることの証明ではなく、監視が必要な状態として扱ってください。

バッチ上限は、1つのオブジェクトに対する絶対的な最大値ではありません。設定したバッチサイズより大きい単一ファイルは、それだけで1つのバッチを構成できます。そのため、ローカルの空き容量には、最大ファイルのサイズとリザーブの合計が必要です。転送先の完全検証では転送先からデータをバイト単位で読み取りますが、rclone 版ではローカルに2つ目のコピーを保持しません。

ローカルステージング境界の両側を検証する

各バッチは、独立した2つの区間を通過します。まず rclone が --ignore-existing を使用して、選択したソースパスをローカルステージングにコピーします。次に check --download が両側のデータを読み取り、実際の内容を比較します。続いて rclone がステージング済みのパスを転送先へコピーし、同じ全バイト検証を繰り返します。

--ignore-existing により、中断した実行でも既存オブジェクトが上書きされないため、データを破壊せずに済みます。ただし、パスをチェックポイントに記録する前に、検証に合格する必要があります。転送先の既存ファイルが異なる場合は rclone check が失敗し、Bash の厳格なエラー処理によって実行が停止します。

--download を使用すると処理が遅くなり、プロバイダー側の送信／読み取り操作を消費しますが、2 つのプロバイダーが共通のハッシュアルゴリズムを提供しているかどうかだけに依存せずに済みます。このコマンドはどちら側も変更しません。

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ファイルを上限とし、4件の転送を同時に実行します。転送先のコンテンツは、日付を付けた新しいフォルダー内に書き込まれます。

最初に --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 ネイティブの Docs、Sheets、Slides、およびその他の仮想形式では、rclone のエクスポート設定と慎重な確認が必要です。テスト用データセットを使って、エクスポート後の拡張子と変換動作を確認してください。シェルによるコピーでは、Google の共同編集履歴、ショートカット、権限、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

転送先の検証後にのみチェックポイントへ記録する

転送先の検証が正常終了すると、ラッパーは各相対パスをプレーンテキストのチェックポイントに追記します。その後、該当ファイルをローカルステージングから削除し、空になったローカルディレクトリも削除します。ソースリモートは変更されません。

チェックポイントは実行中に追記のみが行われ、標準ツールで簡単に監査できます。コマンドライン、rclone のバージョン、設定のフィンガープリント、インベントリ、ログ、タイムスタンプ、受け入れ確認の記録とともに保存してください。転送先ファイルを別途検証していない限り、失敗を隠す目的で編集しないでください。

パスだけを記録するチェックポイントでは、パスが変わらず内容だけが変更されたソースオブジェクトを検出できません。変更される可能性があるデータセットでは、書き込みを停止し、プロバイダー ID と変更メタデータを別途記録するか、Python 版のより厳密な ID とサイズによるチェックポイントを使用してください。規制対象または共同作業用データの移行には、明示的な変更管理を備えたマネージドワークフローを使用してください。

ゼロ以外の終了コードはすべて未解決のバッチとして扱う

• 厳格モードでは、コマンドやパイプラインが失敗した場合、または未設定の変数がある場合に終了します。一時インベントリディレクトリは自動的に削除されます。
• 一時的な転送エラーは rclone が再試行しますが、権限、クォータ、ネットワーク、競合、整合性に関するエラーが解消しない場合は、バッチが停止します。
• チェックポイントに未記録のステージング済みファイルは確認できる状態で残り、同じ条件で再実行すると、バイトを検証する前に --ignore-existing が使用されます。
• 内容が異なる転送先ファイルが上書きされることはありません。競合を解消するか、空の転送先ルートを選択してください。
• 失敗したコピーを rclone sync や move に切り替えないでください。これらのコマンドでは削除の動作が異なります。
• 転送先の手動受け入れ確認が完了するまで、ログとチェックポイントを保持してください。

データプレーンとなるホストを保護する

ステージングホストには、読み取り可能なソースデータのコピーと OAuth リフレッシュトークンが一時的に保存されます。ディスク全体の暗号化、制限の厳しいファイル権限、専用のオペレーティングシステムアカウント、パッチ適用済みの依存関係、管理者アクセスの制御を使用してください。また、ステージング内容が意図せず保持されない暗号化バックアップポリシーを採用してください。

プロセス一覧やシェル履歴から漏洩する可能性があるため、コマンドラインにシークレットを指定しないでください。rclone の保護された設定では保存中のトークンを難読化できますが、ホストのセキュリティに代わるものではありません。移行の受け入れ確認後は、保持ポリシーに従ってトークン情報とステージングの残存データを削除してください。

プロバイダーの監査ログ、ネットワークの送信トラフィック、ディスクの状態、inode の空き、プロセスの状態、rclone の出力を監視してください。ターミナルを開いたままにするだけではプロセス監視にはなりません。承認済みのサービスマネージャーまたはターミナルマルチプレクサーを使用し、ログを永続的に保存してください。

コマンドの成功表示ではなく、証跡をもって移行を完了する

• 確定したインベントリ、実行した正確なコマンド、スクリプトのチェックサム、rclone のバージョン、リモート設定のフィンガープリント、検証済みチェックポイントをアーカイブします。
• ドライブ全体の合計だけでなく、フォルダーごとにファイル数と把握済みのバイト数を照合してください。
• 大きいファイル、小さいファイル、古いファイル、新しいファイル、Unicode を含むファイル、深い階層にあるファイル、アーカイブ済み文書、変換済み文書から、リスクに応じて抽出したサンプルを開いて確認します。
• 代表的なユーザーアカウントから転送先へのアクセスをテストし、必要な共有設定を別途再作成します。
• スキップされたパッケージ、ショートカット、リンク、プロバイダー固有形式の文書、競合、プロバイダーからの警告を確認します。
• ソースを併存させる期間を設け、その後の保持または削除を決定する前に、所有者から明示的な承認を得てください。

よくある質問

Bash スクリプトで sync ではなく rclone copy を使用するのはなぜですか？

コピーでは、ソースのオブジェクトも、ソースに存在しない転送先のオブジェクトも削除しません。同期では照合と削除の動作が異なるため、このワークフローでは意図的に対象外としています。

rclone check --download はいずれかのクラウドを変更しますか？

いいえ。ファイルの内容を読み取って比較します。スクリプトは各コピー工程の後にこれを使用し、転送先のバイト列がステージング上のバイト列と一致した場合にのみ、そのパスをチェックポイントに記録します。

転送先にすでにファイルが存在する場合はどうなりますか？

コピーでは --ignore-existing を使用し、その後に全バイトを検証します。同一のオブジェクトであれば検証に合格しますが、異なるオブジェクトの場合は失敗します。スクリプトが競合ファイルを上書きすることはありません。

1バッチの上限を超えるファイルもスクリプトで処理できますか？

はい。上限サイズを超えるファイルは、単独で 1 つのバッチになります。ステージング用ファイルシステムには、そのファイルと設定済みのローカル予約容量を合わせた空き容量が必要です。

権限、バージョン、クラウドネイティブの共同編集データも移行されますか？

いいえ。rclone を介してファイルの内容とパスをコピーします。アクセス制御、バージョン、ラベル、コメント、ショートカット、リンク、保持ルール、プロバイダー固有の動作については、別途計画と検証が必要です。

このガイドで参照した公式情報

• Google Workspace ラーニング センター：OneDriveからGoogle Driveへの移行
• Google Drive ヘルプ：保存容量とファイルの動作
• Microsoft サポート：OneDriveへのファイルのアップロードと保存
• rclone copy コマンドのリファレンス
• rclone check と全バイト検証
• rclone lsf のインベントリ形式
• rclone about のクォータ出力