RuBackup — российская бэкап система для ИТ-инфраструктуры любого масштаба и бизнес-приложений

15.11.2026

Резервное копирование — одна из немногих ИТ-дисциплин, где качество продукта нельзя оценить по интерфейсу или перечню функций в брошюре. Всё решает архитектура: как система ведёт очередь задач, как обрабатывает потоки данных, как ведёт себя при отказе узла и сколько ресурсов отнимает у защищаемых серверов. Российская бэкап система RuBackup, развиваемая «Группой Астрой», в последние годы превратилась из нишевого решения в одну из центральных платформ контура импортозамещения, и потому заслуживает не рекламного, а технического разбора. Ниже — анализ того, что именно определяет её функциональность и какие инженерные решения за ней стоят.

Архитектура: сервер, резервный сервер, медиасерверы, клиенты

RuBackup построен по клиент-серверной модели, но с продуманной факторизацией ролей. Серверная группировка включает основной сервер, опциональный резервный сервер и произвольное число медиасерверов. Основной сервер — это управляющее ядро: он координирует задания, ведёт конфигурационную базу данных (на PostgreSQL) и хранит метаданные о том, что, куда и когда сохранено. Медиасерверы — узлы, к которым подключены устройства хранения: дисковые пулы, ленточные библиотеки, S3-облака. Именно они принимают поток данных от клиентов.

Такое разделение принципиально. Управляющий трафик и поток копий разнесены по разным компонентам, поэтому производительность резервной инфраструктуры наращивается не заменой сервера на более мощный, а добавлением медиасерверов — горизонтально. Для распределённых ЦОД это означает, что копии можно формировать локально на каждой площадке, не перегоняя терабайты через межсайтовые каналы, а конфигурация остаётся единой.

В минимальной конфигурации всё устанавливается на один узел по схеме «всё в одном»: сервер сам выполняет роль медиасервера. На другом полюсе — построение HA-контура: при недоступности основного сервера запросы автоматически обрабатывает резервный, а при отказе медиасервера задачи перенаправляются на другой узел и другое хранилище. Отказоустойчивость здесь встроена в архитектуру, а не реализована внешними средствами кластеризации.

Клиент — модульное приложение на защищаемом хосте (Linux, Windows, macOS). Модуль отвечает за конкретный тип ресурса: файловую систему, блочное устройство, СУБД или платформу виртуализации. API модулей открыт, то есть сторонний разработчик или интеграционная команда заказчика может написать модуль под нестандартную систему, не дожидаясь релиза вендора.

Охват источников данных

Спектр поддерживаемых источников у RuBackup шире, чем у многих коммерческих аналогов на российском рынке:

• файловые системы (включая BTRFS и ZFS), логические тома LVM, блочные устройства;
• виртуальные среды — безагентно и через API: KVM, Proxmox, OpenNebula, oVirt и построенные на нём zVirt, РЕД Виртуализация, HOSTVM, ПК СВ «Брест», Р-Виртуализация, Aerodisk AIST, RuStack, OpenStack, VMmanager, «РУСТЭК», VMware vSphere;
• СУБД: PostgreSQL (включая непрерывное копирование WAL и PITR), Postgres Pro, Patroni, Tantor, Greenplum/Arenadata, MS SQL for Linux, SQLite, Tarantool;
• служебные сервисы: FreeIPA, CommuniGate Pro, бакеты S3.

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

Второй — глубина интеграции с PostgreSQL. Помимо периодических полных копий, система ведёт непрерывное резервное копирование архивных файлов WAL по мере их появления, поддерживает восстановление на точку во времени (Point-in-Time Recovery) и восстановление отдельных таблиц и баз. Для транзакционных систем это критично: потеря не целого сервера, а последних минут транзакций — типовой сценарий, который классическое вечернее копирование не закрывает.

Дедупликация и производительность

Технологическая визитная карточка RuBackup — поточная глобальная дедупликация на уровне блоков. В дедуплицированное хранилище передаются только те блоки, которых там ещё нет, причём алгоритм применяется не постфактум, а в потоке копирования. Система поддерживает несколько хэш-алгоритмов — SHA1, SHA2, Blake2b, Streebog (ГОСТ) — и допускает несколько пулов дедупликации с разными размерами блока. Для ускорения поиска совпадений используется фильтр Блума, которому документация прямо рекомендует NVMe-накопители под конфигурационную базу.

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

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

Хранение, репликация и жизненный цикл копий

Управление хранением реализовано как полноценный конвейер. Копии распределяются по пулам согласно политике: дисковые СХД для оперативного восстановления, ленточные библиотеки (с работой через LTFS) для долговременного архивного хранения, объектные S3-хранилища для географически распределённых сценариев. Автоматическое перемещение копий между уровнями и удаление устаревших по истечении срока — штатные функции, а не скрипты поверх системы.

Дополнительно доступны:

• непрерывная удалённая репликация с отставанием реплики от источника порядка одной минуты и возможностью хранения любого числа реплик — сценарий аварийного восстановления целой площадки, где RTO сводится к минутам;
• репликация копий в дополнительные пулы как отдельное правило глобального расписания;
• сценарии автоматического восстановления и bare-metal recovery для Linux-систем;
• контроль наличия требуемого числа копий критичных данных.

Отдельно стоит отметить защиту копий от подмены и повреждения: электронная подпись по схеме открытого/закрытого ключа, автоматическая верификация по размеру и контрольным суммам, а также возможность восстановления повреждённых блоков инкрементальных копий из неизменённых частей. Криптостойкость копий обеспечивается четырнадцатью алгоритмами, включая ГОСТ 34.12-2015 («Кузнечик», «Магма») и международных — AES, Twofish, Serpent и другие. Для организаций, работающих в контуре требований ФСТЭК и кибербезопасности, это не опция, а необходимое условие; система имеет сертификат соответствия ФСТЭК России по четвёртому уровню доверия.

Управление, разграничение доступа и эксплуатация

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

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

Примечателен и автономный режим клиента: отдельный хост может копироваться на локальное устройство или сетевую файловую систему без включения в общую СРК. Это закрывает периферийные сценарии — филиалы, киоски, изолированные сегменты, — где разворачивать полноценный сервер нерационально.

Аппаратная и программная совместимость

RuBackup работает на x86_64, а также на отечественных аппаратных платформах «Байкал» и «Эльбрус»; поддерживаются Astra Linux, ALT и RED OS. Развитие в связке с экосистемой «Группы Астры» даёт предсказуемую совместимость с Astra Linux, включая копирование файлов с мандатными атрибутами и защиту доменных сервисов FreeIPA — деталей, которые для регуляторно чувствительных заказчиков значат больше, чем любые удобства интерфейса.

Что остаётся за кадром прайс-листа

Если свести анализ к ключевым инженерным решениям, картина такая: факторизация ролей сервер/медиасервер обеспечивает честную горизонтальную масштабируемость до десятков петабайт; поточная глобальная дедупликация превращает экономию хранения из маркетинговой цифры в измеримую характеристику; непрерывная репликация и WAL-копирование СУБД переводят RTO из часов в минуты; открытый API модулей снимает главный страх замены зарубежных СРК — невозможность быстро адаптироваться к нестандартному стеку.

Всё это не отменяет необходимость стандартной дисциплины внедрения: продумать политику хранения, нагрузочное тестирование на реальных объёмах, схему репликации между площадками. Но структурно RuBackup закрывает именно тот класс задач, который при импортозамещении считался самым трудным, — и делает это не декларативно, а на уровне архитектуры.