TGViewer
DevOps Ready | IT DevOps Ready | IT @devops_ready · 7.62K subscribers
Post #1250 1.25K
Знали, зачем перед rsync --delete почти всегда делать dry-run?

rsync часто используют для деплоя, бэкапов и синхронизации директорий. Команда быстрая, удобная и хорошо переносит только изменившиеся файлы.

Ключ --delete полезен, когда целевая папка должна точно совпадать с источником. Например, в dist удалили старый JS-файл, значит на сервере он тоже должен исчезнуть.

Обычный деплой может выглядеть так.
rsync -av --delete ./dist/ server:/var/www/app/


Но именно --delete делает команду опасной. Если перепутать путь, слеш или переменную окружения, можно удалить не те файлы на удалённой стороне.

Особенно часто ошибаются с завершающим слешем. Эти две команды выглядят почти одинаково, но смысл у них разный.
rsync -av ./dist/ server:/var/www/app/
rsync -av ./dist server:/var/www/app/


В первом случае копируется содержимое папки dist. Во втором случае внутрь назначения может попасть сама папка dist.

Перед реальным запуском лучше посмотреть план изменений.
rsync -av --delete --dry-run ./dist/ server:/var/www/app/


--dry-run показывает, что команда собирается скопировать и удалить, но ничего не меняет. Это хороший предохранитель перед первым запуском или изменением пути.

Для более читаемого вывода можно добавить --itemize-changes.
rsync -av --delete --dry-run --itemize-changes ./dist/ server:/var/www/app/


Так проще увидеть, какие файлы будут добавлены, изменены или удалены. Особенно полезно смотреть строки удаления перед запуском без --dry-run.

Если команда собирается из переменных, dry-run становится ещё важнее.
SRC="./dist/"
DST="server:/var/www/app/"
rsync -av --delete --dry-run "$SRC" "$DST"


Так можно быстро заметить пустую переменную, неправильный путь или неожиданный каталог назначения.

Когда вывод выглядит нормально, можно запустить ту же команду без --dry-run.
rsync -av --delete ./dist/ server:/var/www/app/


В CI/CD удобно делать dry-run отдельным ручным шагом для новых deploy-команд. А для регулярных задач стоит хотя бы использовать его при первом запуске после изменения путей.

Перед опасной синхронизацией можно отдельно проверить, сколько удалений планируется.
rsync -av --delete --dry-run --itemize-changes "$SRC" "$DST" | grep "^\*deleting"


Если удалений внезапно слишком много, запуск лучше остановить и перепроверить переменные.

Ещё полезно держать источник и назначение в логах.
echo "SRC=$SRC"
echo "DST=$DST"


Это звучит просто, но в реальном deploy-скрипте такая печать часто экономит много времени при разборе инцидента.

➡️ DevOps Ready | #совет
  • ❤ 8
  • 👍 5
  • 🔥 4
More from @devops_ready
  1. Oct 2, 2026Знали, почему настройки systemd-сервиса лучше менять через systemctl edit? Допустим, прило…
  2. Oct 2, 2026⚡️5 фундаментальных курсов по ИБ по цене одного Это предложение для тех, кто готов войти в…
  3. Oct 2, 2026Этот инструмент поможет поять из чего на самом деле состоит Docker-образ! Он содержит терм…
  4. Oct 1, 2026Проверяем итоговую конфигурацию Docker Compose перед запуском! Когда проект использует баз…
  5. Oct 1, 2026🔄 Безопасный арсенал практических инструкций, курсов и инструментов 👩‍💻 Linux & Bash 🤔…
  6. Oct 1, 2026Шпаргалка по жизненному циклу Pod в Kubernetes! На картинке показано, как запрос проходит…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →