Резервное копирование Linux-серверов: rsync vs BorgBackup на практике

Привет! Это Евгений Семёнов, директор АйТи Фреш. За пятнадцать с лишним лет в IT мне доводилось всякое: от спасения случайно удалённой базы 1С до борьбы с последствиями шифровальщиков, которые намертво блокировали целые файл-серверы. Знаете, каждый раз приходишь к одному и тому же: бэкап, который ни разу не проверили на восстановление — это просто красивое, но абсолютно бесполезное обещание. В этой статье я поделюсь нашим опытом и детально сравню два инструмента, с которыми мы реально работаем в боевых условиях: старый добрый rsync и наш современный фаворит — BorgBackup. Разберёмся, когда что лучше использовать.

Rsync: проверенный временем

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

• Нужно перекинуть огромное файловое дерево на NAS? С Borg это будет куда быстрее и, главное, стабильнее, чем мучиться с scp. Проверено нами!
• А как насчёт миграций между серверами? С Borg всё просто: делаем один раз полный перенос данных. А потом, прямо перед финальным переключением, несколько быстрых инкрементальных копий. Всё готово, можно переезжать!
• Для нас важно, чтобы у всех разработчиков был одинаковый набор инструментов и настроек. Поэтому мы регулярно зеркалируем конфиги и исходники. Это не просто копирование файлов; это гарантия, что каждый член команды работает с актуальной и идентичной версией проекта. Такой подход минимизирует ошибки и значительно ускоряет весь процесс разработки. Ведь согласитесь, кто хочет тратить время на исправление различий в окружении?
• Знаете, не всем и не всегда нужны сложные инкрементальные бэкапы за целый месяц. Иногда важна максимальная простота и свежая копия данных. Что тогда делать? Мы предлагаем простые ежедневные снимки. Они идеально подходят, когда вам не нужны глубокие архивы изменений, а просто хочется иметь быстрый, актуальный «слепок» системы за каждый день. Это гораздо эффективнее, чем гоняться за каждым микроизменением, когда в этом нет реальной необходимости.

# Базовый бэкап файл-сервера на NAS
rsync -aHAX --delete \
  --exclude='*.tmp' --exclude='/tmp/' --exclude='/proc/' \
  /srv/ backup@nas.office.local:/backups/srv/

# Флаги: -a (archive), -H (hard links), -A (ACL), -X (xattrs), --delete (удалять на целевой то, что нет на исходной)

Проблема rsync — он не даёт истории. Если вы ежедневно делаете rsync --delete, то вчерашняя версия перетирается сегодняшней. Для истории нужен rsync + hard links (схема rsnapshot):

# Упрощённая схема rsnapshot-подобного бэкапа
TODAY=$(date +%F)
YESTERDAY=$(date -d 'yesterday' +%F)
BACKUP_ROOT=/backup/fileserver

rsync -aHAX --delete \
  --link-dest=$BACKUP_ROOT/$YESTERDAY \
  /srv/ $BACKUP_ROOT/$TODAY/

В чём кайф такой схемы? Мы получаем так называемые 'прозрачные' инкременты. Представьте: каждая папка за конкретный день выглядит как полноценная копия данных. Но при этом никаких гигабайтов дубликатов! За счёт hard links неизменившиеся файлы остаются физически одними и теми же. Вот пример из нашей практики: для файлового сервера на 800 ГБ 30 дневных копий занимают всего 1.1 ТБ. Конечно, реальный объём всегда зависит от того, как часто и сильно меняются данные.

BorgBackup: дедупликация и шифрование из коробки

А вот BorgBackup — это уже совсем другой уровень! Считайте, серьёзный апгрейд, современная альтернатива связке rsync+rsnapshot. Он написан на Python и C, поэтому работает очень эффективно. А что он умеет? Прекрасно себя чувствует как по SSH, так и локально. В его арсенале блочная дедупликация, прозрачное сжатие, и, что совершенно необходимо в наши дни, — надёжное шифрование.

sudo apt install borgbackup  # Debian/Ubuntu
sudo dnf install borgbackup  # RHEL/Rocky

# На целевом сервере создаём репозиторий
ssh backup@nas 'borg init --encryption=repokey-blake2 /backup/borg/server1'

# Первый бэкап
borg create \
  --stats --progress \
  --compression zstd,9 \
  --exclude-caches \
  --exclude '/proc/*' --exclude '/sys/*' --exclude '/tmp/*' \
  backup@nas:/backup/borg/server1::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
  / /home /var/www /etc

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

Сравнение rsync vs Borg в цифрах

Чтобы не быть голословным, я специально провёл замеры на одном из наших типовых офисных файл-серверов. Там у нас 850 ГБ данных, ежедневная дельта составляет примерно 8 ГБ, а общее количество файлов — около 250 тысяч. Результаты такие:

Borg просто чемпион по экономии места! И всё это благодаря его волшебной блочной дедупликации. Представьте, если у вас на сервере тонны повторяющихся файлов — например, десятки образов виртуальных машин или ежедневные дампы баз данных. Вот тогда разница в занимаемом объёме становится по-настоящему впечатляющей! Мы лично видели, как Borg давал фантастическое соотношение 5:1 по месту. Это очень круто.

Рабочая схема с Borg и retention

Как мы обычно настраиваем это всё у клиентов? Я всегда делаю бэкап через свой скрипт, а для автоматического запуска использую проверенный systemd-таймер. Вот что обычно входит в сам скрипт:

#!/bin/bash
# /usr/local/bin/borg-backup.sh
set -euo pipefail

export BORG_PASSCOMMAND="cat /root/.borg-passphrase"
export BORG_REPO="backup@nas.office.local:/backup/borg/server1"

BACKUP_NAME="{hostname}-{now:%Y-%m-%dT%H:%M}"

borg create \
  --stats --show-rc \
  --compression zstd,9 \
  --exclude-caches \
  --exclude '/proc' --exclude '/sys' --exclude '/dev' \
  --exclude '/run' --exclude '/tmp' \
  --exclude '/var/cache' --exclude '/var/tmp' \
  --exclude '/var/lib/docker' \
  "::${BACKUP_NAME}" \
  / /home /etc /var/www /var/lib/postgresql

borg prune \
  --list --show-rc \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --keep-yearly 2

borg compact

Systemd-таймер:

# /etc/systemd/system/borg-backup.service
[Unit]
Description=BorgBackup daily
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/borg-backup.sh
Nice=19
IOSchedulingClass=idle

# /etc/systemd/system/borg-backup.timer
[Unit]
Description=Daily BorgBackup
[Timer]
OnCalendar=03:15
RandomizedDelaySec=900
Persistent=true
[Install]
WantedBy=timers.target

Восстановление

Но ведь главное, зачем мы вообще заморачиваемся с бэкапами, — это возможность быстро всё восстановить, верно? И вот тут Borg предлагает несколько очень удобных вариантов:

# Список архивов
borg list backup@nas:/backup/borg/server1

# Содержимое конкретного архива
borg list backup@nas:/backup/borg/server1::server1-2025-03-11T03:15

# Восстановление одного файла
cd /tmp/restore
borg extract backup@nas:/backup/borg/server1::server1-2025-03-11T03:15 \
  home/user/important.xlsx

# Монтирование архива как FUSE-файлсистемы
borg mount backup@nas:/backup/borg/server1::server1-2025-03-11T03:15 /mnt/borg
ls /mnt/borg
umount /mnt/borg

Бэкап PostgreSQL и MySQL правильно

Копировать /var/lib/postgresql напрямую — это рецепт катастрофы. Нужен логический дамп или pg_basebackup перед стартом Borg:

# PostgreSQL
pg_dumpall --clean --if-exists | \
  gzip > /var/backups/pg/all-$(date +%F).sql.gz

# Или физический бэкап через pg_basebackup
pg_basebackup -D /var/backups/pg/base -Ft -z -P

# MySQL / MariaDB
mariadb-dump --all-databases --single-transaction --routines --triggers \
  | gzip > /var/backups/mysql/all-$(date +%F).sql.gz

Полученные dump-файлы мы потом уже спокойно пакуем в Borg-архив. В результате получаем консистентный бэкап, который сработает даже для самой 'живой' базы данных. Всё чисто, ничего не потеряется!

Кейс: инцидент с шифровальщиком и восстановление за 4 часа

Хотите реальный пример? Вот вам свежий кейс. В октябре 2025 года к нам обратился клиент — это крупная строительная компания из Московской области, у них около 60 рабочих мест. Они 'словили' шифровальщика. Заражение, как водится, пришло через скомпрометированный RDP. Что произошло? Всего за одну ночь этот гад прошёлся по всему файловому серверу, намертво зашифровав 420 ГБ важнейшей проектной документации. Можете себе представить: утром нам позвонили… и, сами понимаете, что там была за паника.

Хорошо, что мы за год до этого настроили Borg-бэкапы на отдельный NAS в дата-центре МТС с pull-моделью (NAS сам тянет бэкапы по SSH, шифровальщик с сервера не имел к нему push-доступа). Подняли чистую виртуалку, восстановили архив двухдневной давности командой borg extract. 420 ГБ вытащили за 3 часа 20 минут, ещё 40 минут на проверку целостности и перенастройку доступов. Потерь данных — минимум 8 часов работы, но не недели как было бы без бэкапов.

Что за 'железо' было у клиента? Сервер — HP ProLiant DL380 Gen10 с процессором Xeon Silver 4214 и 64 ГБ оперативной памяти. А вот для бэкапов у них стоял NAS: Synology RS3621xs+ с дисками Seagate Exos по 16 ТБ, настроенный в RAID-6. Сколько стоило всё это спасение? Общая сумма наших работ по восстановлению составила 85 000 рублей. В эту стоимость, кстати, вошли не только сами работы, но и наше собственное расследование инцидента, а также 'закаливание' системы (harden'инг), чтобы подобное больше не повторялось.

Что НЕ делать при настройке бэкапов

• Хранить бэкапы на том же сервере. При аппаратном сбое или RW-шифровальщике теряете всё сразу.
• Не тестировать восстановление. У нас на практике 1 из 5 клиентов, у которых якобы «всё бэкапится», не может восстановить БД из-за битых или неполных dump'ов.
• Push-модель к NAS без изоляции. Сервер, который умеет писать на NAS, может и стереть бэкапы. Нужен pull или append-only режим.
• Длинная парольная фраза на репозитории, потерянная в никуда. Без BORG_PASSPHRASE репозиторий не открыть. Храните в password manager команды + плюс офлайн-копию.
• Не мониторить успешность. Бэкап должен писать в Prometheus textfile или слать уведомление в Telegram. Молчаливый сбой — худший вариант.

FAQ — частые вопросы о бэкапах Linux

В чём разница между rsync и BorgBackup?

rsync копирует файлы as-is. Borg делает дедупликацию и шифрование, хранит инкременты в компактном репозитории.

Как часто делать бэкапы?

Стандарт 3-2-1. Критичные данные — каждые 1-4 часа, рядовые — раз в сутки.

Как проверить, что бэкап рабочий?

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

Нужно ли шифровать резервные копии?

Если вне защищённого периметра — обязательно. Borg шифрует по умолчанию.

BorgBackup или Restic — что выбрать?

Borg — для SSH-репозиториев, Restic — для S3-совместимых облаков.