rsync для администратора: копирование по SSH, dry run, исключения и безопасное удаление

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

Ниже — практический порядок для Linux и Bash. Примеры используют /srv/project/, отдельный каталог /srv/backup/project/ и backup.example.net. Замените их фактическими путями. Удаление в примерах всегда начинается с dry run; на рабочем сервере сначала требуется независимая копия или snapshot назначения.

1. Что проверить до первой передачи

Проверьте rsync на обеих сторонах, доступный объём, точку монтирования и права оператора:

rsync --version
findmnt -T /srv/backup/project
ls -ld /srv/project /srv/backup/project
df -h /srv/backup/project

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

Следите за обновлениями обеих сторон. На дату сверки 9 октября 2026 года проект рекомендует rsync 3.5.0 для исправления перечисленных уязвимостей; у дистрибутивов возможны backport-исправления с другой версией пакета. Сверяйте бюллетень пакета и официальные security advisories, проверяйте наличие исправлений безопасности в устанавливаемом пакете.

2. Как работает завершающий слеш

Два варианта имеют разное назначение:

rsync -ani /srv/project/ /srv/backup/project/
rsync -ani /srv/project /srv/backup/

Первый переносит содержимое project в назначение. Второй переносит каталог project в уже существующую /srv/backup/. В данном примере итоговые пути совпадут, но при другом назначении легко получить лишний уровень вложенности.

-n означает dry run: rsync показывает предполагаемые действия без переноса. -i выводит изменения по объектам. Всегда проверяйте источник и назначение слева направо, особенно при восстановлении. Синтаксис и слеши — в официальном руководстве rsync.

3. Как выполнить локальное копирование

После проверки dry run выполните тот же сценарий без -n:

rsync -ai --stats /srv/project/ /srv/backup/project/
copy_rc=$?
printf 'rsync exit=%s\n' "$copy_rc"

Без --delete лишние файлы назначения остаются, но совпадающие изменённые файлы могут быть перезаписаны. Это всё равно изменение данных. -a сохраняет стандартный набор атрибутов, но не означает сохранение ACL, extended attributes и hard links: для них рассматривают -A, -X и -H с учётом файловой системы и полномочий.

Обычный пользователь не может произвольно установить владельца. Для копии с восстановлением метаданных нужны согласованные права; перенос числовых UID/GID между серверами требует совпадения модели пользователей. Не добавляйте sudo только ради исчезновения сообщения об ошибке.

4. Как настроить передачу через SSH

Проверьте SSH host key по доверенному каналу и сохраните подтверждённую запись. Не отключайте StrictHostKeyChecking. Создайте отдельный ключ, например Ed25519, либо алгоритм, разрешённый вашей криптографической политикой; устаревший алгоритм DSA не используйте.

Для первого подключения ключ может защищаться парольной фразой и использовать ssh-agent. Публичную часть добавляйте в authorized_keys установленным администратором способом, не заменяя весь файл.

ssh -o StrictHostKeyChecking=yes backup_ops@backup.example.net 'rsync --version'
rsync -ani -e 'ssh -o StrictHostKeyChecking=yes' \
  /srv/project/ backup_ops@backup.example.net:/srv/backup/project/

Пользователь backup_ops должен читать источник или писать назначение в зависимости от направления. Ограничьте его доступ согласованным каталогом и функциями. host: означает remote shell, обычно SSH при данном -e; host::module и rsync:// обращаются к daemon и сами по себе не гарантируют шифрование. Примеры проекта показывают разные сценарии доставки.

5. Как выполнить push и pull

Push — отправка локальных данных на сервер. После dry run:

rsync -ai --stats -e 'ssh -o StrictHostKeyChecking=yes' \
  /srv/project/ backup_ops@backup.example.net:/srv/backup/project/

Pull — получение с сервера в отдельную локальную папку:

rsync -ani -e 'ssh -o StrictHostKeyChecking=yes' \
  backup_ops@backup.example.net:/srv/backup/project/ /srv/restore/project/

Для pull здесь намеренно оставлен -n. Сначала подготовьте /srv/restore/project/ и убедитесь, что это не рабочий каталог. Затем снимите -n для согласованного восстановления. При нестандартном SSH-порте добавляйте -p в команду SSH внутри -e; rsync --port относится к daemon-транспорту.

Сжатие -z оценивайте на реальных данных: уже сжатые архивы и быстрый локальный канал могут не выиграть. Ограничение --bwlimit полезно при совместном использовании канала, но значение выбирается по доступной полосе.

6. Как исключить временные и лишние файлы

Пример исключений относительно корня передачи:

rsync -ani --exclude='/cache/' --exclude='*.tmp' \
  /srv/project/ /srv/backup/project/

/cache/ относится к верхнему каталогу источника, *.tmp — к совпадающим именам в дереве. Сначала проверьте, не содержат ли исключаемые каталоги единственные необходимые данные. Для множества правил создайте документированный exclude-файл и используйте --exclude-from.

Не используйте источник /srv/project/* вместо /srv/project/: wildcard раскрывает shell и может пропустить скрытые объекты. Не добавляйте --delete-excluded к типовой копии: он меняет судьбу исключённых файлов на принимающей стороне. У источника и назначения должны быть одинаковые согласованные правила при повторной сверке.

7. Как применять --delete без потери лишних данных

--delete удаляет объекты назначения, отсутствующие в источнике. Назначение должно быть выделенным зеркалом, без собственных документов и уникальных копий. Пример проверки:

rsync -ani --delete /srv/project/ /srv/mirror/project/

Найдите строки *deleting и проверьте каждую ожидаемую группу удалений. Подтвердите доступность и полноту источника: пустой или ошибочно подключённый источник способен удалить корректное зеркало. Независимая копия назначения должна существовать до исполнения.

Только после согласования той же области снимите -n:

rsync -ai --delete --max-delete=20 /srv/project/ /srv/mirror/project/

20 — демонстрационный ограничитель, не рекомендация для любой сети. --max-delete не является транзакцией: часть изменений может уже произойти до достижения лимита. Повторный dry run нужен, если между просмотром и исполнением изменилось состояние файлов. Не применяйте удаление к /home/, /var/ или корню диска по шаблону статьи.

8. Как проверить результат

Для стабильного источника повторите сравнение:

rsync -ani /srv/project/ /srv/backup/project/
rsync -anic /srv/project/ /srv/backup/project/

Первый вариант использует обычную проверку изменений, второй с -c дополнительно сравнивает содержимое по checksum и читает файлы, создавая нагрузку. Пустой вывод относится только к выбранным правилам и сохраняемым атрибутам. Без --delete сверка не сообщает, что назначения свободны от любых лишних файлов.

Для дампа или архива дополнительно сравните известный хеш и попробуйте восстановление. Откройте контрольные документы с прикладного клиента. Успешный перенос не подтверждает целостность живой базы данных или работающего образа виртуальной машины.

9. Как автоматизировать и понять ошибки

У задания должны быть журнал, защита от пересечения запусков, проверка mount/source и уведомление о результате. Используйте выделенный сервисный контекст; его ключ и права отличаются от интерактивного пользователя. Сначала выполните задание вручную именно в этом контексте.

Зафиксируйте exit code непосредственно после rsync. В разделе EXIT VALUES руководства описаны, в частности, 23 — неполная передача из-за ошибки, 24 — исчезнувшие исходные файлы. Не принимайте любой ненулевой код как успех: выясните объекты и причину.

Permission denied требует проверки конкретной стороны, пути и полномочий. Connection refused — проверки адреса, SSH и фильтрации. Ошибка host key — проверки изменения сервера, а не удаления known_hosts вслепую. Если pipe ведёт в tee, обычный $? может относиться к tee; учитывайте pipefail или PIPESTATUS в Bash.

10. Когда rsync не является резервным копированием

Работающие файлы MySQL, почтовые базы и диски VM нельзя считать согласованной копией только потому, что rsync завершился. Подготовьте прикладной дамп или snapshot с подходящими гарантиями и доставляйте его. Для MySQL — отдельная инструкция по копированию и восстановлению.

Храните историю и независимую копию с отдельными правами, проверяйте восстановление. На Windows выбирайте поддерживаемую среду и проверяйте преобразование путей и метаданных; WSL или Cygwin не обеспечивают автоматически все свойства NTFS-копии. Старый batch с DSA и путями Documents and Settings не переносится на современное развёртывание без пересмотра.

Если нужна схема переноса, синхронизации и проверяемого восстановления АВАНГАРД ИТ поможет определить границы данных и принять результат.