Резервное копирование · 13 мин чтения

BorgBackup для Linux-серверов офиса: моя схема для клиентов в Москве

Меня зовут Семёнов Евгений Сергеевич, я уже 15 лет занимаюсь IT-обслуживанием корпоративных офисов в Москве и Подмосковье. У меня в АйТи Фреш сейчас под обслуживанием 28 офисов с Linux-серверами — 1С на PostgreSQL, файловые сервера на Samba, веб-сайты на Nginx, корпоративные чаты на Mattermost. На все эти серверы я ставлю BorgBackup. Расскажу почему и как.

Почему я отказался от rsync, tar и платных решений

Шесть лет назад у меня был стандартный набор: rsync для файлов, mysqldump для баз, tar для архивов и Veeam для VM-инфраструктуры. Всё работало, всё было привычно. Пока в один прекрасный день у клиента — типография, 22 рабочих места, сервер 1С на PostgreSQL — не накрылся RAID-контроллер.

Бэкапы у клиента вроде как делались. Каждую ночь cron-скрипт делал mysqldump базы (но это PostgreSQL, и скрипт писал какой-то предыдущий администратор лет пять назад) и rsync на NAS. Когда я приехал восстанавливать, оказалось:

В общем, бэкапа у клиента не было. Восстанавливали базу из логов 1С за месяц вручную силами оператора и бухгалтера. После этого случая я начал серьёзно изучать профессиональные инструменты резервного копирования и остановился на Borg как основном решении для всех Linux-машин.

Что мне в нём понравилось:

Архитектура: где хранить бэкапы

Прежде чем говорить о настройке Borg, разберёмся с местом хранения. Самая распространённая ошибка — хранить бэкапы на том же сервере, который вы бэкапите. Я в практике придерживаюсь правила «3-2-1»: три копии данных, на двух разных типах носителей, одна копия — географически удалённая.

Для типичного клиента с офисом 25 ПК и одним Linux-сервером моя схема такая:

Стоимость такой схемы для клиента — около 8 500 руб./мес за хранилище в дата-центре + разовая стоимость NAS (от 45 тыс. руб. за модель на 2 диска по 4 TB). За три года владения ровно одного раза эта схема спасла данные после атаки шифровальщика на офис в Подольске — клиент восстановился за 6 часов вместо месяцев переписывания договоров.

Установка и инициализация репозитория

Borg есть в репозиториях всех современных Linux-дистрибутивов. На Debian/Ubuntu:

apt install borgbackup
borg --version  # должно быть 1.2 или выше

На CentOS/Rocky/AlmaLinux через EPEL:

dnf install epel-release
dnf install borgbackup

Создаём репозиторий. Я делаю его на NAS, который примонтирован через NFS или SMB на сервере как /mnt/backup:

borg init --encryption=repokey-blake2 /mnt/backup/srv01

На этом этапе Borg попросит ввести пароль для шифрования. Этот пароль я генерирую через pwgen 32 1 и сохраняю в трёх местах: KeePass-базу клиента, мой собственный KeePass АйТи Фреш и бумажку в сейфе у директора. Если потеряете пароль — данные потеряны навсегда. AES-256 не подбирается.

Тип шифрования repokey-blake2 я выбираю осознанно: ключ хранится внутри репозитория и зашифрован паролем. Это удобно, потому что не нужно отдельно бэкапить ключевой файл — он уже там. Альтернатива keyfile-blake2 требует отдельного бэкапа ключевого файла, что добавляет геморрой.

Скрипт ежедневного бэкапа

Дальше — основной скрипт, который запускается по cron каждую ночь в 02:30. Я его шлифую уже шесть лет, вот текущая версия для типового сервера 1С с PostgreSQL:

#!/bin/bash
set -euo pipefail

export BORG_PASSPHRASE="ваш_пароль_сюда"
export BORG_REPO="/mnt/backup/srv01"
export BORG_RSH="ssh -i /root/.ssh/borg_key"

LOG_FILE="/var/log/borg/$(date +%Y-%m-%d).log"
HOSTNAME=$(hostname -s)
TIMESTAMP=$(date +%Y-%m-%d-%H%M)

# 1. Дамп PostgreSQL
echo "[$(date)] Dumping PostgreSQL..." | tee -a $LOG_FILE
sudo -u postgres pg_dumpall | gzip > /tmp/pgdump_${TIMESTAMP}.sql.gz

# 2. Borg-бэкап
echo "[$(date)] Creating Borg archive..." | tee -a $LOG_FILE
borg create \
    --verbose --stats --show-rc \
    --compression zstd,9 \
    --exclude '/proc' --exclude '/sys' --exclude '/dev' \
    --exclude '/var/log' --exclude '/tmp' --exclude '/run' \
    --exclude '/var/lib/postgresql' \
    --exclude '/var/cache' \
    ::"${HOSTNAME}-${TIMESTAMP}" \
    /etc /home /opt /root /srv /usr/local /var \
    /tmp/pgdump_${TIMESTAMP}.sql.gz 2>&1 | tee -a $LOG_FILE

# 3. Удаление дампа
rm -f /tmp/pgdump_${TIMESTAMP}.sql.gz

# 4. Применение политики хранения
echo "[$(date)] Pruning old archives..." | tee -a $LOG_FILE
borg prune --verbose --list \
    --keep-daily=14 --keep-weekly=8 --keep-monthly=12 \
    2>&1 | tee -a $LOG_FILE

# 5. Compact
borg compact 2>&1 | tee -a $LOG_FILE

# 6. Уведомление
if [ "${PIPESTATUS[0]}" -eq 0 ]; then
    curl -s "https://api.telegram.org/botTOKEN/sendMessage" \
        -d "chat_id=CHAT_ID" \
        -d "text=Backup ${HOSTNAME} OK"
else
    curl -s "https://api.telegram.org/botTOKEN/sendMessage" \
        -d "chat_id=CHAT_ID" \
        -d "text=BACKUP ${HOSTNAME} FAILED!"
fi

Несколько важных моментов в скрипте, которые я выработал на практике:

Восстановление: три рабочих сценария

Самое полезное в Borg — простота восстановления. Покажу три самых частых сценария из моей практики.

Сценарий 1: пользователь случайно удалил файл. Бухгалтер потёр папку с отчётами в shared. Звонит, паникует. Подключаюсь через SSH к серверу и за минуту восстанавливаю:

borg mount /mnt/backup/srv01::srv01-2026-04-16-0230 /mnt/restore
cp -r /mnt/restore/srv/shared/buh/2026-04 /srv/shared/buh/
borg umount /mnt/restore

Сценарий 2: упала база 1С. Накануне был успешный бэкап. Восстанавливаем PostgreSQL дамп:

borg extract --list /mnt/backup/srv01::srv01-2026-04-16-0230 \
    tmp/pgdump_2026-04-16-0230.sql.gz
gunzip /tmp/pgdump_*.sql.gz
sudo -u postgres psql < /tmp/pgdump_*.sql

Сценарий 3: полный bare-metal restore. Сервер сгорел, есть свежее железо. Ставим минимальный Linux, монтируем NAS, ставим Borg, восстанавливаем:

borg extract /mnt/backup/srv01::srv01-2026-04-16-0230
# Дальше восстановить PostgreSQL из дампа, проверить /etc, перезагрузиться

Реальное время bare-metal восстановления для офисного сервера на 1С — 3–5 часов с момента готовности железа. У меня в SLA для клиентов «Премиум»-тарифа этот показатель закреплён в договоре с штрафом 5000 руб. за каждый час просрочки.

Тестирование бэкапов: то, чего почти никто не делает

Здесь начинается самое неприятное. Я регулярно слышу от коллег: «У нас бэкапы делаются». Но когда я спрашиваю «когда вы последний раз ИЗ них восстанавливались» — повисает молчание. У 80 % компаний, которые приходят ко мне на аудит, бэкапы есть, но никто никогда не проверял, можно ли из них восстановиться.

В АйТи Фреш я ввёл квартальное тестирование. Раз в три месяца мы поднимаем тестовую VM, развёртываем туда последний бэкап и проверяем работоспособность. На стандартном клиенте это занимает 4–6 часов работы инженера, но это ровно те часы, которые отделяют «у нас вроде всё в порядке» от «мы реально готовы к катастрофе».

Скрипт автоматического тестирования через borg check:

#!/bin/bash
borg check --verbose --repository-only /mnt/backup/srv01
borg check --verbose --archives-only --last 3 /mnt/backup/srv01

Запускается еженедельно, занимает на 200-гигабайтном репозитории около 40 минут. Если check ругается — значит, в репозитории битые данные, нужно срочно разбираться.

Удалённое хранение через SSH

Для географически распределённой копии я использую второй сервер в дата-центре, на который Borg пишет напрямую через SSH:

borg init --encryption=repokey-blake2 \
    backup-user@backup.example.com:/storage/srv01

borg create \
    backup-user@backup.example.com:/storage/srv01::srv01-{now} \
    /etc /home /srv

На принимающей стороне нужен SSH-доступ с ограниченным окружением. В /home/backup-user/.ssh/authorized_keys я прописываю:

command="borg serve --restrict-to-path /storage/srv01 --append-only" ssh-rsa AAAA...

Флаг --append-only крайне важен: он означает, что даже если злоумышленник получит SSH-ключ, он не сможет удалить старые бэкапы, только добавить новые. Это защита от криптолокеров, которые научились искать и шифровать также ваши бэкапы.

borgmatic: красивый wrapper для тех, кто не любит писать скрипты

Если вам не нравится поддерживать кучу bash-скриптов, есть инструмент borgmatic — Python-обёртка, где вся конфигурация описывается в YAML:

location:
    source_directories:
        - /etc
        - /srv
        - /var/lib/mysql
    repositories:
        - /mnt/backup/srv01
storage:
    encryption_passphrase: "пароль"
    compression: zstd,9
retention:
    keep_daily: 14
    keep_weekly: 8
    keep_monthly: 12
hooks:
    postgresql_databases:
        - name: all
    healthchecks: https://hc-ping.com/UUID

Удобно тем, что есть встроенные хуки для PostgreSQL, MySQL, MongoDB и интеграция с healthchecks.io / ntfy / telegram. Я использую borgmatic у клиентов, где сам сервер обслуживается их штатным админом — ему проще читать YAML, чем разбирать мои bash-скрипты.

Настроим бэкапы вашего Linux-сервера за один день

Я лично провожу аудит вашей резервной системы и составляю работающую схему 3-2-1 под ваши задачи. Бесплатный выезд по Москве и в радиусе 50 км от МКАД, гарантия восстановления данных по договору.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — частые вопросы по BorgBackup

Чем BorgBackup лучше rsync или tar?
Borg делает дедупликацию на уровне блоков данных: одинаковые куски сохраняются один раз. На бэкапах VM или баз данных это даёт экономию места в 10–30 раз по сравнению с tar и в 3–5 раз по сравнению с rsync с hardlink.
Подходит ли Borg для Windows-серверов?
Нативно — нет, Borg только для Linux/BSD/macOS. Для Windows-серверов мы используем Veeam B&R или Restic, у которого похожая идеология. Borg отлично подходит для Linux-серверов 1С на CentOS/Debian, веб-серверов и LXC.
Сколько места нужно для репозитория?
С учётом дедупликации — 2–4 объёма исходных данных при политике хранения 30 дней. Для офисного сервера с 200 GB полезных данных хватает диска на 1 TB на 6–12 месяцев бэкапов.
Где хранить пароль репозитория?
Обязательно в нескольких местах: KeePass с шифрованием, бумажный архив в сейфе у директора и резервная копия у IT-аутсорсера. Без пароля Borg-репозиторий неотличим от случайного шума.
Можно ли восстановить отдельный файл из бэкапа?
Да, через borg mount репозиторий монтируется как обычная папка через FUSE. Дальше работаете как с любым файловым деревом — копируете нужное и размонтируете.

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.