● Серверное резервное копирование

Копии, которые нельзя потерять и нельзя стереть

Homyak — программный комплекс серверного резервного копирования: специализированные агенты, центральный сервер хранения с контролем целостности и архивный ленточный контур. Спроектирован как последняя линия обороны данных: write-once хранение, верифицируемая целостность, минимальная поверхность атаки.

Почему Homyak → Документация
01 · киберустойчивость

Write-once хранение

В протоколе нет операции удаления: компрометация источника — включая ransomware-сценарий — не затрагивает уже принятые копии.

режим «Копилка» → 02 · целостность

Верифицируемая сохранность

SHA-256 при приёме и плановый фоновый пересчёт хранимого массива: «тихая» деградация носителя фиксируется до восстановления, а не во время.

контроль целостности → 03 · источники

Промышленные агенты

KVM/libvirt, MS SQL Server, PostgreSQL на едином протоколе: потоковая передача копий ~150 ГБ с возобновлением после обрыва.

функционал → 04 · эксплуатация

API-first, без UI

Машиночитаемое состояние для Zabbix, Prometheus и ИИ-наблюдателей. Нет веб-интерфейса — нет классических веб-векторов атаки.

мониторинг → 05 · независимость

Восстановление без вендора

Архив на ленте LTO в открытом формате: восстановление штатными средствами любого Linux — mt, tar, sha256sum, без ПО Homyak.

архивный контур →
// контур хранения — под непрерывным adversarial-анализом уязвимостей моделями Claude Mythos 5 · Fable 5 · ~17 тыс. строк Go
// strengths

Сильные стороны платформы

Девять принципов, на которых построен Homyak — от платформенной независимости и компактной кодовой базы до непрерывного анализа безопасности хранения передовыми моделями.

⛓️
01

Платформенная независимость

Серверная часть и агенты написаны на Go и собираются под Linux и Windows из единой кодовой базы. Сервер хранения не привязан к ОС защищаемых узлов — агенты специализируются под платформу (KVM/libvirt, MS SQL, PostgreSQL), протокол общий.

go · linux · windows
🐷
02

Режим «Копилка» (WORM)

Данные попадают в хранилище без возможности удаления со стороны агента. В протоколе нет операции стирания принятой копии: занятое имя файла отклоняется, перезапись невозможна. Удаление — только по серверной retention-политике или решением оператора.

append-only · write-once
🛡️
03

Контроль и целостность хранения

Контрольная сумма SHA-256 проверяется при приёме копии и периодически пересчитывается фоновым сканером уже сохранённых данных. Каждый файл сопровождается манифестом с суммой и описанием. Найденные расхождения попадают в integrity-лог и влияют на состояние здоровья.

sha-256 · manifest · rescan
🎛️
04

Гибкость в настройках

Конфигурация — YAML, секреты — в .env. Настраиваются расписания (cron), политики хранения, параллелизм приёма, отдельные хранилища под агентов, ротация логов. Поведение меняется конфигом, без пересборки.

yaml · .env · cron
🤖
05

Контроль ИИ-системами из коробки

Полностью машиночитаемый интерфейс: REST API о состоянии и структурные JSON-логи. Это позволяет ИИ-агентам и LLM-наблюдателям опрашивать систему, интерпретировать события целостности и принимать решения без человеко-ориентированных адаптеров.

rest · json-logs · machine-first
🚪
06

Без интерфейса — меньше атак

Отсутствие веб-интерфейса — осознанное преимущество. Нет фронтенда — нет лишней кодовой базы, нет классических веб-уязвимостей и, как следствие, низкий уровень векторов атаки. Управление — через API и конфиги.

headless · low attack surface
📈
07

Мониторинг Zabbix / Prometheus

Состояние агентов, heartbeat и здоровье сервера отдаются единым машиночитаемым JSON-эндпоинтом. Zabbix снимает его штатным HTTP-агентом, Prometheus — через стандартный json_exporter. Доработки кода для подключения мониторинга не требуются.

zabbix · prometheus · health
📐
08

Эффективная кодовая база

Весь комплекс — сервер хранения, сервис staging, три специализированных агента и модуль ленточной выгрузки — это ~17 тыс. строк production-кода Go и ~10 тыс. строк тестов. Высокая плотность функциональности на объём кода: меньше кода — меньше дефектов, быстрее аудит, дешевле сопровождение.

~17k loc · feature/loc
🔬
09

Динамический анализ передовыми моделями

Контур хранения непрерывно проходит динамический анализ уязвимостей на основе передовых моделей Claude Mythos 5 и Fable 5: модель в adversarial-режиме исследует поверхность атаки, находки проходят triage и митигируются кодом или компенсирующими контролями.

mythos · fable 5 · continuous analysis
✦
+

Технологичный дизайн

Инженерный подход в продукте и в подаче: предсказуемое поведение, явные ограничения, документированная архитектура и готовность к доработкам под специализированные задачи заказчика.

engineering-grade
// технологично

Режим «Копилка»: данные входят, но не выходят

«Копилка» — это модель хранения write-once. Агент только добавляет копии; удалить или подменить уже принятый файл он не может технически.

  • Атомарная фиксация. Копия собирается во временном объекте и фиксируется атомарно только после сверки контрольной суммы; повторная запись под занятым именем отклоняется.
  • Нет delete-операции для агента. Протокол агент→сервер не содержит запроса на стирание принятых данных.
  • Удаление — только политикой. Срок жизни задаётся серверной retention-политикой; по умолчанию копия живёт бессрочно.
  • Скомпрометированный агент безопасен. Захват узла-источника не приводит к потере уже сохранённых копий.
write-once · схема
# принцип приёма копии (упрощённо)
приём
  → потоковая запись во временный объект
  → сверка контрольной суммы с манифестом
  → атомарная фиксация в хранилище

# повторная запись под занятым именем
→ отказ — перезапись запрещена

# удаление по запросу агента
→ операции не существует
// concept

Концепция решения

Разделение ответственности: агенты делают копии и передают их, сервер — проверяет, хранит и отдаёт состояние. Между ними — единый протокол.

01

Агент копирует

Специализированный агент снимает копию (KVM-домен, базу MS SQL или PostgreSQL) и считает контрольную сумму.

02

Передача на сервер

Копия стримится на сервер хранения по протоколу с аутентификацией каждого запроса и возобновлением загрузки после обрыва.

03

Проверка и хранение

Сервер сверяет SHA-256, пишет манифест, фиксирует копилку и фоном перепроверяет данные.

04

Состояние по API

REST API и JSON-логи отдают здоровье, целостность и статус агентов — людям и ИИ-системам.

// functionality

Краткое описание функционала

Что система делает сегодня — компактный набор, сфокусированный на сохранности копий.

🗄️ Централизованное хранение

Единый сервер хранения принимает копии от заранее настроенных агентов, раскладывает их по агентам и ведёт индекс всех копий с манифестами.

🔁 Фоновый контроль целостности

Планировщик периодически пересчитывает суммы хранимых копий, фиксирует «тихую» порчу данных и отражает её в integrity-логе и в health.

📦 Консолидированный слепок (staging)

Сервис homyak-staging по расписанию или вручную собирает слепок: по одной актуальной копии на каждое задание (агент + БД/ВМ), с опциональной пересверкой SHA-256 при отборе и двойной описью — машиночитаемой для автоматизации и табличной для оператора. Публикация атомарна: актуальный слепок всегда целостен.

📼 Выгрузка на ленту LTO

Модуль homyak-tape пишет staging-слепок на стример LTO в платформонезависимом формате с каталогом кассет: восстановление любым Linux штатными mt + tar + sha256sum, без ПО Homyak.

⏱️ Retention и политики хранения

Срок жизни копий задаётся политикой; просроченные удаляются сервером по расписанию. Без политики — бессрочное хранение (копилка).

🖥️ Агент KVM/libvirt

Резервное копирование виртуальных машин: live-режим и cold-copy выключенных ВМ, учёт UEFI/NVRAM, по расписанию.

🧱 Агент MS SQL

Копии баз Microsoft SQL Server через нативный BACKUP DATABASE, потоковая передача крупных баз, состояние заданий.

🐘 Агент PostgreSQL

Логические копии баз через нативный pg_dump -Fc: каждая база — отдельная копия, охват all/list, отдельный срез ролей и tablespaces (globals), restore через pg_restore.

// security

Проверка безопасности хранения

Программный комплекс проходит проверку хранения на базе моделей Claude Mythos 5 и Fable 5 — динамический анализ уязвимостей на основе передовых моделей. Процесс непрерывный и встроен в цикл разработки.

// continuous dynamic ai analysis

Непрерывный цикл выявления и митигации

Передовая модель работает с исходным кодом и поведением сервера в adversarial-режиме — как атакующий, исследующий поверхность атаки контура хранения. Цикл анализа:

  • Выявление (discovery). Динамическое исследование поверхности атаки: пути записи и удаления, аутентификация и авторизация, изоляция тенантов-агентов, состояния гонки.
  • Triage и классификация. Находки приоритизируются по уровню критичности и регистрируются с привязкой к коду и модели угроз.
  • Митигация. Устранение в коде либо компенсирующими контролями (сетевые ACL, hardening конфигурации); принятие риска — только с документированным обоснованием.
  • Регрессионная верификация. Повторный анализ подтверждает закрытие находок и отсутствие деградации защитных свойств.
  • Повторяемость. Цикл выполняется на каждом значимом изменении кодовой базы — анализ сопровождает развитие продукта, а не проводится разово.
security · continuous analysis
# динамический анализ уязвимостей
# на основе передовых моделей
модели: Claude Mythos 5 · Fable 5
режим:  adversarial — модель в роли атакующего

# непрерывный цикл
discover  → исследование поверхности атаки
triage    → классификация по критичности
mitigate  → фикс в коде / компенсирующий контроль
verify    → регрессионная перепроверка
repeat    → при каждом изменении кодовой базы
состояние сервера · иллюстрация
# машиночитаемое состояние — для ИИ и систем мониторинга
# пример упрощён; спецификация API — по запросу
{
  "status": "degraded",        # ok | degraded | alarm
  "agents": "12 ok / 1 degraded",
  "integrity": "без находок"
}

# Zabbix — HTTP-агент (JSONPath), Prometheus — json_exporter
# события целостности — в отдельном JSON-журнале
// observability

Мониторинг и контроль — для машин

Homyak спроектирован так, чтобы за ним наблюдали автоматизированные системы, а не оператор у экрана.

  • REST API состояния — здоровье, целостность, статусы агентов, индекс копий.
  • Структурные JSON-логи с отдельным каналом целостности и ротацией.
  • Heartbeat агентов с детекцией «отвалившихся» источников.
  • Zabbix и Prometheus — штатный HTTP-агент и json_exporter, без доработок кода.
  • ИИ-наблюдатели получают всё в машинном виде — без парсинга UI.
// extensibility

Готовность к доработкам под заказчика

Модульная архитектура (агенты ↔ общий протокол ↔ сервер хранения) позволяет добавлять новые типы агентов и бэкенды хранения под специализированные задачи.

Новые агенты

Файловые деревья, произвольный command-output и другие источники — добавляются как отдельные агенты поверх единого протокола, как уже сделано для KVM, MS SQL и PostgreSQL.

Бэкенды хранения

v1 — файловое хранилище; архитектура заложена под расширение на объектное хранилище (S3). Ленточный контур реализован модулем homyak-tape: выгрузка staging-слепка на стример LTO с дисковым каталогом кассет и учётом ресурса привода.

Интеграции и выгрузка

Слепок staging и машинный API — точки интеграции с внешними системами архивирования и офсайт-хранением.

// contact

Вопросы, комментарии, обращения по продукту

Напишите нам — обсудим внедрение, доработки под вашу инфраструктуру и интеграции мониторинга. Документация и обновления — на homyak.interforum.su.

✉ hello@inter-forum.org
Написать письмо →