BorgBackup для Linux-серверов офиса: моя схема для клиентов в Москве
Резервное копирование · 13 мин чтения

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

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

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

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

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

Бэкапы, как обычно, 'вроде как делались'. Ночью запускался cron-скрипт, который пытался делать mysqldump базы. Только вот незадача: база-то была на PostgreSQL, а скрипт, как выяснилось, накатал какой-то прошлый админ лет пять назад, причём явно под MySQL. Ещё там был rsync на NAS. Когда я приехал спасать ситуацию, восстанавливать что-либо, оказалось вот что:

В общем, если честно, бэкапа у клиента НЕ БЫЛО совсем. Представляете? Мы месяц вручную восстанавливали базу из логов 1С, и этим занимались оператор с бухгалтером! После такого я понял: всё, хватит. Нужно срочно, и очень серьёзно, изучать нормальные, профессиональные инструменты для резервного копирования. Так я и вышел на Borg. Теперь это наше основное решение для всех Linux-машин, без вариантов.

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

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

Ладно, прежде чем нырять в дебри настройки Borg, поговорим о самом главном. Куда же, черт возьми, эти бэкапы вообще складировать? Знаете, самая частая, просто гигантская ошибка, которую я вижу снова и снова, — это хранить резервные копии прямо на том же сервере, который вы якобы защищаете. Какой в этом смысл? Мы в ITFresh всегда, БЕЗОГОВОРОЧНО, следуем правилу «3-2-1». Что это значит? Три копии данных, две из них на разных типах носителей, и обязательно, просто кровь из носу, одна копия — где-то далеко, географически удалённо.

Вот как выглядит наша проверенная схема для обычного клиента: офис на 25 ПК и всего один Linux-сервер. Схема, которую мы применяем, выглядит так:

Сколько это стоит? Наша схема обходится клиенту примерно в 8 500 рублей в месяц за удалённое хранилище в дата-центре. Плюс, конечно, единоразовые расходы на NAS — это где-то от 45 тысяч рублей за модель с двумя дисками по 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 часов. Причём считаем мы это с момента, как железо готово к работе. А для клиентов на нашем «Премиум»-тарифе этот показатель, между прочим, жёстко закреплён в договоре. Если мы задерживаемся, платим штраф: 5000 рублей за каждый час просрочки. Мы этим очень гордимся!

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

И вот тут начинается самое скользкое и неприятное. Вы не представляете, сколько раз я слышу от коллег: «Да, конечно, у нас бэкапы делаются, всё пучком!» Но стоит мне задать один-единственный вопрос: «А когда вы последний раз реально ИЗ НИХ что-то восстанавливали?» — и, как правило, повисает гробовая тишина. Мои наблюдения, честно говоря, печальны: у 80% компаний, что приходят к нам на аудит, бэкапы-то может и есть. Вот только никто и никогда не проверял, получится ли из них хоть что-то поднять в случае чего.

Именно поэтому мы в АйТи Фреш давно ввели железное правило: квартальное тестирование бэкапов. Что это значит на практике? Раз в три месяца мы не просто делаем бэкап, а поднимаем отдельную тестовую виртуальную машину, развёртываем туда самый свежий бэкап и, что самое важное, ПРОВЕРЯЕМ ЕГО РАБОТОСПОСОБНОСТЬ. Для стандартного клиента это занимает всего 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 подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.