rsync против scp — какая команда копирования и когда
rsync помнит, scp забывает: строка с пояснениями, возобновление через --partial --append-verify, дельта на повторах и таблица вердикта — каждая команда работает как есть.
Both ship with OpenSSH on virtually every Linux distribution — this is a выбор привычки, а не выбор установки, и привычкой по умолчанию должен быть rsync. Разница — в состоянии: scp открывает SSH-канал, льёт байты, закрывает и ничего не помнит. rsync перед отправкой строит список контрольных сумм назначения и переносит только различающееся. Всё на этой странице следует из этого одного предложения.
rsync для бэкапов, больших деревьев, всего, что будете запускать больше одного раза — scp для одного маленького файла, один раз.
scp cannot resume : обрыв на 900 МБ из 1 ГБ — не хватает 100 МБ — начинается с нуля. rsync с --partial --append-verify превращает этот перезапуск в паузу.
On re-runs rsync moves только изменённые блоки; scp re-sends everything. The one flag to take away: --partial.
ОДНА СТРОКА, С ПОЯСНЕНИЯМИ
Большинству нужна только она — каждый флаг подписан, по порядку:
завершающий слэш ловит каждого один раз — 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, а проход контрольных сумм добавляет лишь небольшой накладной расход. Разрыв открывается в трёх местах:
- Много мелких файлов. rsync конвейеризует обход каталогов и может переиспользовать одно соединение; старые scp плодили процесс на файл. Тысячи мелких файлов —
node_modules, установка WordPress — заканчиваются заметно быстрее с rsync. - Повторные прогоны. Скопируйте файл на 4,0 ГБ, где изменилось 50 МБ, — rsync перенесёт примерно 50 МБ; scp снова тащит 4 ГБ.
- 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-таймер и позвольте копировать только дельты — журнал там, где прогоны оставляют свою историю.
ТАБЛИЦА ВЕРДИКТА
| scp | rsync | |
|---|---|---|
| Поставляется с OpenSSH | Yes | Да (нужны оба конца) |
| Возобновление прерванной передачи | No | Да (--partial) |
| Дельта-передача на повторах | No | Yes |
| Сохраняет права/симлинки | Частично | Полностью (-a) |
| Шаблоны исключения | No | --exclude |
| Пробный прогон | No | --dry-run |
| Зеркалит удаления | No | --delete |
| Лучше всего для | Быстрые разовые копии | Бэкапы, синхронизации, большие деревья |
По умолчанию rsync для бэкапов, больших деревьев, всего, что идёт по каналу с обрывами, и всего, что будете запускать больше одного раза. scp — когда команда разовая и прерваться нечему — и всегда добавляйте --partial — превращает каждый будущий обрыв связи из перезапуска в паузу.
конец страницы копирования · ничего не скачано · всё локально