rsync копирует не файлы целиком, а дельты — при повторном запуске на тот же адресат передаёт по сети только изменившиеся блоки. Это база большинства скриптовых бэкапов, где pg_probackup/pgBackRest — оверкилл, а tar каждый день целиком — слишком дорого по месту и трафику.
База — флаг -a (archive), который на самом деле сокращение сразу нескольких:
rsync -avz --delete -e ssh /srv/data/ user@backup-host:/srv/data/
-a— рекурсивно, с сохранением прав, времени модификации, симлинков, владельца/группы-v— подробный вывод, что скопировано-z— сжатие на лету (полезно на медленном канале, бессмысленно на гигабитной локалке между двумя дисками)--delete— удалить на приёмнике файлы, которых больше нет в источнике (без этого флага бэкап только растёт, никогда не синхронизируется в обе стороны по составу)-e ssh— транспорт, можно указать порт/ключ:-e "ssh -p 2222 -i /path/key"
Инкрементальные снапшоты без дифф-бэкапа — трюк с --link-dest:
rsync -a --link-dest=/backup/2026-09-30 /srv/data/ /backup/2026-10-01/
Файлы, которые не изменились с прошлого снапшота, не копируются заново — вместо этого в новой директории создаётся хардлинк на файл из --link-dest. Итог: /backup/2026-10-01/ выглядит как полная независимая копия (можно смонтировать, скопировать, удалить старые снапшоты не трогая новые), а место на диске расходуется только на реально изменившиеся файлы. Это тот же принцип, на котором строится rsnapshot, только без обёртки.
Частая ошибка — путь с завершающим слэшем и без:
rsync -a /srv/data /backup/ # скопирует папку data/ ВНУТРЬ /backup/
rsync -a /srv/data/ /backup/ # скопирует СОДЕРЖИМОЕ data/ прямо в /backup/
Слэш после источника — “содержимое директории”, без слэша — “саму директорию как есть”. На бэкап-скрипте это разница между рабочей структурой каталогов и случайно продублированным уровнем вложенности.
#linux #backup #rsync