scp и rsync

scp копирует файлы через SSH, используя ту же аутентификацию, что и ssh. Синтаксис повторяет cp, но допускает удалённые пути в форме user@host:path:

# локально → удалённо
scp build/app.tar.gz deploy@server.example:/var/deploys/

# удалённо → локально
scp deploy@server.example:/var/log/app.log ./app.log

# удалённо → удалённо (через твою локальную машину как ретранслятор)
scp deploy@203.0.113.10:/tmp/data.csv deploy@198.51.100.20:/tmp/data.csv

scp достаточен для одноразового копирования файлов. Инкрементальной передачи у него нет — он всегда копирует файл целиком. Для больших или часто обновляемых файлов rsync эффективнее.

rsync -avz — основной инструмент для эффективных передач. Флаги:

• -a (archive): сохраняет права, временные метки, симлинки, владельца, группу. Рекурсия включена.
• -v (verbose): печатает каждый передаваемый файл.
• -z (compress): сжимает данные при передаче — полезно на медленных каналах, избыточно в локальных сетях или для уже сжатых файлов.

rsync -avz ./dist/ deploy@server.example:/var/www/html/

rsync вычисляет контрольную сумму каждого файла и передаёт только изменившиеся. При повторном запуске без изменений завершается почти мгновенно. Это ключевое отличие от scp.

Вывод показывает, что было передано:

sending incremental file list
index.html
assets/app.42a1b.js
sent 48,231 bytes  received 542 bytes  9,754.60 bytes/sec

Завершающий слеш в источнике меняет то, что копирует rsync — это самая распространённая ошибка. Семантика завершающего слеша rsync:

# СО завершающим слешем — копировать СОДЕРЖИМОЕ dist/ в html/
rsync -avz ./dist/ deploy@server.example:/var/www/html/
# Результат: html/index.html, html/assets/app.js ...

# БЕЗ завершающего слеша — копировать САМ каталог dist/ в html/
rsync -avz ./dist deploy@server.example:/var/www/html/
# Результат: html/dist/index.html, html/dist/assets/app.js ...

У пути назначения нет такой неоднозначности — он всегда контейнер. Правило: если хочешь, чтобы содержимое src/ попало прямо в dst/, ставь завершающий слеш на источнике. Если хочешь создать dst/src/ с файлами — не ставь. Проверяй своё намерение перед каждым вызовом rsync.

rsync -a --delete зеркалирует каталог — и удаляет на удалённой стороне файлы, отсутствующие в источнике. Это самая мощная и самая опасная комбинация флагов rsync:

rsync -avz --delete ./dist/ deploy@server.example:/var/www/html/

--delete удаляет из удалённого /var/www/html/ все файлы, которых нет в локальном ./dist/. Это именно то, что нужно для зеркала деплоя: удалённая сторона точно отражает источник, без накопления устаревших файлов. И это именно то, как удаляются важные файлы, если перепутать источник или назначение.

Распространённые ошибки:

• Неправильный каталог источника (на уровень выше): rsync -a --delete ./ deploy@server.example:/var/www/html/ — удалит в html/ всё, чего нет в текущем каталоге.
• Переставленные источник и назначение: удалённая сторона становится источником, локальная — назначением; файлы удаляются локально.
• Пропущенный завершающий слеш при необходимости: копирование на неправильный уровень вложенности.

Всегда используй --dry-run перед любой деструктивной синхронизацией. --dry-run (или -n) печатает точно, что сделает rsync, без передачи или удаления чего-либо:

rsync -avz --delete --dry-run ./dist/ deploy@server.example:/var/www/html/

Вывод включает:

deleting old-feature/
deleting old-feature/index.html
index.html
assets/app.42a1b.js

Читай этот вывод внимательно. Если видишь строки deleting, которых не ожидал — останавливайся. Привычка: каждый раз при добавлении --delete сначала запускай с --dry-run, проверяй список удалений, затем запускай без него. Эта одна дисциплина предотвращает целую категорию инцидентов с потерей данных.