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

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

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

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

• Копирование больших файловых деревьев на NAS — быстрее и стабильнее, чем scp.
• Миграции между серверами — один раз полный перенос, потом несколько инкрементальных перед переключением.
• Зеркалирование конфигов и исходников между разработческими машинами.
• Простые ежедневные снимки, когда не нужны инкременты за месяц.

# Базовый бэкап файл-сервера на 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 выигрывает в экономии места за счёт блочной дедупликации. На данных, где много повторяющихся файлов (образы ВМ, дампы БД), разница ещё больше — я видел соотношение 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 ГБ RAM. 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-совместимых облаков.