rsync для деплоев и бэкапов: быстрые ключи, инкрементальность и контроль прав

rsync — инструмент, который одинаково уместен и в «маленьких» задачах (залить пару папок на тест), и в регулярной рутине продакшена: деплой, зеркалирование, инкрементальные бэкапы. Он экономит трафик, сравнивает файлы по размерам/контрольным суммам, передаёт только отличия, умеет сохранять права, владельцев, ACL и xattrs. Ниже — практические пресеты и приёмы для админов, девопсов и вебмастеров: быстрый деплой по SSH, инкрементальные снапшоты через hardlink, и главное — контроль прав, чтобы после копирования ничего не «сломалось».

Ментальная модель rsync: источник, приёмник и «хвостящий слэш»

rsync работает по простой схеме: источник и приёмник могут быть локальными путями, удалёнными путями по SSH, либо смешанными (локально → удалённо или наоборот). Он строит список файлов, определяет изменения и передаёт только различия. Классическая ловушка — хвостящий слэш у исходного пути: он меняет семантику копирования.

Если указываете источник с хвостящим слэшем, копируется содержимое каталога. Без слэша копируется сам каталог как сущность.

При деплое обычно копируем содержимое build-папки в директорию релиза, а при бэкапе — наоборот, сохраняем «каталог как есть» для структурированных слепков.

Быстрый и безопасный пресет для деплоя по SSH

Типовой сценарий: локальная сборка → удалённый сервер (например, VDS; на некоторых проектах годится и виртуальный хостинг с доступом по SSH). Цель — быстро доставить изменённые файлы, удалить устаревшие артефакты, не сломать права и владельцев, получить внятную статистику. Базовый набор ключей:

• -a — архивный режим: рекурсивно, с сохранением прав, времён, симлинков, устройств и т. п.
• -H, -A, -X — дополнительно сохраняем hardlinks, ACL, расширенные атрибуты (xattrs), когда это важно.
• --delete-delay — удаляем лишние файлы на приёмнике после передачи, но с задержкой для безопасности процесса.
• --info=stats2,progress2 и --stats — полезная статистика и прогресс.
• -z или явный --compress — сжатие по сети (для медленного канала; в LAN не всегда нужно).
• -e ssh — передача по SSH (с нужными опциями для производительности и безопасности).
• --mkpath — создать путь назначения, если его ещё нет (удобно для CI/CD).

Практические улучшения: используйте --skip-compress (или в новых версиях --compress-choice) для форматов, которые не стоит пережимать (jpg, png, mp4, gz, br, zip), и включайте SSH-мультиплексирование, чтобы последующие запуски rsync не тратили время на установку канала.

В продакшене начинайте с «сухого прогона». Ключ -n (--dry-run) покажет план действий и спасёт от неприятных сюрпризов при первом запуске рецепта.

SSH-опции, ускоряющие деплой

Чтобы не упираться в накладные расходы на установку соединения и шифрование, добавьте к -e ssh параметры: ControlMaster/ControlPersist для мультиплексирования, подходящий шифр и отключение сжатия на стороне SSH (если rsync уже сжимает данные). Не забудьте про порт и ключи.

rsync -aHAX --delete-delay --info=stats2,progress2 --mkpath -z -e "ssh -p 22 -i /home/user/.ssh/deploy_ed25519 -o ControlMaster=auto -o ControlPersist=60s -o Compression=no" ./build/ user@example:/var/www/app/releases/2025-10-21/

На быстрых каналах (LAN, внутри датацентра) иногда быстрее --whole-file (-W), который отключает дельта-алгоритм и копирует файлы целиком. Помните: -z может замедлить процесс при упоре в CPU.

Надёжное удаление и защита от «самострела»

Удаление на приёмнике — частая причина инцидентов. Уточняйте семантику:

• --delete-delay — удаление после передачи (безопаснее для деплоя).
• --delete-after — схожая идея, но с меньшими оптимизациями.
• --delete-excluded — удалять на приёмнике то, что попало под --exclude. Опасно — включайте только при чётком понимании.

Для критичных файлов используйте защитные фильтры: --filter 'P .env' или маски исключений. Это особенно важно, когда на сервере появляются файлы, которых нет в репозитории (локальные конфиги, пользовательские загрузки).

Контроль прав, владельцев, ACL и xattrs

«Права» — главный источник проблем при деплое и бэкапе. Архивный режим (-a) пытается сохранить метаданные, но итог зависит от пользователя, от которого запущен rsync, и особенностей ФС.

• --perms (-p) — сохранить режимы доступа.
• --owner (-o), --group (-g) — сохранить владельца и группу (нужен root на приёмнике, либо --fake-super).
• --acls (-A) и --xattrs (-X) — для ACL и расширенных атрибутов.
• --numeric-ids — использовать числовые UID/GID без сопоставления имён (актуально при разных именах пользователей).
• --chown=<user>:<group> — назначить владельца на приёмнике, даже если копируете как не-root (обрабатывается на приёмнике).
• --chmod=... — изменить режимы, например --chmod=Du=rwx,Dg=rx,Fu=rw,Fg=r.

Нет root-доступа? Используйте --fake-super: владельцы/ACL/xattrs будут сохранены «виртуально» в xattrs. Требуется поддержка xattrs на ФС по обе стороны.

На серверах с несколькими проектами полезно фиксировать режимы каталогов через setgid у групповых директорий и согласованный umask. rsync может принудительно привести права к ожидаемым с помощью --chmod, чтобы избежать «плавающих» прав, если деплой делает другой пользователь CI.

Инкрементальные бэкапы: быстро и экономно

Сильная сторона rsync в резервном копировании — инкрементальность. Часто достаточно зеркала и ежедневных «снимков», реализованных через hardlink-и. Получаем полноценно выглядящие каталоги по датам, а место экономится радикально: неизменённые файлы занимают ровно один набор блоков на диске.

Ключи: --link-dest (ссылка на предыдущий снимок), --delete/--delete-delay для синхронизации удаления, плюс аккуратная ротация (скрипт, systemd-timer).

# Базовое зеркало (первый прогон):
rsync -aHAX --delete --mkpath -e "ssh -i /home/user/.ssh/backup_ed25519" user@example:/var/www/app/ /backups/app/mirror/

# Ежедневный снапшот с hardlink-и к зеркалу:
SNAP=/backups/app/snapshots/$(date +%F)
rsync -aHAX --delete --link-dest=/backups/app/mirror/ /backups/app/mirror/ "$SNAP"

# После снапшота обновляем зеркало, чтобы на следующий день link-dest был актуален:
rsync -aHAX --delete -e "ssh -i /home/user/.ssh/backup_ed25519" user@example:/var/www/app/ /backups/app/mirror/

Для больших деревьев включайте --delete-delay, чтобы удаление не мешало передаче. На XFS и ext4 hardlink-снимки работают предсказуемо.

Производительность: когда и что ускоряет

Оптимальные опции зависят от канала, CPU и профиля данных. Практические правила:

• Медленный канал, мощный CPU: включайте -z, выставляйте --compress-level=6, используйте --skip-compress для уже сжатых форматов.
• Быстрый канал (LAN, внутри DC): --whole-file (-W) часто быстрее дельта-алгоритма.
• Большие разрежённые файлы: --sparse (-S) сохранит разрежённость.
• Ограничение канала: --bwlimit=10m стабилизирует нагрузку.
• Много мелких файлов: следите за метаданными на приёмнике (inode, журналирование). Иногда выгоднее упаковать tar и передать один файл, если обновлений мало.
• CPU на пределе: отключите SSH- и rsync-сжатие, используйте быстрый шифр и мультиплексирование SSH.

Профилируйте: сравните прогон с -W и без, замерьте с/без -z, смотрите --stats — «Literal data» и «Matched data» хорошо подсвечивают узкие места.

Паттерн деплоя без простоя

Для статического контента и PHP-приложений без долгоживущих воркеров подходит паттерн: синхронизируем в новый каталог релиза, затем атомарно переключаем симлинк current. Текущий релиз остаётся нетронутым, новый готовится параллельно.

# Синхронизируем сборку в новый релиз
RELEASE=2025-10-21_1200
rsync -aHAX --delete-delay --mkpath -e "ssh -i /home/user/.ssh/deploy_ed25519" ./build/ user@example:/var/www/app/releases/${RELEASE}/

# После успешной передачи меняем ссылку current на новый релиз
ssh -i /home/user/.ssh/deploy_ed25519 user@example "ln -sfn /var/www/app/releases/${RELEASE} /var/www/app/current"

Откат — мгновенным переключением симлинка на предыдущий релиз. Не затирайте каталоги с пользовательскими загрузками, кешами, сокетами — корректно опишите исключения --exclude/--filter. Если планируете перенос окружения с сохранением аптайма, пригодится наш материал про пошаговый переезд сайта без простоя.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Фильтры, исключения и файловые списки

Грамотные исключения ускоряют деплой и бэкап и снижают риски. --exclude удобен для коротких масок, а --filter — для сложных правил, включая «защиту» путей (P):

rsync -a --delete-delay --exclude ".git" --exclude ".DS_Store" --exclude "node_modules" --filter "P .env" --filter "P storage/uploads" ./ user@example:/var/www/app/current/

Для больших проектов эффективны --files-from (список переносимых путей) и --exclude-from (маски исключений из файла). Это повышает воспроизводимость и делает рецепты самодокументируемыми. Если проект перерос общий хостинг и вы планируете переезд, посмотрите обзор шагов в материале миграция с шаред-хостинга на VDS.

Диагностика и безопасность

Полезные опции для отладки: -n (--dry-run), -i (--itemize-changes) — детализирует, что меняется; -v/-vv повышают многословность. Сообщение «file has vanished» обычно безвредно при параллельных изменениях источника, но в продакшене это повод стабилизировать входные данные (freeze).

Частые ошибки и решения:

• Permission denied: проверьте владельца каталога назначения, SELinux/AppArmor и соответствие опций --owner/--group.
• Operation not permitted при -A/-X: нет поддержки ACL/xattrs на ФС. Отключите опции или настройте ФС.
• Несовпадение пользователей: используйте --numeric-ids или --usermap/--groupmap для явного сопоставления.

Безопасность: для деплоя/бэкапа используйте отдельную пару SSH-ключей, при необходимости ограничьте командой в authorized_keys и/или IP. На CI выделяйте «deploy-only» юзера на приёмнике, чтобы минимизировать последствия ошибки.

Тонкости хранения метаданных

Если важно сохранить «всё как есть» (временные метки, владельцев, ACL/xattrs), запускайте rsync от аккаунта с нужными правами на приёмнике. При отсутствии root помогает --fake-super. Не забывайте про монтирование ФС с поддержкой xattrs/acl и про перенос атрибутов при миграции на другой сервер.

На NFS и других сетевых ФС часть метаданных может теряться или преобразовываться. Тестируйте полный цикл восстановления: разверните один из снапшотов, проверьте права, запустите приложение. Бэкап — это не только «куда-то сложили», но и «корректно восстановили».

Автоматизация: cron и systemd timers

Для ежедневных инкрементальных бэкапов используйте systemd timers или cron. Логируйте --stats, храните логи отдельно от бэкапов, контролируйте коды выхода. В CI/CD фиксируйте версии rsync и SSH-опции, чтобы воспроизводимость не зависела от окружений runner-ов.

Чеклист для продакшен-профиля rsync

• Начинайте с --dry-run и --itemize-changes.
• Явно описывайте исключения и «защищённые» пути (--filter 'P ...').
• Решите вопрос с правами: --chown, --chmod, --numeric-ids, -A, -X, либо --fake-super.
• Для деплоя — релизные каталоги и атомарное переключение симлинка.
• Для бэкапов — зеркало плюс ежедневные hardlink-снапшоты через --link-dest.
• Оптимизируйте под канал: -z или -W, SSH-мультиплексирование, --bwlimit.
• Логи, метрики, коды возврата — в отдельный мониторинг.

Итоги

rsync остаётся актуальным для деплоев и бэкапов: экономит трафик и время, корректно сохраняет права и владельцев, легко автоматизируется. С правильными ключами вы получите и производительность, и безопасность: инкрементальные снимки через hardlink, бездоу́нтайм-переключение релизов, чёткие правила исключений. А самое ценное — прозрачность: --itemize-changes и --stats дают полную картину изменений для аудита и быстрого разбора инцидентов.