中断したファイル転送を途中から再開する｜rsync/curlのレジューム運用【2026年版】

大容量のISOイメージやバックアップアーカイブを転送している最中に、ネットワーク断やタイムアウトが発生した経験は多くの運用者にあるはずです。数十GBの転送が9割終わったところで中断すると、最初からやり直す時間的コストは無視できません。Linux環境では curl と rsync のいずれもレジューム（途中再開）に対応しており、適切なオプションを指定するだけで中断箇所から処理を引き継げます。本記事では転送が中断する代表的な原因を整理したうえで、curl・rsync それぞれのレジューム手順、再開後の整合性検証、そして万が一に備えた切り戻し手順まで一貫して解説します。

転送が中断する代表的な原因と「再開」の考え方

ファイル転送が途中で止まる原因は大きく三つに分類できます。

• ネットワーク起因：ISPの瞬断・VPNセッション切れ・ファイアウォールのアイドルタイムアウトなど
• サーバー起因：転送元サーバーの再起動・ディスクI/O負荷によるソケットリセットなど
• クライアント起因：誤ったシグナル送信・シェルセッションの切断・ターミナルマルチプレクサの設定不備など

「途中から再開できる」というのは、受信側がすでに受け取ったバイト数をサーバー側に伝え、その続きだけを転送してもらう仕組みです。HTTPでは Range ヘッダー、rsyncでは差分転送アルゴリズムがこれを担います。どちらの場合も、再開前に「既存の部分ファイルが壊れていないか」を確認することが安全運用の前提になります。

curlで中断したダウンロードを再開する

HTTP/HTTPS経由のダウンロードには curl の -C -（続き取得）オプションが最もシンプルです。ハイフン一つは「ローカルに残ったファイルのサイズを自動検出して続きを要求する」という意味で、バイト数を明示する必要がありません。

# 通常のダウンロード（途中で Ctrl+C などにより中断したとする）
curl -O https://example.com/large-archive.tar.gz

# 再開：-C - でオフセットを自動検出
curl -C - -O https://example.com/large-archive.tar.gz

サーバーが Accept-Ranges: bytes を返さない場合、curlは「HTTP server doesn't seem to support byte ranges」と警告して処理を中断します。このときは最初から取り直しが必要です。主要なオブジェクトストレージ（S3互換・Google Cloud Storageなど）やCDNはRangeリクエストを標準でサポートしているため、現場での問題になるケースは限られます。

長時間の転送では --retry と --retry-delay を組み合わせると、短期間の瞬断であれば自動で再試行し、再開まで無人で対応できます。進捗を視認したい場合は --progress-bar も加えておくと便利です。

curl -C - -O --retry 5 --retry-delay 10 --progress-bar \
  https://example.com/large-archive.tar.gz

rsyncで転送を途中から再開する

サーバー間のファイルコピーやバックアップ転送では rsync が広く使われています。rsyncはデフォルトで差分転送を行いますが、「転送途中で中断したファイル」を次回起動時に続きから再開させるには --partial オプションが必要です。このオプションを省略すると、中断された不完全なファイルは転送終了後に削除され、次回は最初から送り直しになります。

# -P は --progress --partial の省略形。手動実行時はほぼこの形で十分
rsync -avP user@remote:/data/large-backup.tar.gz /backup/

スクリプトやcronで自動実行する場合は、中断ファイルを専用ディレクトリに隔離しておく --partial-dir を使う方が管理しやすくなります。完全に転送が終わったファイルだけが目的ディレクトリに置かれるため、不完全ファイルを誤って参照するリスクを排除できます。

rsync -av --partial-dir=.rsync-partial \
  user@remote:/data/large-backup.tar.gz /backup/

ディレクトリ全体を同期する場合は --append-verify も検討できます。既存ファイルの末尾に追記する形で再開し、完了後にチェックサムで全体を検証します。ただしファイルの途中が書き換わっているケース（ログローテーション中のファイルなど）では誤検知することがあるため、静的なアーカイブファイルの再開に限って使うのが無難です。

再開後の整合性検証

転送を再開して完了したとしても、ファイルが壊れていないかを確認するまでが運用の一連の手順です。転送元でチェックサムを生成しておき、受信側で照合するのが確実な方法です。

# 転送元でチェックサムを生成（SHA-256 推奨）
sha256sum large-backup.tar.gz > large-backup.tar.gz.sha256

# チェックサムファイルも転送する
rsync -avP user@remote:/data/large-backup.tar.gz.sha256 /backup/

# 受信側で検証
sha256sum -c /backup/large-backup.tar.gz.sha256

出力に OK が表示されれば整合性は確認できています。FAILED が出た場合は部分ファイルが破損している可能性があり、中断ファイルを削除して最初から転送し直す必要があります。

rsync自体にも --checksum（-c）オプションがあり、ファイルサイズ・更新日時ではなくチェックサムで差分を判断します。ただし全ファイルのハッシュ計算が発生するため、ファイル数が多いと処理時間が大幅に伸びます。定期バックアップの差分同期には向かず、「最終確認として一度だけ走らせる」用途に留めるのが現場での運用感覚です。

切り戻し手順と運用上の注意点

レジューム運用では以下の点に注意が必要です。

• 転送元ファイルが更新された場合：中断から再開までの間に転送元ファイルが置き換えられると、前半と後半でバージョンが混在した壊れたファイルが完成します。チェックサム検証が必須である理由の一つです。
• ストレージ空き容量：--partial-dir を使う場合、中断ファイルと最終ファイルが一時的に共存するため、ファイルサイズの約2倍の空き容量が必要になります。
• SSHセッションのタイムアウト：rsync over SSHでは、長時間の転送中にSSHセッションがタイムアウトすることがあります。~/.ssh/config に ServerAliveInterval 60 を設定するか、-e "ssh -o ServerAliveInterval=60" をオプションに加えると対処できます。

チェックサムが合わず再転送が必要になった場合の切り戻し手順は以下のとおりです。

# 壊れた中断ファイルを削除
rm /backup/large-backup.tar.gz

# --partial-dir の残骸もクリア
rm -rf /backup/.rsync-partial/

# 最初から転送し直す
rsync -avP user@remote:/data/large-backup.tar.gz /backup/

2026年の現行環境での差分・補足

旧来の記事ではFTPクライアントの reget コマンドを使った手順が紹介されていましたが、FTPは認証情報が平文で流れる設計のため、現在の運用環境では原則使用されていません。HTTP/HTTPS・SCP/SFTP・rsync over SSHが主流であり、本記事の手順がそのまま現場に適用できます。

2024年以降に採用が広がっている rclone は、S3・Google Drive・Azure Blobなど多様なバックエンドに対応したツールです。rclone copy はデフォルトで途中再開を考慮した設計になっており、チェックサム検証も組み込まれています。クラウドストレージとの転送が増えた現場ではrcloneへの移行も有力な選択肢になります。

また、systemdの Type=oneshot サービスとして転送スクリプトを管理する構成も一般的になっています。Restart=on-failure と RestartSec=30 を組み合わせると、一時的なネットワーク断であれば自動で再起動が走るため、深夜バッチ転送の監視負荷を下げられます。

[Unit]
Description=Large file transfer with resume

[Service]
Type=oneshot
ExecStart=/usr/local/bin/transfer.sh
Restart=on-failure
RestartSec=30
StartLimitIntervalSec=300
StartLimitBurst=5

スクリプト内で rsync -avP --partial-dir=.rsync-partial を呼び出せば、systemdが失敗を検知するたびに途中から再開する構成が完成します。定常的に大容量ファイルを扱う環境では、一度テンプレート化しておくと運用コストを大きく削減できます。