rsync: примеры синхронизации файлов и бэкапов в Linux

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

Синтаксис и самые нужные флаги

Общий вид команды:

rsync [опции] ИСТОЧНИК... ПРИЁМНИК

Источник и приёмник могут быть локальными путями или удалёнными в форме user@host:/путь. Одна из сторон обязательно локальная: rsync не копирует напрямую между двумя удалёнными машинами.

На практике в девяти случаях из десяти хватает rsync -avh локально и rsync -avzh по сети.

Слеш в конце пути: главная ловушка

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

# Скопировать КАТАЛОГ project внутрь /backup → получится /backup/project/...
rsync -av project /backup/

# Скопировать СОДЕРЖИМОЕ project в /backup → файлы окажутся прямо в /backup/
rsync -av project/ /backup/

Запомнить просто: слеш в конце источника означает «содержимое этого каталога». У приёмника слеш роли не играет. Если сомневаетесь, добавьте -n и посмотрите, какие пути rsync собирается создать.

Локальное копирование

Скопировать каталог на внешний диск с прогрессом:

rsync -avhP ~/photos/ /mnt/usb/photos/

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

sending incremental file list
2026/10/IMG_2041.jpg
          4.12M 100%   38.40MB/s    0:00:00 (xfr#1, to-chk=0/1534)

sent 4.13M bytes  received 9.25K bytes  2.76M bytes/sec
total size is 6.82G  speedup is 1,648.21

Значение speedup показывает, во сколько раз меньше данных передано по сравнению с полным копированием.

rsync по SSH: копирование на сервер и обратно

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

# Выгрузить сайт на сервер
rsync -avz ./site/ deploy@203.0.113.10:/var/www/site/

# Скачать логи с сервера к себе
rsync -avz deploy@203.0.113.10:/var/log/nginx/ ./nginx-logs/

# SSH на нестандартном порту и с конкретным ключом
rsync -avz -e "ssh -p 2222 -i ~/.ssh/deploy_key" ./site/ deploy@203.0.113.10:/var/www/site/

rsync должен быть установлен на обеих машинах: на удалённой стороне он запускается через SSH. Если его там нет, вы увидите rsync: command not found — поставьте пакет (sudo apt install rsync или sudo dnf install rsync).

Если хост указан в ~/.ssh/config под псевдонимом, rsync его понимает: rsync -avz ./site/ prod:/var/www/site/.

Нужны права root на сервере

Когда файлы в приёмнике принадлежат root, а входите вы обычным пользователем, можно запустить удалённый rsync через sudo:

rsync -avz --rsync-path="sudo rsync" ./conf/ admin@server:/etc/myapp/

Для этого на сервере sudo для rsync должен работать без пароля (правило в sudoers), иначе команда зависнет в ожидании ввода.

rsync-демон вместо SSH

Во внутренней доверенной сети можно обойтись без SSH: на приёмнике запускают rsync-демон, а в /etc/rsyncd.conf описывают именованные шары. Клиент обращается по адресу rsync:// и не нуждается в системной учётной записи; передача быстрее, но данные не шифруются, поэтому в интернет такой порт (873) не выставляют.

# /etc/rsyncd.conf на сервере
[share]
path = /backup/
hosts allow = 192.168.3.0/24
read only = false

# Клиент
rsync -avzh /tmp/backup/ rsync://192.168.3.105/share

Зеркало каталога: --delete

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

rsync -avh --delete ~/projects/ /mnt/backup/projects/

Это мощный и опасный флаг. Ошибка в пути (например, пустой источник или забытый слеш) удалит данные в приёмнике. Поэтому правило одно: любую команду с --delete сначала запускайте с -n.

$ rsync -avhn --delete ~/projects/ /mnt/backup/projects/
sending incremental file list
deleting old-app/README.md
deleting old-app/
app/main.py

sent 1.20K bytes  received 64 bytes  2.53K bytes/sec
total size is 18.4M  speedup is 14,554.39 (DRY RUN)

Строки deleting показывают, что будет удалено. Убедились, что всё верно, — запускайте без -n.

Полезные вариации: --delete-after удаляет файлы после передачи (приёмник дольше остаётся полным), --backup --backup-dir=/mnt/backup/deleted-$(date +%F) не удаляет, а перемещает удаляемые и заменяемые файлы в отдельный каталог.

Исключения: --exclude и --include

Исключать временные файлы, зависимости и секреты — обычная практика при деплое и бэкапах.

# Несколько шаблонов
rsync -avz --exclude='.git/' --exclude='node_modules/' --exclude='*.log' ./app/ server:/srv/app/

# Шаблоны из файла
rsync -avz --exclude-from='.rsyncignore' ./app/ server:/srv/app/

Файл .rsyncignore — простой список шаблонов, по одному на строку:

.git/
node_modules/
*.log
.env
tmp/

Как работают шаблоны:

• Шаблон без слеша в начале (*.log) совпадает на любой глубине.
• Шаблон со слешем в начале (/tmp/) привязан к корню передачи — исключит только верхний tmp.
• Слеш в конце (cache/) означает «только каталог».
• Правила проверяются по порядку, срабатывает первое подходящее.

Из последнего пункта следует приём «скопировать только нужное»: сначала разрешить, потом запретить остальное.

# Скопировать только файлы .conf, сохранив структуру каталогов
rsync -av --include='*/' --include='*.conf' --exclude='*' /etc/ ./etc-confs/

Здесь --include='*/' нужен, чтобы rsync заходил во все подкаталоги. Добавьте --prune-empty-dirs (-m), чтобы не создавать пустые папки.

Бэкапы на rsync

Простая ежедневная копия

Минимальный бэкап домашнего каталога на второй диск:

rsync -aH --delete --exclude='.cache/' /home/alice/ /mnt/backup/alice/

Минус такого подхода — хранится только одна версия. Если файл испортили, а бэкап успел синхронизироваться, старая версия потеряна.

Инкрементные снимки через --link-dest

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

#!/bin/bash
set -euo pipefail

SRC="/home/alice/"
DEST="/mnt/backup/snapshots"
TODAY="$(date +%F)"

mkdir -p "$DEST"
rsync -aH --delete \
  --exclude='.cache/' \
  --link-dest="$DEST/latest" \
  "$SRC" "$DEST/$TODAY"

ln -sfn "$DEST/$TODAY" "$DEST/latest"

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

Удалять снимки старше 30 дней можно так:

find /mnt/backup/snapshots -maxdepth 1 -type d -name '20*' -mtime +30 -exec rm -rf {} +

Бэкап сервера на другую машину

Направление удобно выбирать «с бэкап-сервера на рабочий»: бэкап-машина сама забирает данные, а у рабочего сервера нет доступа к копиям. Если его взломают, бэкапы останутся целы.

rsync -azH --delete -e "ssh -i /root/.ssh/backup_key" \
  backup@web01:/var/www/ /srv/backups/web01/www/

Учтите, что базы данных так копировать нельзя: файлы работающей СУБД в момент копирования несогласованы. Сначала сделайте дамп (mysqldump, pg_dump), а rsync пусть переносит готовый файл дампа.

Запуск по расписанию через cron

Скрипт бэкапа ставится в cron командой crontab -e:

# Каждый день в 03:15, вывод — в лог
15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Что проверить, чтобы бэкап из cron действительно работал:

• В скрипте используются абсолютные пути: у cron минимальный PATH и другой текущий каталог.
• SSH-ключ без пароля, и хост уже есть в known_hosts — иначе rsync зависнет на вопросе о подлинности ключа.
• Скрипт проверяет код возврата: rsync возвращает 0 при успехе, 23 — если часть файлов не передана, 24 — если файлы исчезли во время копирования.
• От одновременного запуска двух копий защищает flock: flock -n /tmp/backup.lock /usr/local/bin/backup.sh.

Вместо cron можно использовать systemd-таймер — он пишет вывод в журнал, и смотреть результаты удобно через journalctl.

Полезные опции для больших передач

Типичные ошибки и как их исправить

• Permission denied при записи — у пользователя нет прав на каталог приёмника. Проверьте владельца каталога или используйте --rsync-path="sudo rsync".
• Файлы копируются каждый раз заново — не сохраняется время изменения. Убедитесь, что есть -a или -t; на FAT/exFAT добавьте --modify-window=2, потому что эти системы хранят время с точностью до двух секунд.
• Ошибки chown или chgrp при копировании на флешку или сетевую папку — файловая система не поддерживает владельцев. Замените -a на -rlt.
• Появилась лишняя вложенность /backup/project/project — перепутан слеш в конце источника.
• connection unexpectedly closed — проблема SSH или rsync не установлен на удалённой стороне. Проверьте вход обычным ssh и наличие rsync на сервере.

Итог

Для повседневной работы достаточно запомнить несколько команд: rsync -avz src/ host:/dst/ для копирования по SSH, --delete вместе с пробным -n для зеркала, --exclude для лишнего и --link-dest для бэкапов со снимками. Следите за слешем в конце источника — и rsync станет самым надёжным способом переносить файлы между машинами. Синхронизация и резервное копирование разобраны на практике в курсе по Linux.