Каталог, демоны, enterprise: что теряет админ, уходя с restic на Bacula

MAATRIX

Пока бэкапите один-два сервера, restic закрывает вопрос почти без усилий: один бинарник, одна команда, дедупликация и шифрование из коробки. Но когда серверов становится два десятка, у каждого свой владелец, а руководство спрашивает «покажите, что бэкап такого-то хоста реально существовал такого-то числа» — простоты restic перестаёт хватать. Bacula решает именно эту задачу: централизованное управление парком, каталог с историей всех бэкапов и гибкие политики хранения enterprise-уровня. Но за это придётся заплатить тем, что сегодня работает у вас без единой мысли — простотой развёртывания и владения.

Restic и Bacula — разный масштаб задачи с самого начала

Restic спроектирован под сценарий «один администратор, несколько серверов»: скачали бинарник, инициализировали репозиторий, запустили restic backup по cron или systemd-таймеру — и всё. Никакого сервера, БД или отдельной консоли управления. Репозиторий самодостаточен: вся информация о снапшотах лежит там же, где и данные, в зашифрованном виде.

Bacula изначально проектировалась для другого масштаба — резервного копирования корпоративной инфраструктуры с десятками и сотнями хостов, отдельной командой (или хотя бы ролью) администратора бэкапов, лентами и библиотеками для долгосрочного архива, требованиями подтверждать факт бэкапа перед аудиторами. Это клиент-серверная система: центральный узел управляет расписаниями и политиками, а на каждом сервере крутится собственный агент-демон. Идея не «запустить команду», а «управлять резервным копированием как отдельной подсистемой инфраструктуры» — и из этого расхождения в изначальном назначении вытекают все дальнейшие плюсы и минусы перехода: Bacula не «restic с большим функционалом», а принципиально другая архитектура под другую организационную модель.

Архитектура Bacula: три демона и БД вместо одного бинарника

Там, где restic — это один exe-файл, Bacula состоит минимум из четырёх компонентов, и каждый — отдельный процесс со своим конфигом:

• Director (bacula-dir, порт 9101) — мозг системы: хранит расписания, политики хранения (Pools), список клиентов и заданий (Jobs), управляет запуском бэкапов и обращается к каталогу.
• Storage Daemon (bacula-sd, порт 9103) — пишет данные на физический носитель (диск, ленточную библиотеку, автозагрузчик) и читает их обратно при восстановлении.
• File Daemon (bacula-fd, порт 9102) — агент на каждом бэкапируемом сервере: читает файлы с диска клиента и передаёт их Storage Daemon по сети, слушает постоянно как системный сервис.
• Console (bconsole или Bacula Web/BAT) — интерфейс администратора для запуска заданий, просмотра статуса и восстановления, подключается к Director по паролю и TLS-сертификату.

Restic в этом сравнении — как если бы все три роли были слиты в один процесс, который вы вызываете вручную. У Bacula они разделены намеренно: Director держат в одном дата-центре, Storage Daemon — рядом с лентами или дисковым массивом, File Daemon разъезжается по клиентским серверам. Для крупной инфраструктуры это удобно — хранилище масштабируется отдельно от управления. Для двух-трёх серверов это три процесса и три конфига там, где раньше был один cron-джоб.

Каждая пара демонов взаимодействует по паролю, заданному в обоих конфигах одновременно, и это первое, на чём спотыкаются при настройке — опечатка с одной стороны роняет соединение без внятной диагностики, кроме Authorization failed в логе.

Каталог: почему бэкап теперь зависит от отдельной базы данных

Ключевое архитектурное отличие Bacula от restic — каталог (Catalog). Это отдельная реляционная база данных (PostgreSQL, MySQL/MariaDB или SQLite для тестовых стендов), в которой Director хранит метаданные обо всех заданиях: какие файлы бэкапились, в каком job, на каком volume лежат данные, когда истекает retention. Восстановление файла проходит через SQL-запрос к каталогу, а не сканирование самого хранилища.

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

С каталогом Bacula эта самодостаточность исчезает. Данные лежат на Storage Daemon (диск или лента), а описание того, что где лежит, — в отдельной базе. Это классическая проблема курицы и яйца: если каталог потерян или повреждён, а тома с данными целы, восстановить конкретный файл напрямую нельзя — нужно либо восстановить каталог из его собственного бэкапа, либо запускать bscan, который читает все тома заново и пересобирает каталог с нуля, а на большом архиве это долго. Это тот случай, ради которого стоит отдельно продумать ротацию и срок хранения бэкапов — включая бэкап самого каталога.

Поэтому первое, что настраивают в продакшн-инсталляции Bacula, — отдельное задание Catalog Backup: штатный скрипт make_catalog_backup регулярно дампит саму БД каталога на отдельный носитель, вне зависимости от расписания клиентских бэкапов. Забыть про это — значит держать систему бэкапа, у которой нет бэкапа её собственного «мозга».

Что вы теряете, уходя с restic: простоту деплоя и владения

Перед тем как переходить, честно разберём, чем придётся пожертвовать — это не мелочи, а ежедневная эксплуатационная реальность.

• Один бинарник превращается в систему из процессов. Вместо apt install restic — установка Director, Storage Daemon и БД на одном сервере, File Daemon на каждом клиенте, настройка паролей и сертификатов между всеми парами. Первое развёртывание занимает часы, а не минуты, даже у того, кто уже читал документацию.
• Появляется постоянно слушающий сервис на каждом клиенте. File Daemon — системная служба с открытым портом 9102 на каждом сервере, а не разовый вызов из cron. Это лишняя поверхность атаки и процесс, который нужно патчить и перезапускать при сбое — того, чего у restic просто нет: он не оставляет после себя ничего, кроме файла кэша.
• Появляется критическая точка отказа — каталог. Восстановление зависит от здоровья отдельной БД, которую тоже нужно бэкапить, патчить и следить за её местом на диске.
• Нет нативной content-defined дедупликации, как у restic. Community-редакция экономит место через классическую схему Full/Differential/Incremental и синтетические полные бэкапы (Base Jobs), но блочной дедупликации по содержимому из коробки нет — за настоящий дедуп отвечают механизмы Enterprise-редакции или дедуп на уровне самого хранилища под томами SD. Это стоит проверить на этапе планирования, если экономия места была причиной перехода.
• Восстановление — это сессия, а не команда. У restic файл достаётся командой restic restore latest --include /path. У Bacula — через bconsole: команда restore, выбор клиента и job, построение дерева файлов через mark, постановка задания в очередь Storage Daemon. Для разового «достать конфиг за пять минут до дедлайна» это ощутимо тяжелее.
• Кривая обучения несравнима. У restic весь синтаксис — одна страница --help. У Bacula — сотни страниц документации по директивам, и ошибка в одной из них (не то имя ресурса, не тот пароль) часто даёт малопонятную ошибку авторизации без указания, где именно расхождение.

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

Что вы получаете: pools, volumes и retention для десятков серверов

Ради этих потерь Bacula даёт то, чего у restic нет в принципе, — управление резервным копированием как процессом, а не набором независимых команд.

Pools и Volumes. В restic политика хранения — это одна команда forget --keep-daily N --keep-weekly M на репозиторий. В Bacula можно завести отдельные Pools под разные категории данных с разной политикой: DailyPool с ротацией через 30 дней, MonthlyPool с хранением год, YearlyPool с ручным управлением томами для долгосрочного архива, который физически выносится с площадки (лента в сейф):

Pool {
  Name = MonthlyPool
  PoolType = Backup
  VolumeRetention = 365 days
  Recycle = yes
  AutoPrune = yes
}

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

Единая консоль на весь парк. Через bconsole видно статус всех заданий по всем серверам одновременно — какие прошли успешно, какие упали. У restic это собиралось бы самостоятельно, опросом restic snapshots на каждом сервере или через отдельный мониторинг бэкапов, который вы настраиваете сами.

Аудируемость через SQL-запросы к каталогу. Когда аудитор спрашивает «докажите, что сервер X бэкапился ежедневно весь прошлый квартал» — в Bacula это прямой запрос к каталогу:

SELECT Job.Name, Job.StartTime, Job.JobStatus
FROM Job JOIN Client ON Job.ClientId = Client.ClientId
WHERE Client.Name = 'web-01-fd' AND Job.StartTime >= '2026-06-01'
ORDER BY Job.StartTime DESC;

Это готовый машиночитаемый журнал, который можно выгрузить и приложить к отчёту. У restic такой структуры нет — есть snapshots --json, но это список снапшотов репозитория, а не централизованная история всех заданий по всей инфраструктуре с привязкой к клиенту и статусом каждого запуска.

Ленты и офлайн-архив. Если нужна физически изолированная копия данных (air-gapped, для соответствия регламентам или как последняя линия защиты от шифровальщика), Bacula умеет работать с ленточными библиотеками и автозагрузчиками из коробки на уровне Storage Daemon. У restic для того же сценария пришлось бы городить собственную схему выгрузки на съёмный носитель поверх файлового бэкенда.

Установка и базовая настройка на практике

Базовая связка на Debian/Ubuntu — Director с каталогом на PostgreSQL, Storage Daemon и один File Daemon на клиенте. Сначала поднимаем саму СУБД — если PostgreSQL ещё не установлен, разбор есть в статье про установку PostgreSQL на VPS. Дальше на сервере управления:

apt update
apt install bacula-director-pgsql bacula-sd bconsole postgresql

Имена пакетов чуть отличаются между дистрибутивами и версиями репозиториев — сверяйтесь со списком пакетов в вашем дистрибутиве. Фрагмент bacula-dir.conf:

Director {
  Name = bacula-dir
  DIRport = 9101
  Password = "смените-этот-пароль"
}

Client {
  Name = web-01-fd
  Address = 203.0.113.10
  FDPort = 9102
  Catalog = MyCatalog
  Password = "пароль-для-этого-клиента"
}

FileSet {
  Name = "WebServerFiles"
  Include {
    Options { signature = MD5; compression = GZIP }
    File = /etc
    File = /var/www
  }
  Exclude { File = /var/www/*/node_modules }
}

Schedule {
  Name = "DailySchedule"
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}

На клиентском сервере ставится только apt install bacula-fd, а в bacula-fd.conf достаточно имени, порта и того же пароля, что указан в блоке Client на Director:

FileDaemon { Name = web-01-fd; FDport = 9102 }
Director { Name = bacula-dir; Password = "тот-же-пароль-что-в-Client" }

Storage Daemon под файловое дисковое устройство (без лент):

Storage { Name = bacula-sd; SDPort = 9103 }

Device {
  Name = FileStorage1
  Media Type = File
  Archive Device = /mnt/backup/bacula-volumes
  LabelMedia = yes
  AutomaticMount = yes
}

Когда все три демона запущены и видят друг друга, работа идёт через bconsole:

*status dir
*run job=BackupWeb01Monthly
*list jobs
*restore

Команда restore откроет интерактивный выбор клиента, job и файлов — процесс многошаговый, но подробно описанный на каждом экране; просто он не укладывается в одну строку, как у restic.

Когда переход оправдан, а когда лучше остаться на restic

Если сомневаетесь — честный ориентир такой: пока вы один человек, который сам настраивал бэкап, сам его чинит и сам восстанавливает, лишняя инфраструктура Bacula работает против вас. Переход имеет смысл, когда бэкап перестаёт быть личной задачей одного администратора и становится процессом, за который отчитываются перед кем-то ещё — руководством, клиентом, аудитором. Ничто не мешает держать оба инструмента параллельно на переходный период, часть серверов уже под Bacula, часть — ещё на restic; логика выбора между «простой инструмент» и «система для парка» здесь похожа на то, чем restic лучше BorgBackup в похожих небольших сценариях.

Частые вопросы