Minarca: централизованный бэкап Linux-серверов для IT-аутсорсинга

Резервное копирование linux-серверов в аутсорсинговой практике — это не «настроил rsync на cron и забыл», а ежедневная работа с десятками клиентских инфраструктур, где у каждого свои квоты, расписания, требования к ретеншну и SLA по восстановлению. Когда у нас на сопровождении 30+ серверов разных заказчиков, скрипт-самописец превращается в технический долг: нет единой панели, нет уведомлений о пропущенных бэкапах, нет self-service для клиента.

Minarca от канадской IKUS Software — open-source решение поверх rdiff-backup с веб-интерфейсом, мульти-тенантной архитектурой и агентами под Linux, macOS и Windows. Никаких лицензионных платежей, дефолтный логин admin/admin123, демо на test.minarca.net, более 500 подписчиков рассылки и активное комьюнити в Google Group — мы развернули её для пяти клиентов и делимся практикой.

Minarca — open-source решение для централизованного резервного копирования, которое разрабатывает канадская компания IKUS Software. Архитектура простая и предсказуемая: на каждой защищаемой машине стоит агент, а в дата-центре или на офисном сервере — центральный Minarca-сервер с веб-интерфейсом. Агенты передают данные на сервер по защищённому каналу, сервер хранит инкрементальные резервные копии и показывает состояние всех заданий в одной панели. Лицензионных платежей нет, исходники открыты на GitLab, разработчик предлагает платную корпоративную поддержку для компаний из Канады, США и Европы — но в self-hosted сценарии она необязательна.

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

Для системных администраторов ценен встроенный дашборд: всё, что нужно проверить утром, уже агрегировано на одной странице. Сколько резервных копий прошло, сколько провалилось, у кого исчерпывается квота, какой клиент не выходил на связь больше суток. Проактивная система предупреждений шлёт алерты сразу, как только задание не отработало в окне расписания, что позволяет реагировать до того, как клиент сам заметит проблему. Для нас это означает соблюдение SLA по RPO без ручного обхода серверов.

Третья аудитория, на которую целится Minarca, — IT-энтузиасты и небольшие команды, которым нужен полный контроль над данными без облачных подписок. Self-hosted-развёртывание означает, что данные клиентов лежат на нашем железе или железе клиента, а не у внешнего вендора. Это критично для государственного сектора, медицины, юристов и любых компаний, где требования по локализации и хранению персональных данных запрещают облака. По данным сайта проекта, более 500 пользователей подписаны на новостную рассылку — это маленькое, но активное сообщество, в котором быстро отвечают в Google Group.

Главный технический фундамент — rdiff-backup. Это значит, что даже если Minarca-сервер однажды откажет или вы решите мигрировать, данные останутся читаемыми любым стандартным rdiff-backup-клиентом. Lock-in отсутствует, что для нас как подрядчика важно: клиент в любой момент может забрать архив и продолжить работу самостоятельно.

Minarca состоит из двух компонентов: серверной части и агента. Сервер — это Python-приложение, которое слушает порт 8080 для веб-панели и обрабатывает входящие соединения от агентов через SSH. Хранилище — обычная файловая система с rdiff-backup-репозиториями, по одному на каждый тенант. Это значит, что под капотом нет проприетарного формата: репозиторий можно открыть, скопировать, проверить целостность стандартными утилитами Linux.

rdiff-backup делает инкрементальные бэкапы файлового уровня. Первая копия — полная, последующие хранят только изменения и обратные diff-ы. Это позволяет откатываться к любой исторической версии файла, при этом занимая места почти столько же, сколько одна полная копия плюс цепочка изменений. На практике для нашего файлового сервера на 800 ГБ ежедневные инкременты занимают 5–15 ГБ. Восстановление любой даты — одна команда или клик в веб-интерфейсе.

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

Мульти-тенантная модель организована через учётные записи Minarca: каждый клиент — отдельный пользователь со своим домашним каталогом на сервере и квотой в гигабайтах. Изоляция строится на уровне файловой системы и SSH-ключей. Клиент A не может попасть в репозиторий клиента B даже теоретически, потому что у него нет ни прав на каталог, ни SSH-ключа на сервере. Для админов это означает, что не нужно поднимать отдельные виртуалки под каждого заказчика — одна установка обслуживает несколько проектов.

Транспорт между агентом и сервером — SSH с публичными ключами, ключи генерируются при подключении агента. Это снимает вопросы шифрования в полёте: трафик зашифрован тем же протоколом, которым все админы пользуются годами. Никаких самописных бинарных протоколов, никаких эзотерических TLS-конфигов. Если у клиента жёсткий firewall, открыть нужно один порт SSH в сторону Minarca-сервера.

Поверх SSH-туннеля rdiff-backup передаёт только diff-ы, что экономит трафик. Для удалённых филиалов с медленным каналом это критично — мы сократили нагрузку на интернет одного из клиентов с 200 ГБ в сутки (старый rsync) до 12–18 ГБ в сутки на Minarca без потери глубины истории.

Установка Minarca-сервера на Debian или Ubuntu укладывается в четыре команды и около 20 минут с учётом первого логина и смены пароля. Разработчик публикует подписанный APT-репозиторий, что снимает вопрос целостности пакетов: ключ загружается отдельно и кладётся в /etc/apt/keyrings, как требует современный Debian.

Сначала качаем GPG-ключ репозитория: curl -L -o /etc/apt/keyrings/minarca-keyring.asc https://www.ikus-soft.com/archive/public.asc. Затем создаём файл /etc/apt/sources.list.d/minarca.sources с описанием источника, в котором поля Types: deb, URIs: https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/, Suites: $(lsb_release -sc), Components: main, Architectures: amd64 и Signed-By, указывающий на загруженный ключ. После этого apt update подтягивает метаданные, apt install minarca-server разворачивает приложение и зависимости.

Сервис стартует автоматически на порту 8080. Открываем http://127.0.0.1:8080/ и логинимся под дефолтной учёткой admin / admin123. Первое, что делаем после первого входа, — меняем пароль администратора и создаём отдельную учётку для работы. Дефолтные креды известны всем, оставлять их в продакшне — приглашение для сканеров. Заодно настраиваем reverse-proxy на nginx или Apache с TLS-сертификатом от Let’s Encrypt, потому что в открытом виде по 8080 веб-панель пускать нельзя.

До серьёзной нагрузки полезно покрутить демо. Разработчик держит публичный стенд на test.minarca.net — там можно зайти, потыкать веб-интерфейс, проверить, как выглядит дашборд и формы создания пользователей. Это экономит час на принятии решения «подходит — не подходит» до того, как мы тратим время на боевое развёртывание.

Под нагрузку для аутсорсинга мы рекомендуем минимум 4 vCPU, 8 ГБ ОЗУ и быстрый диск под /var/backups. Размер хранилища считается просто: суммарный объём защищаемых данных всех клиентов плюс 30–50% на инкрементальную историю за выбранный retention. Если планируется 10 клиентов по 200 ГБ с историей 30 дней — закладывайте 3–4 ТБ под репозитории. Файловая система — XFS или ext4, ZFS-снапшоты сверху не требуются, но не повредят как дополнительный уровень защиты от случайного удаления самих репозиториев.

После установки агенты под Windows, macOS, Debian и Ubuntu качаются с download-страницы проекта и подключаются к серверу по адресу и токену из веб-панели. Документация на www.respira… то есть в официальной wiki проекта закрывает остальные сценарии: миграцию, обновления, ручную сборку из исходников.

На стороне клиента мы ставим пакет minarca-client из того же APT-репозитория, что и сервер. Агент существует в двух вариантах: графический и командной строки. Для серверных Linux-машин без рабочего стола всё делается через minarca-client (CLI). На рабочих станциях пользователь сам запускает графический сетап.

Подключение происходит в три шага. Сначала в веб-панели сервера мы создаём нового пользователя, выдаём логин, пароль и квоту. Затем на клиентской машине запускаем minarca-client и вводим адрес сервера, логин и пароль. Агент генерирует SSH-пару ключей, берёт с сервера хост-ключ и регистрирует себя. На третьем шаге мы выбираем, что именно бэкапить, и задаём расписание.

Отбор файлов работает по принципу белых и чёрных списков: include-пути (/etc, /home, /var/lib/postgresql, /srv) и exclude-паттерны (/var/cache, *.tmp, *.swp, node_modules). Для Linux-серверов мы по умолчанию бэкапим /etc, /home, /root, а также специфичные каталоги приложений — /var/lib/mysql или /var/lib/postgresql в виде регулярных dump-ов, а не живых файлов базы. Расписание в Minarca выражается в простых пресетах (hourly, daily, monthly) или cron-выражении. Мы выбираем daily, потому что почасовые бэкапы на файловом уровне редко оправданы — базы проще реплицировать.

Квоты выставляем сразу, не «потом посмотрим». Практика: берём объём защищаемых данных, умножаем на 1.5 для истории и добавляем 20% резерва. Для клиента с 200 ГБ данных это около 360 ГБ квоты. Когда порог достигается, Minarca присылает алерт — мы реагируем расширением за дополнительную плату или вынуждаем клиента прибраться в источнике данных.

SSH-ключи хранятся в домашнем каталоге пользователя на сервере в ~/.ssh/authorized_keys. В панели можно отозвать ключ или всю учётку, если клиентская машина скомпрометирована. История бэкапов при этом остаётся и доступна для восстановления, даже если исходная машина выключена вместе со всем каталогом.

Отдельный важный момент — оверлейные pre/post-хуки. На Linux мы вешаем pg_dumpall или mysqldump в pre-script, чтобы к моменту бэкапа на диске уже лежал consistent dump базы. Это покрывает слабое место файлового резервного копирования — невозможность безопасно рвать живые данные СУБД на файловом уровне.

Резервные копии нужны ради восстановления, и именно здесь Minarca раскрывается для аутсорсинга. Сценариев три: пользователь сам восстанавливает файл, инженер роллбэчивает каталог на дату, или происходит полное disaster recovery с нового железа. Каждый покрыт отдельными инструментами.

Self-service-восстановление работает через веб-интерфейс Minarca. Клиент заходит под своим логином, выбирает путь в бэкапе, видит все версии файла по датам и скачивает нужную. По нашей статистике этот сценарий закрывает 70–80% всех обращений от клиентов: «удалили файл, верните как было в понедельник». Раньше это вызывало инженера на 30 минут — теперь клиент решает за две минуты.

Для инженеров работает CLI rdiff-backup напрямую. Команда rdiff-backup –restore-as-of 7D /var/backups/<tenant>/etc/nginx /tmp/restore вытащит состояние конфигов nginx на семь дней назад. Когда клиент «вчера всё ломали, верните как было» — это именно такой случай, причём откат мы делаем во временный каталог и ручкой разбираемся, что именно разломали. Автоматическое «просто переписать» в production-каталог без разбора ведёт к новым инцидентам.

Полное disaster recovery выглядит так: поднимаем чистый Linux, ставим minarca-client, подключаем к серверу под учёткой пострадавшего клиента и командой minarca-client restore вытягиваем всё хранилище обратно на диск. Время восстановления зависит от объёма и канала. Для 200 ГБ по гигабитному линку это порядка 30–40 минут без учёта оверхеда SSH; для филиальных каналов 100 Мбит/с закладываем 4–6 часов.

Отдельный сценарий — выборочное восстановление конфига. Пример: клиент сломал /etc/nginx/sites-available/, нужно вернуть один файл. В веб-интерфейсе открываем путь, нажимаем «версии», видим все изменения за последние 30 дней, скачиваем нужную. Суммарное время с момента звонка клиента — около пяти минут вместо получаса «подключись по SSH, найди репозиторий, вытяни копию».

Критичный момент для SLA — регулярная проверка восстановления. Раз в месяц мы делаем тестовый restore одного клиента на временный сервер и сверяем md5-суммы ключевых каталогов. Без этого бэкап-система юридически существует, но фактически не проверена.

Встроенных алертов Minarca в базовом виде хватает для одиночного инженера. Сервер умеет отсылать почту о пропущенных заданиях, о превышении квот и о сбоях во время работы. Для аутсорсинга этого мало: 30+ серверов и почта от каждого о каждой проблеме быстро превращаются в фоновый шум. Мы выводим мониторинг в Zabbix.

Minarca-сервер пишет журнал бэкапов в SQLite-базу и выдаёт статусы через веб-API. На хосте с Zabbix агентом мы ставим скрипт user-parameter, который ходит в API Minarca и выдаёт два числа: количество успешных бэкапов за последние 24 часа и количество провалившихся. На эти метрики вешаем триггеры: больше 0 провалов любого клиента — warning, больше 24 часов без успеха — critical. С триггеров идёт извещение в дежурный чат с именем клиента и сроком простоя.

Отдельно мы проверяем размер репозиториев. Резкий рост объёма обычно означает одно из двух: клиент залил огромный файл и исчерпал квоту, либо в бэкап попало что-то лишнее — бинарная база без dump-а, видеофайлы, временные файлы. Алерт в Zabbix с порогом +20% за сутки срабатывает в обоих случаях.

По опыту первые две недели после внедрения Zabbix-интеграции всплывают 5–7 «тихих» проблем. Один агент не связывался с сервером с января, потому что cron-задание было сломано при обновлении ОС. Другой клиент фактически бэкапил только /etc, а /home выпал из конфига. Сами без мониторинга вы это обнаружите только в момент восстановления, и это репутационный риск.

Для Prometheus-стеков подход тот же: выполняем скрипт, выдающий metric-строки в формате textfile collector node_exporter, и следим за метриками minarca_backup_failed_total и minarca_backup_age_seconds. Alertmanager с тремя правилами (failed > 0, age > 86400, age > 172800) закрывает боевые сценарии. Один винтик поверх Minarca — выбор любого привычного инструмента мониторинга.

Отдельно логи Minarca мы перенаправляем в централизованный журнал через rsyslog или vector. Это нужно для аудита: кто и когда ресторил какие файлы. Если клиент приходит с вопросом «вы ничего не портили?», мы вытаскиваем лог за нужный день и показываем, что все восстановления были инициированы ими самими с собственного IP.

Minarca — не единственный self-hosted вариант для резервного копирования linux. Реальных конкурентов три: UrBackup, BorgBackup и Bacula. Каждый решает задачу по-своему, и выбор зависит от модели бизнеса. Мы разворачивали все четыре на клиентских площадках и получили чёткую картину.

UrBackup силён в образных бэкапах Windows и быстром bare-metal восстановлении. Для чисто файловых Linux-серверов это избыточно: образы растут быстрее, мульти-тенантности нет из коробки. Если в парке много Windows-рабочих станций — UrBackup выигрывает. Для аутсорсинга Linux-инфры выбор в пользу Minarca.

BorgBackup — любимец энтузиастов благодаря сильной дедупликации и шифрованию on-disk. Дедупликация работает на уровне блоков: официальная документация приводит соотношения 10:1 и выше, на практике экономия составляет 50–90%+ в зависимости от схожести данных. Но у Borg нет официального веб-интерфейса для клиентского self-service — клиент не вытащит файл без инженера. Хороший выбор для одного администратора, но не для аутсорсера.

Bacula — ветеран рынка для enterprise. Директор, Storage Daemon, каталог в PostgreSQL, конфиги на собственном языке. Три дня на первую рабочую конфигурацию — норма. Для IT-аутсорсинга МСБ это дорого.

Итог: резервное копирование linux через Minarca выигрывает там, где нужна мульти-клиентская модель, быстрый старт и self-service для клиента. UrBackup и BorgBackup остаются в арсенале для image-бэкапа Windows и экстремальной дедупликации. Bacula — для крупных enterprise-инфраструктур с лентами.

Ответы на часто задаваемые вопросы по теме статьи.