rsync чи scp: якою командою копіювати в Linux

Використовуйте rsync для всього, що більше за швидку разову копію, і scp, коли файл просто треба мати на іншій машині вже зараз. Головна різниця: scp щоразу заново переливає цілий файл і не пам’ятає про обірваний зв’язок, тоді як rsync порівнює джерело з призначенням, переносить лише змінені блоки і продовжує перервану копію з місця зупинки. На великому бекапі через кволу лінію це різниця між «дві хвилини» і «починай спочатку». Обидва йдуть у комплекті з OpenSSH майже в кожному Linux-дистрибутиві, тож це вибір звички, а не інсталяції — і звичка має за замовчуванням ставити на rsync. Нижче: пряма таблиця порівняння, реальні різниці швидкості, трюк із відновленням, який scp не вміє, і випадки, коли scp досі правильна відповідь.

У чому різниця між rsync і scp?

scp робить одне: відкриває SSH-канал, ллє байти, закриває. Між запусками стану немає, тож якщо передача померла на 90%, стартуєте з нуля.

rsync — інструмент синхронізації, який так вийшло, що їздить на SSH як транспорті. Перед відправкою він будує список контрольних сум файлу на призначенні (дельта-алгоритм з rolling-checksum) і передає лише блоки, що відрізняються. Запустіть команду двічі — другий прохід майже нічого не тягне. Саме тому rsync — природний інструмент тримати дві теки синхронними: поставте в розклад, і кожен запуск копіює тільки дельти.

Практичні наслідки:

• Переривання: rsync продовжує; scp починає файл заново.
• Повторні копії: rsync шле лише зміни; scp пересилає все.
• Видалення: rsync вміє дзеркалити видалення через --delete; scp ні.
• Фільтрація: у rsync є патерни --exclude; scp копіює все, на що покажете.
• Dry run: rsync показує намір через --dry-run; scp нічого не пропонує.

Чи rsync швидший за scp?

Для першої копії одного великого файлу через швидку лінію — майже паритет: обидва насичують SSH, а прохід контрольних сум додає малий оверхед. Розрив відкривається у трьох місцях:

1. Дрібні файли кулями. rsync конвеєрує обходи тек і вміє перевикористовувати одне з’єднання; старіші налаштування scp породжували роботу на кожен файл. Тисячі дрібних файлів (a node_modules, вордпресова інсталяція) закінчуються помітно швидше з rsync.
2. Повторні запуски. Скопіюйте файл на 4 ГБ, у якому змінилося 50 МБ — rsync прокотить близько 50 МБ; scp знову волоче 4 ГБ.
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/

Якщо ваш день минає на серверах, швидкість передачі — з тих речей, які варто заміряти один раз, так само як ss обійдає netstat на завантажених хостах (дивіться ss vs netstat: якою командою дивитися порти).

Чи вміє scp продовжити перервану передачу?

Ні. У scp немає продовження: якщо з’єднання впало на 900 МБ із 1 ГБ, стартуєте заново. Це найцитованіший аргумент у кожній суперечці rsync-проти-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

Коли все ж брати scp замість rsync?

scp досі правильний інструмент у кількох випадках:

• Один малий файл, один раз. Набрати scp app.conf user@host:/etc/myapp/ коротше за будь-який виклик rsync, і продовжувати нема чого.
• rsync відсутній на дальньому кінці. rsync потребує свого бінарника з обох боків. Багато мінімальних контейнерів і пристроїв мають SFTP-сервер scp, але не rsync.
• Ви не хочете відкритого rsync-сервера. Рідко, але деякі середовища закручують гайки саме навколо демона rsync.

Тонкість, варта знання: проєкт OpenSSH роки тому депреціював оригінальний протокол scp, і сучасний scp насправді говорить SFTP під капотом. Це виправило хитрість з виходом зі шляхів, але нічого не змінило у двох обмеженнях, що тут важливі — без продовження, без дельта-передачі. Зміна протоколу не робить scp з rsync.

Також по темі: якщо ваше питання насправді «rsync vs cp», відповідь дзеркалить цю — cp є локальний аналог scp (без продовження, без дельт, без атрибутів без прапорців), а rsync працює і локально, і віддалено. Для локальних разових дій cp — нормально.

Які прапорці rsync найважливіші?

Більшості людей завжди достатньо одного рядка:

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

Прапорець	Що робить
-a (архів)	Рекурсивно + зберігає права, часи, групу, симлінки, девайси
-v (багатослівний)	Перелічує, що передає
-h (людський)	Розміри, читабельні для людини
--partial	Тримає частково передані файли — повторний запуск продовжить
--progress	Прогрес по файлах — те, чого scp не мав ніколи
-z	Стискання в дорозі (повільні CPU на швидкій LAN: пропустіть)
--delete	Дзеркалить і видалення — небезпечно, завжди сполучайте з dry run
--dry-run (-n)	Показати, що станеться, нічого не змінюючи

Дві звички, які варто взяти. Перша: dry-run для всього, де є --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # огляньте
rsync -avh --delete src/ user@server:/srv/dest/             # потім виконуйте

Друга: слідкуйте за замикаючим слешем — /srv/src копіює саму теку в призначення, а /srv/src/ копіює її вміст. На цьому спотикаються всі по одному разу; rsync навіть попереджає «no bytes transferred», коли ви мали на увазі іншу форму.

Для щоденної чи тижневої синхронізації покладіть rsync у systemd timer і дайте йому тягти лише дельти — journalctl-бік розкладів покритий у шпаргалці journalctl.

rsync проти scp: вердикт

	scp	rsync
Йде з OpenSSH	Так	Так (потрібні обидва кінці)
Продовження перерваної передачі	Ні	Так (--partial)
Дельта-передача при повторах	Ні	Так
Зберігає права/симлінки	Частково	Повністю (-a)
Патерни винятків	Ні	--exclude
Dry run	Ні	--dry-run
Дзеркалить видалення	Ні	--delete
Найкраще для	Швидкі разові копії	Бекапи, синхронізації, великі дерева

За замовчуванням беріть rsync для бекапів, великих дерев, усього через лінію, що може обірватися, і всього, що запустите більше разу. Беріться за scp, коли команда коротша за думку. Якщо заберете з цього тексту один прапорець — хай це буде --partial: він перетворює кожен майбутній обрив зв’язку з рестарту на паузу.