Both ship with OpenSSH on virtually every Linux distribution — this is a выбор привычки, а не выбор установки, и привычкой по умолчанию должен быть rsync. Разница — в состоянии: scp открывает SSH-канал, льёт байты, закрывает и ничего не помнит. rsync перед отправкой строит список контрольных сумм назначения и переносит только различающееся. Всё на этой странице следует из этого одного предложения.

ОДНА СТРОКА, С ПОЯСНЕНИЯМИ

Большинству нужна только она — каждый флаг подписан, по порядку:

завершающий слэш ловит каждого один раз — rsync даже предупреждает «no bytes transferred», когда вы имели в виду другую форму

ЧТО ДАЁТ РАЗНИЦА В СОСТОЯНИИ

scp does one thing: open an SSH channel, stream the bytes, close. No state between runs, so a transfer that dies at 90% restarts from zero and re-sends the whole 1,000 MB. rsync — инструмент синхронизации, случайно использующий SSH как транспорт: перед отправкой он строит список контрольных сумм назначения (rolling-checksum

• Обрывы : rsync возобновляет; scp перезапускает файл.
• Вторые копии : rsync шлёт только изменения; scp — всё заново.
• Удаления : rsync умеет зеркалить удаления через --delete; scp cannot.
• Фильтрация : у rsync есть шаблоны --exclude ; scp копирует всё, на что вы укажете.
• Пробные прогоны : rsync показывает, что сделает, через --dry-run; scp offers nothing.

RSYNC БЫСТРЕЕ?

Для первой копии одного крупного файла по быстрому каналу они близки — оба насыщают SSH, а проход контрольных сумм добавляет лишь небольшой накладной расход. Разрыв открывается в трёх местах:

1. Много мелких файлов. rsync конвейеризует обход каталогов и может переиспользовать одно соединение; старые scp плодили процесс на файл. Тысячи мелких файлов — node_modules, установка WordPress — заканчиваются заметно быстрее с rsync.
2. Повторные прогоны. Скопируйте файл на 4,0 ГБ, где изменилось 50 МБ, — rsync перенесёт примерно 50 МБ; scp снова тащит 4 ГБ.
3. Compression. -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/

ЗАКЛИНАНИЕ ВОЗОБНОВЛЕНИЯ

Нет, 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 app.conf user@host:/etc/myapp/ короче, чем любой вызов rsync, и возобновлять нечего.
• rsync отсутствует на дальнем конце. rsync требует своего бинарника с обеих сторон. Многие минимальные контейнеры и appliance несут SFTP-сервер scp, но не rsync.
• Не хотите открытый демон rsync. Редко, но кое-какие среды блокируют именно демон rsync.

One subtlety worth knowing: the OpenSSH project deprecated scp's original protocol years ago, and modern scp actually speaks SFTP под капотом. Это исправило причуду с экранированием путей, но не изменило ничего в двух ограничениях, которые важны — нет возобновления, нет дельта-передачи. Смена протокола не делает scp rsync'ом. А если ваш вопрос на самом деле «rsync против cp»: cp — локальный аналог scp — без возобновления, без дельты, без атрибутов без флагов — и для локальных разовых задач его достаточно.

ОПАСНЫЙ

--delete зеркалит и удаления — стирает в назначении файлы, которых больше нет в источнике. Мощно для зеркал, опасно везде остальное. Сначала пробный прогон:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # просмотреть
rsync -avh --delete src/ user@server:/srv/dest/             # затем применить

проверка: проход --dry-run печатает список удалений и ничего не меняет

Для ежедневной или еженедельной синхронизации положите rsync в systemd-таймер и позвольте копировать только дельты — журнал там, где прогоны оставляют свою историю.

ТАБЛИЦА ВЕРДИКТА

По умолчанию rsync для бэкапов, больших деревьев, всего, что идёт по каналу с обрывами, и всего, что будете запускать больше одного раза. scp — когда команда разовая и прерваться нечему — и всегда добавляйте --partial — превращает каждый будущий обрыв связи из перезапуска в паузу.

конец страницы копирования · ничего не скачано · всё локально