rsync: синхронизация файлов и резервное копирование

Зачем нужен rsync, если есть scp и cp

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

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

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

Практическая репутация rsync в администрировании Linux-серверов

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

Базовый синтаксис и ключевые флаги

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

rsync -avz /var/www/site/ user@backup.example.ru:/backups/site/

Флаг -a (archive) — это составной флаг, включающий сразу несколько важных режимов: рекурсивный обход подкаталогов, сохранение прав доступа, владельца, группы, времени модификации и символических ссылок как есть, без разыменования. На практике -a — это флаг, который стоит использовать почти всегда при полноценном резервном копировании, поскольку без него метаданные файлов (важные, например, для корректной работы веб-сервера с правильным владельцем файлов) не сохраняются.

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

Важная деталь синтаксиса rsync — наличие или отсутствие слэша в конце пути источника меняет поведение: rsync -avz /var/www/site/ (со слэшем) скопирует содержимое каталога site внутрь назначения, тогда как rsync -avz /var/www/site (без слэша) скопирует сам каталог site как подкаталог назначения. Эта деталь — частый источник путаницы при первой настройке резервного копирования, особенно если ожидаемая структура каталогов на приёмнике не совпадает с полученной.

Флаг --delete: полная зеркальная синхронизация

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

rsync -avz --delete /var/www/site/ user@backup.example.ru:/backups/site/

Флаг --delete приводит назначение к точному соответствию источнику, удаляя из него всё, чего больше нет в источнике, — это необходимо для настоящего зеркалирования, но требует особой осторожности: если по ошибке указан пустой или неверный путь источника (например, из-за незамонтированного диска), rsync с --delete честно приведёт назначение к пустому состоянию, безвозвратно удалив все реальные данные резервной копии.

rsync -avzn --delete /var/www/site/ user@backup.example.ru:/backups/site/

Добавление флага -n (или --dry-run) к любой команде с --delete — разумная защитная практика перед первым реальным запуском новой конфигурации синхронизации: rsync выведет полный список файлов, которые были бы удалены или изменены, но не выполнит ни одной реальной операции, что позволяет заметить ошибку в пути или неожиданно большой список удаляемых файлов до того, как они действительно исчезнут.

Исключение файлов и каталогов из синхронизации

Далеко не все файлы проекта нужно включать в резервную копию или синхронизацию — временные файлы, кэш, системные каталоги вроде .git можно и нужно исключать, чтобы не тратить время и место на данные, которые либо легко восстановить из другого источника, либо вообще не нужны в копии.

rsync -avz --exclude='cache/' --exclude='*.tmp' --exclude='.git/' /var/www/site/ user@backup.example.ru:/backups/site/

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

# exclude-list.txt
cache/
*.tmp
*.log
.git/
node_modules/

# использование:
rsync -avz --exclude-from='exclude-list.txt' /var/www/site/ user@backup.example.ru:/backups/site/

Обратная задача — явно включить только определённые файлы или каталоги — решается флагом --include в комбинации с --exclude='*' в конце, при этом порядок правил имеет значение: rsync применяет правила в том порядке, в котором они указаны в команде, и первое подошедшее правило определяет судьбу файла, что важно учитывать при построении более сложных комбинаций include и exclude.

Инкрементальное резервное копирование через --link-dest

Одна из самых практически ценных возможностей rsync для резервного копирования — построение серии инкрементальных снапшотов, каждый из которых выглядит как полная независимая копия данных, но реально занимает на диске место только под файлы, действительно изменившиеся с прошлого снапшота.

rsync -avz --delete --link-dest=/backups/2026-10-24/ /var/www/site/ /backups/2026-10-25/

Флаг --link-dest указывает на каталог предыдущего снапшота — для каждого файла, содержимое которого не изменилось по сравнению с этим каталогом, rsync создаёт в новом снапшоте не копию, а жёсткую ссылку (hard link) на тот же самый файл на диске. С точки зрения файловой системы жёсткая ссылка — это ещё одно имя для тех же самых данных на диске, поэтому такой файл физически не дублируется, хотя в каждом снапшоте он выглядит как полноценный, независимый файл при обычном просмотре каталога.

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

#!/bin/bash
DATE=$(date +%Y-%m-%d)
YESTERDAY=$(date -d yesterday +%Y-%m-%d)
BACKUP_ROOT=/backups

rsync -a --delete \
  --link-dest="$BACKUP_ROOT/$YESTERDAY/" \
  /var/www/site/ \
  "$BACKUP_ROOT/$DATE/"

Важная деталь: важно удалять сам файл, а не изменять его содержимое напрямую внутри старых снапшотов — если случайно отредактировать файл в старом снапшоте, из-за жёсткой ссылки эти изменения затронут и все остальные снапшоты, использующие ту же самую ссылку на данные, что нарушает саму идею неизменности исторических копий.

Ограничение скорости и передача по SSH с нестандартным портом

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

rsync -avz --bwlimit=5000 /var/www/site/ user@backup.example.ru:/backups/site/

Флаг --bwlimit задаёт ограничение скорости передачи в килобайтах в секунду — разумная практика для регулярных фоновых резервных копий, которые не должны конкурировать за пропускную способность канала с обслуживанием реальных посетителей сайта в момент выполнения задачи.

rsync -avz -e 'ssh -p 2222' /var/www/site/ user@backup.example.ru:/backups/site/

Флаг -e позволяет передать произвольные параметры команде ssh, используемой rsync для установления соединения, — это нужно, если сервер назначения слушает SSH на нестандартном порту (частая практика безопасности, разобранная в статье о защите SSH) или если требуется указать конкретный файл приватного ключа, отличный от используемого по умолчанию.

rsync через SSH против rsync daemon

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

Альтернативный способ — запуск rsync в режиме отдельного демона (rsync daemon), слушающего собственный порт 873 без использования SSH вообще. Такой режим заметно быстрее за счёт отсутствия накладных расходов на шифрование и установление SSH-сессии, что заметно на синхронизации очень больших объёмов данных внутри доверенной локальной сети.

# /etc/rsyncd.conf
[backup]
path = /backups/site
read only = yes
uid = nobody
gid = nogroup

Плата за эту скорость — отсутствие шифрования трафика по умолчанию и необходимость отдельной настройки аутентификации внутри самого rsyncd.conf (через secrets file), поскольку демон rsync не использует системных пользователей и SSH-ключи сервера. По этой причине режим демона в первую очередь подходит для передачи данных внутри доверенной приватной сети (например, между серверами одного дата-центра), а не через открытый интернет, где предпочтительна передача через SSH с полным шифрованием канала.

rsync -avz rsync://backup.example.ru/backup/ /local/restore/

Автоматизация резервного копирования через cron

Регулярное резервное копирование через rsync редко имеет смысл запускать вручную — гораздо надёжнее оформить его как задачу по расписанию через cron (или systemd timer, разобранный в отдельной статье), чтобы копии создавались автоматически без участия администратора.

#!/bin/bash
set -e
LOG=/var/log/rsync-backup.log
echo "[$(date)] Начало резервного копирования" >> "$LOG"
rsync -avz --delete \
  --exclude-from=/etc/rsync-exclude.txt \
  --bwlimit=5000 \
  /var/www/site/ user@backup.example.ru:/backups/site/ >> "$LOG" 2>&1
echo "[$(date)] Резервное копирование завершено, код: $?" >> "$LOG"

Директива set -e в начале скрипта прерывает его выполнение при первой же неудачной команде, вместо того чтобы продолжить выполнение остальных строк скрипта после сбоя, что особенно важно, если после rsync в скрипте идут дальнейшие шаги вроде уведомления об успешном завершении или ротации старых снапшотов, — эти шаги не должны выполняться, если сама передача данных провалилась.

0 2 * * * /usr/local/bin/backup-rsync.sh

Отдельного внимания заслуживает логирование результата: без явного перенаправления вывода в файл узнать об ошибке синхронизации (например, недоступности удалённого сервера в конкретную ночь) можно только случайно, значительно позже, обнаружив отсутствие свежих резервных копий. Разбор различий между cron и systemd timer в части логирования и уведомлений о сбоях — в отдельной статье о выборе планировщика задач.

Восстановление данных из резервной копии rsync

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

rsync -avz user@backup.example.ru:/backups/2026-10-25/ /var/www/site-restored/

Это одно из практических преимуществ подхода с --link-dest перед архивными форматами резервного копирования: любой отдельный снапшот можно просмотреть и восстановить независимо от остальных, без необходимости распаковывать полный архив или последовательно применять цепочку инкрементальных изменений поверх базовой полной копии, как это устроено в некоторых других системах резервного копирования.

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

Типичные ошибки при работе с rsync

Пропущенный или лишний слэш в конце пути источника — приводит к синхронизации содержимого каталога вместо самого каталога (или наоборот), что даёт неожиданную структуру файлов на приёмнике и особенно заметно при первом запуске новой конфигурации резервного копирования.

Использование --delete без предварительной проверки через --dry-run на новой или изменённой команде — при ошибке в пути источника это способно безвозвратно удалить существующую резервную копию, а не создать новую поверх старой.

Редактирование файлов напрямую внутри старых снапшотов, созданных через --link-dest, — из-за общих жёстких ссылок такое изменение затрагивает данные сразу во всех снапшотах, использующих ссылку на тот же файл, разрушая историческую точность старых копий.

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

Игнорирование ограничения скорости (--bwlimit) для больших регулярных резервных копий на серверах с ограниченным или разделяемым с реальным трафиком каналом — полноскоростная синхронизация ночью способна временно снизить отзывчивость сайта для посетителей, оказавшихся онлайн именно в это время.

Итог: гибкий инструмент для синхронизации и резервного копирования

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

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

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