RcloneViewでS3マルチパートアップロードの失敗を修正する

2026年4月9日 · 約10分

Senior Engineer

S3マルチパートアップロードは大きなファイルをチャンクに分割して並列転送と再開性を実現しますが、処理中に失敗すると不完全なアップロードが残り、ストレージが無駄になり、転送がブロックされることがあります。ここではRcloneViewでの修正方法を説明します。

Amazon S3およびS3互換プロバイダー(Wasabi、Backblaze B2 S3、Cloudflare R2、MinIO、DigitalOcean Spaces)は、5GBを超えるファイルにはマルチパートアップロードを必須とし、100MBを超えるファイルには推奨しています。ファイルはパート(デフォルトで各5MBから5GB)に分割され、並列でアップロードされた後、サーバー側で組み立てられます。このプロセスがネットワークの中断、タイムアウト、またはパートサイズの設定ミスによって途中で失敗すると、ストレージを消費するものの使用可能なオブジェクトを生成しない不完全なアップロードが残ります。

すべてのクラウドを一か所で管理・同期

RcloneViewはrcloneのクロスプラットフォームGUIです。フォルダを比較し、ファイルを転送・同期し、クリーンなビジュアルインターフェースでマルチクラウドのワークフローを自動化できます。

ワンクリック操作: コピー · 同期 · 比較
信頼性の高い自動化のためのスケジューラーと履歴
Google Drive、OneDrive、Dropbox、S3、WebDAV、SFTPなどに対応

WindowsmacOSLinux

無料で始める →

コア機能は無料。Plusで自動化機能を利用可能。

よくある症状

アップロードの停止またはハング: 大きなファイルの転送が途中で止まったように見えます。RcloneViewのモニタリングでは長時間進捗が表示されません。
「EntityTooSmall」エラー: 最小サイズ(ほとんどのS3プロバイダーで5MB)より小さいパートがアップロードされました。これは通常、ファイルサイズに対してチャンクサイズの設定が小さすぎる場合に発生します。
「EntityTooLarge」エラー: 単一のパートが許容される最大サイズ(5GB)を超えています。
「InvalidPart」または「InvalidPartOrder」: パートが順不同でアップロードされたか、転送中にパートが破損しました。サーバーが完了リクエストを拒否します。
ストレージ使用量は増えるがファイルが表示されない: 不完全なマルチパートアップロードはストレージを消費します。パートはサーバー上に存在しますが、最終的なオブジェクトは組み立てられません。

修正1: チャンクサイズを調整する

マルチパート失敗の最も一般的な原因は、ファイルサイズに対するチャンクサイズの設定ミスです。S3では1つのアップロードにつき最大10,000パートまでしか許可されていません。大きなファイルに対してチャンクサイズが小さすぎると、アップロードがパート数の上限を超えて失敗します。

例: デフォルトの5MBチャンクサイズで500GBのファイルをアップロードすると、100,000パートが必要となり、10,000パートの上限を大幅に超えてしまいます。

RcloneViewでは、S3リモートの設定時、またはジョブの詳細設定でチャンクサイズを調整してください。目安として、チャンクサイズをfile_size / 10,000以上に設定します。500GBのファイルの場合は少なくとも50MBのチャンクを使用してください。ほとんどのワークロードでは、64MBから128MBのチャンクが並列性と信頼性のバランスが良好です。

これはRcloneViewのカスタムフラグフィールドで--s3-chunk-sizeフラグを使って設定できます。

修正2: アップロードのタイムアウトを増やす

低速な接続で大きなパートを転送すると、デフォルトのタイムアウトを超える場合があります。接続速度が10Mbpsより遅い場合、128MBのチャンクのアップロードに100秒以上かかることがあり、デフォルトのタイムアウト制限に近づきます。

--timeoutフラグでタイムアウトを増やしてください。例えば、--timeout 300sとすると各パートに最大5分の猶予が与えられます。個々のパートの転送を速くするために、チャンクサイズを小さくすることもできます。

修正3: 転送の並行数を減らす

同時にアップロードするパートが多すぎると、ネットワーク接続やS3エンドポイントに負荷がかかることがあります。マルチパートアップロード中に頻繁にタイムアウトや接続リセットが発生する場合は、同時転送数を減らしてください。

RcloneViewのジョブ設定で、転送数をデフォルト(4)から2、非常に大きなファイルの場合は1にまで下げます。また、--s3-upload-concurrencyを使用すると、単一ファイルの何個のパートを並列でアップロードするかを制御できます(デフォルトは4)。

修正4: 孤立したマルチパートアップロードをクリーンアップする

失敗したマルチパートアップロードは、サーバー上に孤立したパートを残し、ストレージを消費してコストが発生します。これらのパートはオブジェクトとして表示されず、RcloneViewやAWSコンソールでバケットを閲覧しても見えません。

孤立したアップロードをクリーンアップするには:

AWS S3: バケットにライフサイクルルールを設定し、指定した日数(例: 7日)後に不完全なマルチパートアップロードを自動的に中止します。これはAWSコンソールのバケットの「管理」タブで行います。
rcloneを使用する場合: RcloneViewの組み込みターミナルからrclone cleanup remote:bucketを実行します。これにより、指定したバケットの保留中のマルチパートアップロードがすべて中止されます。
S3互換プロバイダー: ほとんどのプロバイダーは同様のライフサイクルルールやクリーンアップコマンドをサポートしていますが、詳細はプロバイダーのドキュメントを確認してください。

修正5: 失敗時の再試行を有効にする

マルチパートアップロード中のネットワーク中断により、個々のパートが失敗することがあります。RcloneViewは失敗した操作を自動的に再試行します(デフォルトは指数バックオフで3回)。一時的な失敗が頻繁に発生する場合は、カスタムフラグで--retries 5または--retries 10を指定して再試行回数を増やしてください。

非常に不安定な接続の場合は、--low-level-retries 10も設定し、失敗した操作としてカウントする前に個々のHTTPリクエストを再試行するようにしてください。

修正6: 可能な場合はサーバー側コピーを使用する

同じプロバイダー上の2つのS3互換バケット間でコピーする場合、サーバー側コピーを使用するとマルチパートアップロードの問題を完全に回避できます。データはお使いのマシンを経由せず、プロバイダーのネットワーク内で移動します。RcloneViewは、送信元と送信先が同じS3プロバイダー上にある場合、自動的にサーバー側コピーを使用します。

プロバイダーをまたぐ転送(例: AWS S3からCloudflare R2へ)の場合、データはお使いのマシンを経由する必要があり、送信先側でマルチパートアップロードが適用されます。

今後の失敗を防ぐ

チャンクサイズを事前に設定する: 1GBを超えるファイルをアップロードする前に、必要なチャンクサイズ(file_size / 10,000)を計算し、カスタムフラグに設定してください。
ライフサイクルクリーンアップを有効にする: 不完全なマルチパートアップロードを中止するライフサイクルルールを必ず設定してください。これにより孤立したパートの蓄積を防げます。
転送を監視する: RcloneViewのリアルタイムモニタリングを使用して、停止したアップロードを早期に発見してください。停止した転送を一時停止して再開すると、一時的な問題が解決することがよくあります。
ドライランでテストする: 重要なアップロードでは、RcloneViewのドライランモードを使用して転送計画をコミット前に確認してください。