rsync в Linux: как копировать файлы без неприятных сюрпризов

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

Безопасность работы с rsync зависит не от количества ключей, а от трёх привычек: явно записывать источник и назначение, сначала запускать команду с --dry-run и не использовать удаление, пока план не прочитан целиком.

Сначала решите, какой результат должен получиться

Допустим, файлы сайта лежат в /srv/site/, а копия должна оказаться в /mnt/backup/site/. После выполнения вы ожидаете увидеть файл /mnt/backup/site/index.html, а не /mnt/backup/site/site/index.html.

Проверьте исходный каталог и создайте назначение заранее:

ls -la /srv/site/
mkdir -p /mnt/backup/site/
ls -ld /mnt/backup/site/

Команды выполняются на компьютере, где доступны оба пути. ls ничего не меняет. mkdir -p создаёт недостающие каталоги, но не очищает существующий. Если для записи нужны права другого пользователя, не переходите сразу к sudo: сначала выясните владельца через ls -ld и выберите назначение, которым управляете.

Проведите пробное локальное копирование

Начните с команды, которая только покажет предполагаемые действия. Запускайте её на компьютере с каталогом /srv/site/; благодаря --dry-run содержимое источника и назначения пока не изменится:

rsync -a --itemize-changes --dry-run /srv/site/ /mnt/backup/site/

Здесь:

• -a включает архивный режим: рекурсивное копирование и сохранение основных атрибутов файлов;
• --itemize-changes добавляет краткое объяснение для каждого изменяемого объекта;
• --dry-run запрещает реальное копирование;
• первый путь — источник, второй — назначение.

Если вывод содержит ожидаемые файлы и правильные пути, повторите команду без --dry-run:

rsync -a --itemize-changes /srv/site/ /mnt/backup/site/

Успешная команда завершается с кодом 0. Сразу после неё запросите код выхода:

echo $?

Ноль означает, что rsync не сообщил об ошибке. Это ещё не подтверждает пригодность копии: откройте несколько файлов или выполните проверку, описанную ниже.

Не перепутайте каталог и его содержимое

Завершающий слеш у источника меняет структуру результата. Следующие строки не предназначены для запуска: это схема двух вариантов и ожидаемых путей назначения:

rsync -a source/ destination/  → destination/file.txt
rsync -a source  destination/  → destination/source/file.txt

Слеш после source/ означает «копировать содержимое». Без слеша каталог source становится отдельным элементом внутри назначения. Оба поведения правильные; ошибка появляется, когда фактическая структура не совпадает с ожидаемой.

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

Передайте каталог на сервер через SSH

Для удалённой передачи rsync обычно запускает SSH. Утилита rsync должна быть установлена и на отправляющей, и на принимающей стороне. Сначала отдельно проверьте вход:

ssh deploy@example.com

Замените пользователя и имя сервера. Убедитесь, что попали на нужную машину, затем завершите сеанс командой exit. Не отключайте проверку ключа сервера: отпечаток защищает от подключения к подменённому узлу.

Теперь с локального компьютера постройте пробный план отправки:

rsync -a --itemize-changes --dry-run \
  /srv/site/ deploy@example.com:/srv/site/

Двоеточие отделяет имя удалённого узла от пути на нём. Без двоеточия выражение станет локальным путём с необычным именем. Если SSH работает на другом порту, передайте его так:

rsync -a --dry-run -e 'ssh -p 2222' \
  /srv/site/ deploy@example.com:/srv/site/

Ключ -e задаёт транспортную команду, а 2222 — пример порта. После проверки уберите только --dry-run. Если удалённая сторона отвечает rsync: command not found, установите rsync штатным пакетным менеджером на сервере или выберите другой способ передачи.

Исключите кеши и локальные секреты

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

.git/
node_modules/
.env
cache/
*.log

Затем добавьте файл исключений к пробному локальному запуску. Команда читает rsync-exclude.txt из текущего каталога и по-прежнему ничего не копирует из-за --dry-run:

rsync -a --itemize-changes --dry-run \
  --exclude-from=rsync-exclude.txt \
  /srv/site/ /mnt/backup/site/

Шаблоны применяются относительно корня передачи. Каталог .git/ и файл .env не попадут в назначение. Проверьте вывод и структуру: слишком широкое правило вроде *.json может исключить нужные данные приложения.

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

Используйте удаление только для точного зеркала

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

До первого удаления сохраните прежнее назначение отдельной версией или снапшотом. Затем запустите только пробный вариант:

rsync -a --delete-delay --itemize-changes --dry-run \
  /srv/site/ /mnt/mirror/site/

--delete-delay откладывает удаления до окончания передачи. В выводе строки с *deleting перечисляют будущие удаления. Если там есть неожиданный путь, не запускайте рабочую команду: проверьте слеш у источника, исключения и назначение.

Ни --delete, ни --delete-delay не создают историю версий. Если файл был испорчен в источнике, зеркало получит испорченную версию. Для настоящей резервной копии нужны несколько точек восстановления и регулярная проба возврата данных.

Проверьте копию после передачи

Повторный обычный запуск без изменений должен вывести пустой список при --itemize-changes:

rsync -a --itemize-changes --dry-run /srv/site/ /mnt/backup/site/

Обычно rsync сравнивает размер и время изменения. Для более строгой разовой проверки можно заставить обе стороны вычислить контрольные суммы:

rsync -a --checksum --itemize-changes --dry-run \
  /srv/site/ /mnt/backup/site/

--checksum читает содержимое всех обычных файлов на обеих сторонах и поэтому заметно нагружает диски и процессор. Используйте его для проверки после важного переноса, а не механически в каждом регулярном запуске.

Архивный режим -a не включает сохранение ACL, расширенных атрибутов и жёстких ссылок. Если приложение зависит от них, изучите ключи -A, -X и -H, проверьте поддержку файловой системой и протестируйте восстановление. Не добавляйте эти параметры вслепую: они могут требовать дополнительных прав и ресурсов.

Разберите частые ошибки

Permission denied означает, что пользователь не может прочитать источник, записать назначение или войти по SSH. Определите конкретный путь из сообщения и исправьте его владельца или модель доступа. Запуск всего процесса от root может скрыть проблему и создать файлы с неудобными владельцами.

No space left on device относится не только к объёму данных, но и к исчерпанию inode — записей файловой системы. Проверьте оба ресурса командами df -h и df -i, освободите место и повторите передачу.

Код выхода 23 или 24 сообщает о частичной передаче: некоторые файлы не скопированы или исчезли во время чтения. Не считайте такую копию готовой. Прочитайте сообщения выше итоговой строки, устраните причину и повторите проверку.

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

Если цель — перенести работающий сайт на другой VPS, одного rsync недостаточно: базу данных нужно копировать согласованно, затем проверить новый сервер до переключения DNS.

Источники

• Официальная справка rsync
• Документация OpenSSH