11.08.2026 08:06
L1qu1dVacuum 0 3100 Источник

Привет, Хабр! Это снова Денис — тимлид инфраструктурной Core‑команды в Timeweb Cloud.

В прошлой статье я разбирал живые миграции: NBD, RDMA, switchover за сотни миллисекунд и прочий внутренний хардкор платформы. Там было весело инженерам. Сегодня же поговорим про другое удовольствие.

Вот у нас снова есть клиент. У него есть сервер. На сервере — жизнь бизнеса: сайт, база, файлы, пара скриптов «временно, но уже третий год». И где‑то в голове тихо живёт мысль:

«Бэкапы? Конечно. Сделаем. После релиза. И отпуска. И вот этого срочного.»

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

Если ждали 40 экранов про внутренности Bareos — выдохните. Сегодня я буду продавать спокойный сон. Он, между прочим, тоже продукт.

❯ Минутка увлекательной истории: Bacula, Bareos и плёнка

Прежде чем тыкать в tfvars, стоит понимать, кого мы вообще поднимаем.

Когда‑то бэкап «по‑взрослому» пах машинным залом и звучал как перемотка. Магнитная лента — она же плёнка в широком смысле — была единственным ответом на вопрос «куда спрятать копию, чтобы диск с оригиналом не унёс её с собой в могилу». Библиотеки кассет, оператор с тележкой, ночной full на воскресенье. Романтика дата‑центра нулевых.

В этом мире и вырос Bacula: open‑source система сетевого бэкапа авторства Керна Сиббалда. Не «скрипт, который копирует /home», а нормальная схема: Director раздаёт задания, File Daemon на клиенте отдаёт данные, Storage Daemon пишет их на носитель. Пулы, тома, retention, restore «достань файл из прошлого вторника» — всё это лексика с ленточных времён. Даже когда носитель уже S3, а не кассета в слоте, в голове у системы всё ещё живут volume и pool. Потому что задача та же: надёжно унести копию туда, где оригинал не достанет.

Потом экосистема раздвоилась. В 2010 из Bacula вырос форк Bareos — Backup Archiving Recovery Open Sourced. Та же идея, активная community‑ветка, привычный стек. Если Bacula — дедушка корпоративного open‑source бэкапа, то Bareos — родственник, с которым сегодня проще жить в облаке: WebUI, нормальные пакеты, понятная документация.

Зачем это, если есть rsync и «папка на соседнем диске»? Потому что бэкап — не копирование файлов. Это расписание, каталог «что где лежит», политика хранения, отдельное хранилище и сценарий восстановления, который сработает без Серёги. Bacula/Bareos как раз про это выросли: из мира плёнки — в мир дисков и объектов. Мы просто перестали возить кассеты и начали писать в Cold S3. Дух тот же. Руки — свободнее.

Ну а дальше — без ностальгии по ленточкам: клиент, сервер с данными и мысль «сделаем бэкапы после релиза».

❯ Когда «у нас же есть бэкапы» внезапно становится сюжетом

Обычный выделенный сервер. На нём всё важное. Рядом — папка с гордым именем backup_final_FINAL_v3_new. Иногда даже cron. Иногда даже «вроде работает».

А потом случается одно из двух. Либо человек удаляет не то. Либо диск, обновление или чья‑то «небольшая правка» делают это за него. И начинается любимый корпоративный квест:

  • А куда мы складывали бэкапы?

  • А они свежие?

  • А почему они лежат на том же сервере, который только что умер?

  • А кто помнит пароль от этой базы?

В этот момент бэкап перестаёт быть скучной галочкой и становится единственным способом вернуть бизнес к жизни. «Восстановим как‑нибудь» — это не план. Это надежда, а надежда плохо монтируется в /restore.

У хорошего бэкапа требования простые:

  • он живёт не там, где оригинал;

  • переживает потерю одного сервера или одной базы;

  • через полгода его всё ещё можно понять без телепатии;

  • его поднимают не «по памяти Серёги», а по повторяемому сценарию.

Вот это я и упаковал в облачный Infrastructure as Code.

❯ Что вы получаете, если не хотите собирать зоопарк руками

Картинка максимально бытовая.

У вас есть сервер, который надо бэкапить. Вы не хотите вручную заказывать VDS, ставить софт, отдельно поднимать Postgres, отдельно создавать S3, отдельно настраивать файрвол и отдельно придумывать пароли, чтобы потом найти их в Telegram самому себе в три ночи.

Вместо этого вы говорите системе примерно так:

→ Вот IP сервера.
→ Вот путь.
→ Вот сколько хранить полные и инкрементальные копии.
→ Вот с каких сетей пускать в админку.

А дальше — сам.

После terraform apply поднимается не «сервер с Bareos и надеждой», а нормальная связка:

  • Bareos Director — мозг системы бэкапов;

  • managed PostgreSQL — каталог заданий в облачной БД с репликацией;

  • Cold S3 — хранилище самих бэкапов;

  • Приватная сеть — Director и база разговаривают по локалке, а не через публичный интернет;

  • Firewall — наружу торчит только нужное;

  • Автопароли — чтобы P@ssw0rd1 остался в мемах, а не в проде.

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

❯ Панель прекрасна. Но бэкап — это не один клик

Панель управления я люблю. Создать сервер, глянуть метрики, перезагрузить услугу — удобно и быстро.

Но бэкапная инфраструктура — это уже набор связанных решений. Если собирать её кликами, через месяц получается фольклор:

  • Postgres «где‑то рядом»;

  • S3 «вроде тот самый бакет»;

  • Файрвол «открыли временно»;

  • Пароли «в заметках / в чате / в голове»;

  • Инструкция по restore — «спроси у того парня, он в отпуске».

Infrastructure as Code тут не про моду и не про резюме. Это про то, чтобы схема была описана, повторяема и не держалась на героизме одного человека.

Раньше бэкап часто собирали руками и надеялись, что «так и задумано».
Теперь ту же схему можно поднять одинаково хоть для одного клиента, хоть для десятка.

Раньше каталог Bareos мог жить в Docker на том же хосте «ну пока так».
Теперь это отдельный managed Postgres с репликами, да ещё и в приватной сети с Director.

Раньше фраза «давайте пересоздадим» звучала как угроза.
Теперь это нормальный сценарий: тот же манифест, те же параметры, тот же результат.

❯ Все муки человечества в одном — в terraform.tfvars

Самое классное в этом подходе: клиенту не нужно становиться экспертом по провайдеру, Ansible и внутренностям Bareos. Ему нужно ответить на понятные вопросы. Почти как в анкете — только эта анкета потом сама поднимает инфраструктуру.

«Просто забэкапьте мне /home»

# IP сервера, который вы будете бекапить
backup_ip = "203.0.113.50"

# Путь к директории которую вы будете бекапить
backup_fileset_path = "/home"

# Размер вашего бекапного хранилища в гигабайтах
storage_size = 500

# Сколько дней хранить полные бэкапы
full_backup_retention = 10

# Сколько дней хранить инкрементальные бэкапы
incremental_backup_retention = 30

Это уже рабочий минимум, серьёзно. Больше похоже на «заполни и забудь», чем на инфраструктурный проект.

«И базу тоже, пожалуйста»

Если на сервере есть MySQL или PostgreSQL, которые тоже жалко потерять:

backup_database_type = "postgres"
your_postgresql_admin = "backup_user"
your_postgresql_password = "very-long-and-boring-password"

Никакой магии: сказали системе, что бэкапить, — она это учитывает.

«Только не светите админку всему интернету»

Вот тут начинается взрослая жизнь. SSH и WebUI лучше пускать не с 0.0.0.0/0, а со своей сети:

# Сети с доступом по SSH
ssh_allowed_cidrs = ["203.0.113.10/32", "10.10.0.0/16"]

# Сети с доступом к Bareos WebUI
webui_allowed_cidrs = ["203.0.113.10/32"]

Для первого запуска можно оставить широко — чтобы apply с ноутбука не превратился в квест «почему SSH не пускает». Для продакшена лучше сразу указать свои CIDR. Будущий вы скажет спасибо сегодняшнему вам. Желательно без мата.

❯ Как это выглядит в жизни

Мой любимый тезис: cценарий специально сделан скучным. Скучный — значит хороший.

Весь код лежит в открытом репозитории: github.com/L1qu1dVacuum/timeweb_bareos.

Там же кнопка зелёная Code → копируете URL и клонируете:

git clone https://github.com/L1qu1dVacuum/timeweb_bareos.git
cd timeweb_bareos/terraform

Дальше — токен API из раздела API и Terraform в панели Timeweb Cloud:

export TWC_TOKEN="..."

Правите terraform.tfvars. Запускаете:

terraform init
terraform plan
terraform apply -auto-approve

Дальше можно идти пить чай. Когда вернётесь, в выводе уже будут доступы. Пароли генерируются сами — не нужно заранее изобретать «надёжную комбинацию из даты рождения и клички кота.

На выходе у вас:

  • адрес Director;

  • WebUI;

  • доступы к каталогу;

  • уже настроенная связка под бэкап указанного сервера.

Если совсем по‑человечески, путь такой:

Репозиторий → tfvars → export TWC_TOKEN → apply → бэкапная инфраструктура.

И вот это, пожалуй, главный продуктовый вкус всей истории. Не «смотрите, сколько тут YAML». А «смотрите, как мало вам надо знать, чтобы получить нормальный результат».

❯ Почему это не «поставили агент и надеемся»

Раз статья для Хабра, совсем без устройства нельзя, но обойдёмся без экзорцизма.

Bareos Director живёт на своём облачном сервере. Сами бэкапы уезжают в Cold S3. Каталог заданий — в managed PostgreSQL. Director и база сидят в одной приватной сети и ходят друг к другу по локалке. Публичный IP базе для этого не нужен — и это правильно: сервисы не должны болтать через интернет просто потому, что «так проще было настроить».

Бэкап «на тот же диск рядом» — это не бэкап. Это клон проблемы в соседней папке.

Раньше в похожих схемах Postgres часто поднимали локально в Docker. Быстро, уютно... пока не вспоминаешь, что уютный контейнер на том же хосте не спасает, если хост внезапно стал музейным экспонатом. Поэтому каталог вынесен в облачную БД с репликацией.

С файрволом тоже без философии «откроем всё, потом закрутим». На Director снаружи нужны по сути SSH, WebUI и порт Storage Daemon — чтобы клиентский сервер мог отдавать данные. Postgres пускает только Director из приватной сети. Сети для SSH и WebUI клиент задаёт сам в tfvars.

Terraform здесь не цель. Цель — чтобы бэкапная схема была продуктом, а не ритуалом с танцами.

А ещё IaaC даёт бытовые суперспособности, за которые обычно готовы платить нервами:

  • одинаково поднимать стенд для разных клиентов;

  • через полгода понимать, что именно было задумано;

  • не бояться кнопки «пересоздать»;

  • делать review изменений инфраструктуры, а не телепатировать их в чате.

❯ Облако подняли. Теперь пять минут на сам дедик

Один момент, без которого статья была бы сладкой рекламой.

Terraform собирает сторону облака: Director, каталог, S3, сеть, файрвол.

Но бэкапить‑то предстоит ваш сервер. А значит, на нём должен появиться агент Bareos — bareos-filedaemon. Без него Director будет красиво жить в облаке и грустно смотреть в сторону вашего дедика.

Хорошая новость: это уже не «собрать инфраструктуру», а короткий ритуал на стороне клиента. После apply Terraform как раз покажет пароль пользователя бэкапа и готовый кусок конфига директора. Его и переносите на сервер.

Ставим filedaemon

Ubuntu 22.04:

wget -qO- https://download.bareos.org/current/xUbuntu_22.04/add_bareos_repositories.sh | sh
apt update && apt install bareos-filedaemon -y
systemctl enable --now bareos-filedaemon.service

RHEL 9:

firewall-cmd --permanent --add-port={80,443,9101,9102,9103}/tcp && firewall-cmd --reload
wget https://download.bareos.org/current/EL_9/bareos.repo -O /etc/yum.repos.d/bareos_EL_9.repo
yum makecache && yum install bareos-filedaemon -y
systemctl enable --now bareos-filedaemon.service

Подключаем сервер к Director

В /etc/bareos/bareos-fd.d/director/bareos-dir.conf кладёте конфиг, который выдал мой сценарий после создания пользователя. Выглядит примерно так:

Director {
Name = "bareos-dir"
Password = "[md5]e9c62e92c3ddcf8ccf2bd3adb98dfb6e"
TlsEnable = no
TlsRequire = no
}

И перезапускаете службу:

systemctl restart bareos-filedaemon.service

Важная мелочь, на которой обычно спотыкаются: TlsEnable = no и TlsRequire = no нужны и на клиенте, и на стороне Director. Иначе они будут очень культурно не понимать друг друга.

Если бэкапите ещё и базы

Для файлов хватает filedaemon. Для баз — чуть интереснее, но без фанатизма.

Сначала включаете плагины в /etc/bareos/bareos-fd.d/client/myself.conf:

Client {
Name = my-server-fd
TLS Enable = no
TLS Require = no
Plugin Directory = "/usr/lib64/bareos/plugins"
Plugin Names = "python3"
}

MySQL — ставите Percona XtraBackup и плагины Bareos.

Ubuntu:

wget https://downloads.percona.com/downloads/Percona-XtraBackup-8.0/Percona-XtraBackup-8.0.32-26/binary/debian/jammy/x86_64/percona-xtrabackup-80_8.0.32-26-1.jammy_amd64.deb
dpkg -i percona-xtrabackup-80_8.0.32-26-1.jammy_amd64.deb
apt install bareos-filedaemon-python3-plugin bareos-filedaemon-percona-xtrabackup-python-plugin

RHEL:

wget https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.32-26/binary/redhat/9/x86_64/percona-xtrabackup-80-8.0.32-26.1.el9.x86_64.rpm
yum localinstall percona-xtrabackup-80-8.0.32-26.1.el9.x86_64.rpm
yum install bareos-filedaemon-python3-plugin bareos-filedaemon-percona-xtrabackup-python-plugin

PostgreSQL — плагины и pg8000:

Ubuntu:

apt install bareos-filedaemon-python3-plugin bareos-filedaemon-postgresql-python-plugin
apt install python3-pip
pip3 install pg8000

RHEL:

yum install bareos-filedaemon-python3-plugin bareos-filedaemon-postgresql-python-plugin
yum install python3-pip
pip3 install pg8000

Для Postgres ещё включаете WAL‑архивацию в postgresql.conf:

max_wal_size = 10GB
min_wal_size = 100MB
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/wal_archive/%f'
archive_timeout = 60

Создаёте каталог и применяете:

mkdir -p /var/lib/pgsql/wal_archive
chown postgres:postgres /var/lib/pgsql/wal_archive
chmod 700 /var/lib/pgsql/wal_archive
systemctl reload postgresql

И не забываете пустить Director к базе в pg_hba.conf, если внешний доступ у Postgres не открыт всем подряд:

host    all    all    <bareos_external_ip>/32    md5

После этого — systemctl restart postgresql.

Да, руками. Но это уже не сборка облака из нуля, а короткая настройка агента на сервере, который вы и так администрируете. Terraform забирает скучную тяжёлую часть. Вам остаётся сказать дедику: «теперь ты умеешь отдавать бэкапы».

А можно ли завернуть и этот кусок в Ansible‑плейбук, чтобы вообще ничего руками не тыкать? Можно, а зачем?. Даже нужно. Я просто поленился, честно говоря. Если у вас руки чешутся автоматизировать дальше, клиентская сторона идеально ложится всего в одну роль: поставить пакет, положить конфиг, рестартнуть сервис. Я оставил вам это удовольствие.

❯ Кому это стоит попробовать

Если у вас есть выделенный или облачный сервер с данными, которые жалко потерять, — вам сюда.

Если хочется бэкап по‑взрослому, но без полугодового внедрения, — тоже сюда.

Если команда уже устала от авторских поделок «у каждого клиента по‑своему» — особенно сюда.

А если вам достаточно одного tar.gz раз в квартал на флешку — можно не мучить Terraform. Правда, флешки тоже иногда теряются. Обычно в самый интересный момент.

Всем остальным обычно хватает трёх ответов: что бэкапить, куда складывать, как долго хранить. Облачную сторону я упаковал. На дедике остаётся поставить filedaemon и, если нужно, плагины под базы.

Перед запуском проверьте только очевидное: реальный backup_ip, адекватный путь (бэкапить / «на всякий случай» — идея так себе), размер хранилища, политику хранения и свои сети для SSH/WebUI. Потом terraform apply, сохраните доступы нормальным способом — не скрином в семейном чате — и донастройте агент на самом сервере.

Если после этого система поднялась, а вы так и не написали do_backup_please.sh — день прошёл не зря.

❯ А теперь самое вкусное

Облако круто не тем, что сервер создаётся быстро. Это уже все умеют. Облако круто тем, что вокруг сервера можно собрать нормальную обвязку — базу, объектное хранилище, приватную сеть, доступы — и превратить это в сценарий, который повторяется.

Бэкапы особенно хорошо показывают разницу.

Инфраструктура как набор кликов — вы надеетесь, что всё вспомните.

Инфраструктура как код — открываете terraform.tfvars и видите источник истины.

Я специально сделал сценарий простым:

  • Клиент отвечает на понятные вопросы в одном файле;

  • Terraform поднимает облачные ресурсы;

  • На выходе — рабочая система резервного копирования, а не конструктор для выходных.

Если после этой статьи бэкап перестанет быть страшилкой из категории «сделаем потом» и станет обычным шагом рядом с созданием сервера — значит, всё получилось.

Код, как и обещал, здесь: github.com/L1qu1dVacuum/timeweb_bareos. Жать на Code, клонировать, править tfvars, export TWC_TOKEN, terraform apply. Дальше — чай.

А если вас это не устраивает — ну что ж. Всегда можно продолжать хранить судьбу проекта в папке backup_final_FINAL_v3_new.

Я вас предупредил. И даже оставил более вкусный вариант.

P. S. За вдохновение спасибо Серёге.

Может быть интересно:
Перейти ↩

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram‑канале ↩

Комментарии (0)