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

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

🔴 --backup и --backup-dir

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

# /usr/bin/rsync -av --progress --delete back_user@10.20.5.22:/var/lib/pgpro/backup/ /mnt/data/backup/bases --backup --backup-dir=/mnt/data/backup/bases_increment/`date +%Y-%m-%d`/ >> /var/log/rsync/1Csrv-`date +%Y-%m-%d`.log

Все свежие дампы базы из папки /var/lib/pgpro/backup/ сервера 10.20.5.22 будут скопированы в папку с бэкапами /mnt/data/backup/bases, при этом старые дампы, которые были скопированы вчера, переместятся в папку /mnt/data/backup/bases_increment/2025-02-13/ и будут там лежать, пока мы их не удалим, к примеру, через find. Глубину хранения сами выбираете, когда настраиваете очистку.

Я добавил ключ --progress, чтобы вывод, сохранённый в файл, содержал в том числе информацию о средней скорости и времени копирования каждого файла. Если у вас много мелких файлов, лучше этот ключ убрать. В логе /var/log/rsync/1Csrv-2025-02-13.log я увижу следующее:

2025-02-13_05-29 Start backup 1Csrv
receiving incremental file list
deleting 2025-02-10_05-01-zup.sql.gz
deleting 2025-02-10_05-01-buh.sql.gz
2025-02-13_05-01-buh.sql.gz
  1,380,560,010 100%    1.03MB/s    0:21:22 (xfr#1, to-chk=20/62)
2025-02-13_05-01-zup.sql.gz
    444,272,983 100%    1.63MB/s    0:04:19 (xfr#2, to-chk=19/62)

Будут перечислены все скопированные и удалённые (т.е. перемещённые в backup-dir папку) дампы.

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

🟡 --ignore-existing

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

# /usr/bin/rsync -av --ignore-existing back_user@10.30.7.5:/mnt/backup/www/ /var/www/

🟢 --update

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

# /usr/bin/rsync -av --update back_user@10.30.7.5:/mnt/backup/www/ /var/www/

Если в целевой папке файлов из источника вообще нет, то они тоже будут скопированы, как и с ключом --ignore-existing. Ключ удобен, когда ты из разных источников склеиваешь данные и хочешь получить в итоге самые свежие версии одних и тех же файлов.

⚫️ --dry-run

Привычное название ключа, который позволяет выполнить команду и посмотреть результат без реального выполнения. То есть выполняется тестовый прогон. Рекомендую использовать, когда отлаживаете команду. Спасёт, если с ключом --delete перепутаете источник и приёмник. Мигом удалите все файлы в источнике, если приёмник пустой.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#rsync

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

Я очень часто использую rsync для бэкапа. В том числе с ключами  --backup и --backup-dir, о которых отдельно рассказывал не так давно в заметке. Эти ключи позволяют хранить изменения за день, если бэкап выполняется раз в сутки. У меня они лежат в таких директориях:

/mnt/backup/increment/2025-03-15
/mnt/backup/increment/2025-03-16
/mnt/backup/increment/2025-03-17

Сам бэкап делаю так:

# /usr/bin/rsync -av --delete back_user@10.20.5.5:/data/mail/virtual/ /mnt/backup/mailsrv --backup --backup-dir=/mnt/backup/increment/`date +%Y-%m-%d`/ >> /var/log/rsync/mailsrv-`date +%Y-%m-%d`.log

Иногда я эти директории автоматически сжимаю для экономии места. И тогда они превращаются в файлы. Файлы удобно чистить примерно так:

# /usr/bin/find /mnt/backup/increment/ -type f -mtime +100 -exec rm -rf {} \;

Просто удаляем всё, что старше 100 дней. Я клонировал один проект и настраивал там бэкапы. Изменения сжимать не стал, оставил их в виде директорий. А команду на очистку оставил такой же, с -type f.

На днях на источнике проводил чистку, какие-то некритичные данные удалял, какие-то сжимал, переносил. Держал в голове, что все изменения за день приедут в отдельную папку и я их сохраню на всякий случай. На источнике не стал окончательно удалять, а только переместил в другое место. Это в итоге спасло данные.

На следующий день захожу на сервер с бэкапами и понимаю, что файлов нет. Чистил старые файлы, они все были старше 100 дней. Судя по всему сначала они были сложены все в одну директорию в соответствии с ключами --backup и --backup-dir, а потом команда find их все удалила. При этом сами директории, в том числе вложенные, но уже без файлов остались.

Я сначала не мог понять, в чём тут дело. Вся иерархия папок сохранилась, но файлов нет. Точнее некоторые файлы были, как я уже потом понял, которые моложе 100 дней, но большей части нет. Не мог долго понять, почему так получилось. Начал грешить на сам rsync и подумывал заменять его на restic или borg. Но смысл в том, что rsync в данном случае мне удобнее и привычнее.

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

# /usr/bin/find /mnt/backup/increment/ -maxdepth 1 -type d -mtime +100 -exec rm -rf {} \;

❗️На самом деле уже не первый раз натыкаюсь на то, что ошибка с find приводит к неожиданным проблемам. С ним, да и любым подобным софтом для очистки данных, нужно очень аккуратно обращаться, всё проверяя по 10 раз. Одна ошибка и данные можно безвозвратно потерять.

#rsync

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

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

# rsync -av --delete /mnt/backup/data/ root@10.20.1.5:/data/

Одной командой с rsync вы обнулите источник на 10.20.1.5, если директория /mnt/backup/data/ пустая. Причём удаляет rsync очень быстро. Я как-то проводил тестирование и делал заметку по этому поводу. Rsync с пустым приёмником чуть ли не быстрее всех удаляет большое файловое хранилище. Времени опомниться и остановить процедуру у вас практически не будет, особенно если это будет выполняться локально. По SSH ещё есть шансы, если сразу остановите.

Я в голове всегда произношу мантры, когда настраиваю rsync: "Откуда копирую и куда". У него сначала идёт источник, а потом приёмник. Казалось бы, это очевидное поведение, но на самом нет. Сбивает с толку другой софт. Например, в tar сначала указываешь куда сжимать, а потом уже что сжимать:

# tar -czvf files.tar.gz /data/files

Есть и другие примеры, но сейчас сходу не вспомню. Припоминаю, что при копировании разметки с дисков в какой-то программе тоже было неочевидное поведение, когда приёмник был первый, а источник вторым. Я всегда боялся затереть разметку с рабочего диска при копировании на новый. Перепроверял по 10 раз.

Если кто-то сталкивался с подобными засадами из-за невнимательности, то поделитесь историями. Будет интересно и полезно. Лидером тут наверное будет rm, когда перепутали путь или воткнули лишний пробел.

#rsync