Linuxで複数ファイルをまとめて転送する実務｜FTPからsftp/rsyncへ移行する【2026年版】

FTPはなぜ現場から消えつつあるのか

かつてLinux環境でのファイル転送といえばFTPが標準的な選択肢でした。ftpコマンドのmgetで複数ファイルをまとめてダウンロードする手順は、長年にわたって定番として使われてきました。しかし2026年現在、新規構築の現場でFTPを採用するケースは急速に減っています。

理由は明快です。FTPはパスワードを含むすべての通信を平文で送受信します。ネットワーク上でパケットキャプチャされれば、認証情報がそのまま漏洩します。さらに、多くのLinuxディストリビューションは標準でFTPクライアント・サーバーをインストールしなくなっており、追加パッケージを明示的に導入しなければ使えません。

現行標準はsftp（SSH File Transfer Protocol）とrsync（over SSH）の2本柱です。どちらもSSH暗号化を前提とし、鍵認証と組み合わせることで安全な自動化も実現できます。本記事ではFTPのmget相当の操作から始め、実務でよく使う複数ファイル転送のシナリオを順に説明します。

sftpで複数ファイルをまとめて取得する

sftpはSSHセッション上で動作するファイル転送プロトコルです。インタラクティブなシェルを起動してFTPに近い操作感で使えるほか、バッチ処理にも対応しています。OpenSSHに標準で同梱されているため、追加インストールは不要です。

インタラクティブモードで複数ファイルを取得する

FTPのmgetに相当するのが、sftp内のgetコマンドにワイルドカードを組み合わせる方法です。

# sftpでリモートホストに接続
sftp user@remote.example.com

# 接続後、対象ディレクトリへ移動
sftp> cd /var/www/uploads

# ワイルドカードで複数ファイルをまとめてローカルへ取得
sftp> get *.log /tmp/logs/

# 接続を終了
sftp> bye

FTPのpromptコマンドで確認ダイアログを抑制していたのと同様に、sftpではワイルドカード指定時に個別確認が入らず一括取得できます。ローカルのダウンロード先ディレクトリはあらかじめ作成しておく必要があります。

バッチモードで自動化する

定期実行や自動化が必要な場面では、バッチファイルを使ったノンインタラクティブ実行が有効です。

# バッチファイルを作成
cat <<'EOF' > /tmp/sftp_batch.txt
cd /var/www/uploads
get *.log /tmp/logs/
bye
EOF

# SSH鍵認証でバッチ実行（確認プロンプトなし）
sftp -b /tmp/sftp_batch.txt -i ~/.ssh/id_ed25519 user@remote.example.com

バッチモードは-bオプションで指定します。パスワード認証では対話が発生するため自動化できません。SSH鍵ペアをあらかじめssh-keygenで生成し、ssh-copy-idでリモートに登録しておくことが前提になります。

rsyncで複数ファイルを効率よく同期する

転送量が多くなるほど、rsyncの強みが際立ちます。rsyncは差分転送アルゴリズムを持っており、前回転送済みのファイルは再送しません。ログの定期収集やWebコンテンツのデプロイなど、繰り返し実行が前提の用途では実質的な標準ツールとして定着しています。

基本的な複数ファイル転送

リモートからローカルへ複数ファイルを取得する基本パターンです。初回実行前に--dry-run（短縮形：-n）で対象ファイルを確認する習慣が、現場では広く定着しています。

# まず --dry-run で対象を確認（実際には転送しない）
rsync -avzn user@remote.example.com:/var/www/uploads/ /tmp/uploads/

# 問題なければ -n を外して実行
rsync -avz user@remote.example.com:/var/www/uploads/ /tmp/uploads/

# 特定の拡張子だけを対象にする
rsync -avz --include='*.log' --exclude='*' \
  user@remote.example.com:/var/log/ /tmp/logs/

-aはアーカイブモード（パーミッション・タイムスタンプを保持）、-vは詳細出力、-zは転送時圧縮です。--include/--excludeの順序は重要で、記述した順に評価されます。マッチしなかったファイルはデフォルトで転送対象になるため、最後に--exclude='*'を置いて除外する書き方が定番です。

ローカルからリモートへのアップロード

送信方向を逆にするには引数の順序を入れ替えるだけです。デプロイ用途では--deleteを組み合わせてリモートをローカルと完全に一致させることができますが、誤削除のリスクがあるため、こちらも必ず--dry-runで先に確認します。

# ローカルのファイル群をリモートへ転送（--delete 使用前は必ずdry-run）
rsync -avzn --delete /var/www/html/ user@remote.example.com:/var/www/html/

# 確認後、本番実行
rsync -avz --delete /var/www/html/ user@remote.example.com:/var/www/html/

ディレクトリパス末尾のスラッシュの有無で挙動が変わります。送信元に/を付けると「ディレクトリの中身」を転送し、付けないと「ディレクトリ自体」を転送します。この仕様は初学者が誤りやすいポイントなので、実行前のdry-runで対象パスを必ず目視確認してください。

転送後の整合性を検証する

ファイルが届いたことを確認するだけでなく、内容が破損していないかを検証するステップが実務では欠かせません。特にバイナリファイルや圧縮アーカイブの場合、転送途中のビット化けは後工程で初めて発覚することがあります。

# 転送元でチェックサムを生成して保存
ssh user@remote.example.com \
  "sha256sum /var/www/uploads/*.log" > /tmp/remote_checksums.txt

# ローカルで同じチェックサムを生成
sha256sum /tmp/uploads/*.log > /tmp/local_checksums.txt

# ハッシュ値だけ抽出して比較
awk '{print $1}' /tmp/remote_checksums.txt | sort > /tmp/remote_hash.txt
awk '{print $1}' /tmp/local_checksums.txt  | sort > /tmp/local_hash.txt
diff /tmp/remote_hash.txt /tmp/local_hash.txt && echo "OK: チェックサム一致"

rsync自身に検証を任せる方法もあります。--checksumオプションを付けると、タイムスタンプではなくファイル内容のチェックサムで差分を判断します。大量ファイルの再同期時に転送の正確性を担保したい場合に有効ですが、全ファイルのチェックサム計算が走るためCPU負荷が上がります。用途に応じて使い分けてください。

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

複数ファイルを一括操作するときは、誤転送や上書きのリスクが単一ファイル操作よりも大きくなります。現場で積み上げられてきた注意点を整理します。

• rsyncの--deleteは本番前に必ずdry-runで確認する。ディレクトリ末尾スラッシュの有無で対象の解釈が変わるため、意図しない削除が起きやすいポイントです。
• sftpのバッチファイルには絶対パスを明示する。相対パスを使うとカレントディレクトリの解釈がセッションによって変わる場合があります。
• 転送後に元ファイルを削除する場合は段階的に進める。転送と検証を完了させ、問題がないことを確認してから削除します。rsyncの--remove-source-filesはファイル単位の削除（ディレクトリ構造は残る）ですが、確認ステップを省くと取り返しがつきません。
• 切り戻し用のバックアップを事前に取る。rsyncでコンテンツをデプロイする前に、転送先の現状をtarで固めておくか、LVMスナップショットを作成しておくと安全です。
• 長時間の転送はtmuxかscreenの中で実行する。sftp・rsyncともにSSHセッション切断で転送が中断します。rsyncは再実行で差分のみ転送するためリジューム相当の動作をしますが、sftpバッチは途中再開の機能を持ちません。

2026年の現行環境での差分と確認事項

OpenSSH 9系（Ubuntu 24.04・Debian 12の標準）では、旧来のRSA鍵（特に1024ビット）の使用がデフォルトで拒否されるようになっています。新規に鍵を生成する場合はed25519が推奨です。

# 推奨：ed25519鍵を生成する
ssh-keygen -t ed25519 -C "ops@example.com"

# リモートに公開鍵を登録
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote.example.com

RHEL 9 / AlmaLinux 9 / Rocky Linux 9環境ではSHA-1を使った鍵交換がデフォルトで無効になっています。古いサーバーと接続する際に「no matching key exchange method found」といったエラーが出た場合は、接続先のOpenSSHバージョンを確認し、可能なら更新することが先決です。クライアント側で一時的に許可する設定も存在しますが、古いバージョンへの依存自体をセキュリティリスクとして管理する視点が重要です。

rsyncについては、バージョン3.2以降でXXHash（--checksum-choice=xxh128）に対応し、チェックサム計算の速度が大幅に向上しています。Ubuntu 22.04以降や最新のRHEL系では標準リポジトリのrsyncが3.2系になっているため、rsync --versionでバージョンを確認したうえで積極的に活用できます。

古い記事でよく見かけるFTPのmgetやpassiveモード切り替えは、2026年時点では新規構築の現場でほぼ見かけません。既存環境でVSFTPdやProFTPdが稼働している場合も、段階的にSFTPサブシステム（OpenSSHに内蔵）へ移行することが、メンテナンスコストとセキュリティの両面で合理的な選択です。移行の際は本記事で紹介した手順を参考に、dry-runと整合性検証を組み合わせながら慎重に進めてください。