Это образец раздела документации продукта: устройство и принципы — без детальных спецификаций. Точные описания протокола, API и форматов предоставляются по запросу: hello@inter-forum.org.
Homyak — система серверного резервного копирования с централизованным хранением и контролем целостности. Состоит из агентов, которые снимают копии и передают их, и сервера хранения, который проверяет целостность принимаемых и хранимых данных, управляет копиями и отдаёт состояние по REST API.
Серверная часть и агенты написаны на Go и собираются из единой моно-репозитории. Кодовая база компактна: ~17 тыс. строк production-кода и ~10 тыс. строк тестов на весь комплекс — высокая плотность функциональности на объём кода упрощает аудит и сопровождение.
| Компонент | Назначение | Платформа |
|---|---|---|
homyak-server | Приём, хранение, контроль целостности, REST API | Linux |
homyak-agent-kvm | Копирование ВМ KVM/libvirt | Linux |
homyak-agent-mssql | Копирование баз MS SQL Server (BACKUP DATABASE) | Windows |
homyak-agent-pg | Копирование баз PostgreSQL (pg_dump -Fc) | Linux |
homyak-staging | Консолидированный слепок копий перед выгрузкой | Linux |
homyak-tape | Выгрузка staging-слепка на стример LTO | Linux |
homyak-genhash | Генерация argon2id-хэшей секретов агентов | Linux |
Жизненный цикл одной копии — от снятия на агенте до фоновой перепроверки на сервере:
Агент делает копию и считает SHA-256.
Потоковая передача во временный объект, с возобновлением после обрыва.
Сверка суммы и атомарный rename в финальный файл + манифест.
Фоновый сканер периодически пересчитывает суммы хранимых копий.
Общий HTTP-протокол для всех агентов: сервер принимает данные только от заранее настроенных агентов, каждый запрос аутентифицируется токеном. Загрузка двухшаговая — сначала описание копии (манифест), затем поток данных: все проверки проходят до начала длинной передачи, повторы идемпотентны. Обрыв крупной копии не означает перезаливку — передача возобновляется с последнего принятого байта.
# двухшаговая загрузка (упрощённо) шаг 1 манифест копии → аутентификация и проверки до передачи данных шаг 2 поток данных → сверка контрольной суммы → атомарная фиксация # отказоустойчивость обрыв → возобновление с последнего принятого байта повтор → идемпотентен, дублей не создаёт занято → имя существует — перезапись отклоняется
Контрольная сумма SHA-256 проверяется при приёме и затем периодически фоновым пересканированием уже сохранённых копий. Расхождения пишутся в отдельный журнал целостности и влияют на состояние здоровья сервера.
Режим «Копилка» — это модель write-once: агент может только добавлять копии. Удаление принятых данных по запросу агента не предусмотрено протоколом; стирание возможно лишь серверной retention-политикой или решением оператора. Без политики копия хранится бессрочно.
Сервер хранения накапливает историю копий каждого задания. Для выгрузки вовне нужен один консолидированный набор — эту задачу решает сервис homyak-staging: проходит по хранилищу и собирает слепок — по одному файлу на каждое задание (агент + БД/ВМ) — в отдельный каталог с описью. Прогон — демоном по cron-расписанию или вручную (--once).
# контур архивирования (упрощённо) основное хранилище — вся история копий → отбор: один файл на (агент + задание) слепок — самодостаточный набор + опись → атомарная публикация актуального слепка архив — запись слепка на кассету LTO → восстановление штатными средствами Linux, без ПО Homyak
Безопасность контура хранения обеспечивается непрерывным динамическим анализом уязвимостей на основе передовых моделей Claude Mythos 5 и Fable 5. Модель работает в adversarial-режиме — как атакующий, исследующий поверхность атаки сервера и протокола: пути записи и удаления данных, аутентификацию и авторизацию, изоляцию агентов, состояния гонки. Процесс встроен в цикл разработки и повторяется при каждом значимом изменении кодовой базы.
| Этап цикла | Содержание |
|---|---|
| Выявление (discovery) | Динамическое исследование поверхности атаки моделью в роли атакующего, по сценариям из модели угроз |
| Triage | Классификация находок по уровню критичности, регистрация с привязкой к коду |
| Митигация | Устранение в коде либо компенсирующие контроли (сетевые ACL, hardening конфигурации); принятие риска — только с документированным обоснованием |
| Регрессионная верификация | Повторный анализ: подтверждение закрытия находок и отсутствия деградации защитных свойств |
Сервер отдаёт машиночитаемое состояние — основа для мониторинга и ИИ-наблюдателей. Группы возможностей API:
| Группа | Возможности |
|---|---|
| состояние | Сводное здоровье сервера: агрегаты по агентам, целостности, хранилищу |
| агенты | Реестр, heartbeat, состояние последних заданий каждого агента |
| копии | Индекс копий с фильтрами и пагинацией, манифесты |
| целостность | Зафиксированные проблемы, квитирование оператором |
| приём | Загрузка копий агентами по протоколу (см. выше) |
Состояние агентов и сервера отдаётся машиночитаемым JSON: Zabbix снимает его штатным HTTP-агентом (JSONPath-препроцессинг), Prometheus — через стандартный json_exporter; доработки кода не требуются. Heartbeat агентов с настраиваемым тайм-аутом помечает «отвалившиеся» источники; события целостности идут в JSON-лог с ротацией.
Конфигурация — YAML, секреты — отдельно в .env; поведение меняется конфигом, без пересборки. Настраиваются, в частности:
Модульность (агенты ↔ общий протокол ↔ сервер) позволяет адаптировать систему под инфраструктуру заказчика: