rsync vs scp:Linuxのコピーはどちらのコマンドを使うべきか

手早い1回限りのコピーを超えるものには rsync を、今すぐ別のマシンにファイルを置きたいだけなら scp を使ってください。 核心の違いはこうです。scp は毎回ファイル全体をストリームし、切断の記憶を一切持ちません。一方の rsync は送信元と送信先を比較し、変わったブロックだけを転送し、中断したコピーをその続きから再開します。不安定な回線での大きなバックアップでは、それが「2分で終わる」と「最初からやり直し」の差になります。どちらも実質すべてのLinuxディストロにOpenSSHとともに入っているので、これはインストールの選択ではなく習慣の選択です。そして習慣のデフォルトはrsyncであるべきです。以下:率直な比較表、実際の速度差、scpには真似できない再開の技、それでもscpが正解になるケース。

rsyncとscpの違いは何ですか?

scp のすることはひとつです。SSHチャネルを開き、バイトを流し、閉じる。実行と実行の間で状態を持たないので、転送が90%で死んだらゼロからのやり直しです。

rsync は、たまたまSSHを運搬に使う同期ツールです。送信前に宛先ファイルのチェックサムリストを作り(ローリングチェックサムのデルタアルゴリズム)、差分のブロックだけを送ります。同じコマンドを2回実行すれば、2回目はほぼ何も動きません。だからrsyncは、2つのディレクトリを同期し続ける道具としても自然です。スケジュールすれば、毎回デルタだけをコピーします。

実務上の帰結:

• 中断:rsyncは再開します。scpはファイルを最初から。
• 2回目のコピー:rsyncは変更だけ送る。scpは全部再送。
• 削除:rsyncは --delete で削除もミラーできる。scpはできない。
• フィルタ:rsyncには --exclude パターンがある。scpは指したすべてをコピー。
• ドライラン:rsyncは --dry-run で何をするか見せられる。scpには何もない。

rsyncはscpより速い?

高速な回線で大きなファイル1つを初回コピーするなら、両者は僅差です。どちらもSSHを飽和させており、チェックサムのパスが足すオーバーヘッドは小さい。差が開くのは3箇所です:

1. 小さなファイルの大量コピー。 rsyncはディレクトリ走査をパイプライン化でき、1つの接続を再利用できます。古いscpの設定はファイルごとに仕事を起こしていました。数千の小ファイル(node_modules、WordPressのインストール)は、rsyncのほうが明確に速く終わります。
2. 再実行。 4GBのファイルのうち50MBだけ変わったコピーでは、rsyncはおよそ50MBしか動かしません。scpはまた4GB動きます。
3. 圧縮。 -z は転送中に圧縮し、遅いWAN回線で効きます。

両方を自分で計時できます。コマンドの形は同じです:

# 同じファイル、同じサーバー、どちらもSSH経由
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# 両方を再実行:scpは再コピー、rsyncは検証してほぼ何も送らない
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

1日中サーバーに向き合うなら、転送速度は1度だけ計っておく価値のある類のものです。忙しいホストでは ss が netstat に勝るのと同じ理屈です(ss vs netstat:どちらのLinuxポートコマンドを使うべきか参照)。

scpは中断された転送を再開できる?

いいえ。scpに再開機能はありません。1GBのうち900MBで接続が切れたら、最初からです。rsync vs scpの議論でいちばん引用される理由であり、実際の話でもあります。

rsyncの設計全体が「転送はときどき中断される」ことを前提にしています。定番の再開の呪文がこれです:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial は途中まで書かれたファイルを消さずに残します。
• --append-verify は追記で再開し、追記領域をチェックサムで検証します。古い素の --append と違い、壊れた部分ファイルに対して安全です。
• --progress が、どこから拾ったかを見せてくれます。

リトライループに包めば、敵意的な回線ですら「セットして忘れる」バックアップになります:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

rsyncの代わりにscpを使うべきときは?

それでもscpが正解になるのは、一握りのケースです:

• 小さなファイル1つ、1回だけ。 scp app.conf user@host:/etc/myapp/ と打つほうが、どんなrsyncの起動より短い。再開するものもありません。
• 先方にrsyncがない。 rsyncは両側にバイナリを要ります。多くのミニマルなコンテナやアプライアンスは、scpのSFTPサーバーを積んでいてもrsyncを積んでいません。
• rsyncサーバーを晒したくない。 まれですが、rsyncデーモンを特に塞いでいる環境もあります。

知っておくと得な小話をひとつ。OpenSSHプロジェクトはscpの元のプロトコルを何年も前に非推奨にしていて、現代のscpは下で SFTP を話しています。これでパスエスケープの癖は直りましたが、ここで問題になる2つの制限、つまり再開なしとデルタ転送なしは、何も変わっていません。プロトコルの変更でscpがrsyncになるわけではないのです。

関連してもう1つ。問いが実は「rsync vs cp」なら、答えはこれと鏡写しです。 cp はローカル限定のscp相当(再開なし、デルタなし、フラグを足さなければ属性もなし)で、rsyncはローカルでもリモートでも動きます。ローカルの1回きりなら cp で十分です。

重要なrsyncのフラグはどれ?

ほとんどの人に必要なのは1行だけです:

rsync -avh --partial --progress src/ user@server:/srv/dest/

フラグ	何をするか
-a(archive)	再帰 + パーミッション、タイムスタンプ、グループ、symlink、デバイスを保持
-v(verbose)	転送するものを一覧表示
-h(human)	人間が読めるサイズ表記
--partial	部分転送ファイルを残し、再実行で再開できるようにする
--progress	ファイルごとの進捗表示 — scpに決してなかったもの
-z	転送中に圧縮(CPUが遅くLANが速いなら:外せ)
--delete	削除もミラー — 危険、必ずドライランとセットで
--dry-run(-n)	何が起きるかを見せるだけで、何も変えない

取り入れる価値のある習慣が2つあります。1つ目は、 --delete が入るものは必ずドライランする:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # 確認
rsync -avh --delete src/ user@server:/srv/dest/             # そのあとに実行

2つ目は、末尾のスラッシュに気をつけること。 /srv/src はディレクトリそのものを宛先へコピーし、/srv/src/ はその 中身 をコピーします。全員が1度は引っかかります。rsyncは、別の形のつもりだったときに「no bytes transferred」とまで警告してくれます。

毎日か毎週の同期なら、rsyncをsystemd timerへ放り込んで、デルタだけをコピーさせましょう。スケジューリングのjournalctl側はjournalctlチートシートで扱っています。

rsync vs scp:結論

	scp	rsync
OpenSSH同梱	はい	はい(両端に必要)
中断転送の再開	いいえ	はい(--partial)
再実行時のデルタ転送	いいえ	はい
パーミッション/symlinkの保持	一部	完全(-a)
除外パターン	いいえ	--exclude
ドライラン	いいえ	--dry-run
削除のミラー	いいえ	--delete
向いている用途	手早い1回限りのコピー	バックアップ、同期、大きなツリー

バックアップ、大きなツリー、切れ得る回線越しのもの、2回以上実行するもの — デフォルトはrsyncです。scpを使うのは、コマンドのほうが思考より短いとき。1つだけフラグを持ち帰るなら --partial にしてください。これが、今後の接続切断をすべて「やり直し」ではなく「一時停止」に変えてくれます。