На 30 Linux-серверах клиентов бэкапы работали. Или нам так казалось. После перехода на Minarca — open-source платформу с мульти-тенантной архитектурой — за первые две недели мы нашли 5–7 тихих проблем на серверах, где раньше всё «было зелёным».
Почему rsync с cron перестаёт работать при масштабировании
Типичная картина у нового клиента: rsync в cron, скрипт из 2015 года, бэкап уходит куда-то на /backup. Никаких алертов, никакого мониторинга. Приходим восстанавливать после сбоя — и выясняется, что бэкап не делался три месяца: сменился пароль, лежал удалённый сервер, закончилось место.
Когда клиентов больше десяти, такая схема превращается в минное поле. У каждого — свой сервер, своё расписание, своя политика хранения. Без единой панели просто не видно, что происходит.
Ещё один минус rsync — трафик. На одном объекте уходило 200 ГБ в сутки. rdiff-backup, на котором работает Minarca, передаёт только изменения и обратные дельты: тот же клиент — 12–18 ГБ в сутки, та же глубина истории.
Что такое Minarca и как она устроена
Minarca — открытая платформа от канадской IKUS Software. Два компонента: сервер и агент.
Сервер слушает порт 8080 для веб-панели и принимает подключения агентов через SSH. На каждого клиента — отдельный аккаунт с квотой и своей директорией. Клиент А не видит репозиторий клиента Б: разные SSH-ключи, разные права доступа на уровне файловой системы.
В основе rdiff-backup: каждый последующий бэкап хранит только изменения и обратные дельты. Это позволяет восстановить любую версию файла на любую дату одной командой или кликом в браузере. При этом на диске занимает столько же, сколько одна полная копия плюс цепочка изменений — для 800 ГБ файлового сервера суточный инкремент составит 5–15 ГБ.
Агент ставится на защищаемые машины — Linux, macOS, Windows. На серверах без десктопа работает через CLI. При первом подключении сам генерирует SSH-ключ и регистрируется на сервере. Исходники открыты на GitLab, лицензия бесплатная.
Установка за 20 минут и подключение первых клиентов
На Debian или Ubuntu — четыре команды APT. Сервис запускается автоматически на порту 8080. Первый вход: admin / admin123 — менять сразу.
Дальше: создаём аккаунт клиента в веб-панели, задаём квоту. На клиентской машине ставим minarca-client из того же репозитория, вводим адрес сервера и логин — агент сам генерирует ключ и регистрируется. Выбираем директории (/etc, /home, /var/lib), настраиваем расписание.
Расчёт квоты простой: объём защищаемых данных × 1,5 + 20% резерв. Для клиента с 200 ГБ данных — квота около 360 ГБ.
Через веб-панель клиент сам восстанавливает файлы: выбирает путь, видит версии по дате, скачивает нужную. Это закрывает 70–80% обращений «верните файл» без участия инженера. Раньше такое обращение занимало 30 минут, стало — 2 минуты.
Мониторинг: как находить тихие сбои до клиентского звонка
Встроенные алерты Minarca — email при пропущенном задании или превышении квоты. Для 30+ серверов этого недостаточно: письма теряются в потоке.
Решение — интеграция с Zabbix через API Minarca. Скрипт на хосте с Zabbix-агентом опрашивает API и возвращает два числа: успешных бэкапов за 24 часа и ошибок. Триггеры: больше 0 ошибок — предупреждение; больше 24 часов без успешного бэкапа — критично. Оповещение идёт в дежурный чат с именем клиента и временем простоя.
Для стеков на Prometheus подход зеркальный: скрипт выводит строки метрик для textfile collector node_exporter. Alertmanager с тремя правилами — failed > 0, age > 86400, age > 172800 — закрывает операционные сценарии.
После подключения мониторинга мы нашли за первые две недели:
- один агент не выходил на связь с января — после обновления ОС сломался cron
- у другого клиента из конфигурации бэкапа выпал /home — фактически бэкапился только /etc
- ещё в двух случаях агент пропустил несколько ночных заданий из-за перегруженного канала
Без мониторинга это обнаруживается только при восстановлении — и это репутационный риск.
Где Minarca выигрывает у BorgBackup и Bacula
BorgBackup — мощная блочная дедупликация (реальные примеры: 10:1 и выше), шифрование на диске. Нет официального веб-интерфейса для клиентского self-service: клиент не может достать файл сам, без инженера. Отлично для одного администратора, не подходит для реселлера с десятками клиентов.
Bacula — промышленное решение с Director, Storage Daemon и каталогом на PostgreSQL. Три дня до первого рабочего конфига — нормальный срок. Оправдан для корпораций с ленточными библиотеками, для малого и среднего ИТ-аутсорсинга — избыточен.
UrBackup выигрывает на Windows-образах и быстром bare-metal восстановлении. Для чисто Linux-окружения без встроенной мультитенантности уступает Minarca.
Minarca выигрывает в связке: быстрый старт + мульти-тенантность + self-service для клиента. Все три компонента из коробки, без допиливания.
IT For Prof внедряет и сопровождает Minarca для IT-аутсорсинговых компаний: подключение всех Linux-машин, настройка квот и Zabbix-интеграции, контроль SLA — без облаков и лицензионных платежей.