Привет, Хабр! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К2Тех. Сегодня хочу поделиться с вами результатами нашего первого знакомства с системой резервного копирования «Береста». Этот продукт отличается высокой скоростью работы, поддержкой многопоточности и иерархической схемой хранения. Производитель позиционирует «Бересту» как систему, способную решать сложные задачи в области резервного копирования и восстановления данных. Мы не могли пройти мимо и не протестировать такое решение. На что в действительности способна «Береста» — читайте под катом.

Архитектура решения

Платформа решения разрабатывается российскими инженерами с нуля. В качестве источников поддерживаются любые виртуальные машины, контейнеры, СУБД, NAS и физические хосты, а также популярные российские решения, перечень которых регулярно расширяется с учетом существующих потребностей по поддержке СУБД и приложений. Решение поддерживает такие хранилища, как FS, ZFS, S3, NFS, TBFS, TBOOST, TBOOSTAPI, DDBOOST, TAPE, POOL и HSM.

«Береста» использует 3 типа узлов, а также уровень устройств хранения резервных копий, чтобы обеспечить эффективное резервное копирование на корпоративном уровне. 

• мастер-сервер как центр управления;

• силовые серверы для обработки потоков резервного копирования;

• агенты «Береста» устанавливаются на источниках данных;

• устройства хранения — целевые хранилища резервных копий.

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

Среди ключевых особенностей решения можно выделить:

• Полную локализацию. Разработка ведётся с «нулевого цикла», что исключает зависимость от иностранных решений.

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

• Удобный интерфейс. В «Бересте» реализовано понятное и интуитивное управление для администраторов и бизнес-пользователей.

• Модуль аналитики и планирования. В решении уже есть встроенная аналитика для контроля SLA и прогнозирования потребностей.

Устанавливаем «Бересту»

Запросив продукт, мы получили от вендора три пакета для установки, которые могут быть развернуты на большинстве дистрибутивов российских ОС на базе Linux. Для теста выбрали Astra Linux 1.7 и накатили на ВМ мастер-сервер, силовой сервер и агенты РК.

В части требований к ресурсам, при проведении функционального тестирования для мастер-сервера «Бересты» рекомендуется следующая минимальная конфигурация: 16 ядер и 32 ГБ ОЗУ вместе с дисковым пространством 100 ГБ. 

Эти требования сопоставимы с показателями других СРК. Для сравнения: Кибер Бэкап — 6 ядер 16 ГБ ОЗУ для сервера управления + 4 ядра 16 ГБ ОЗУ для СУБД PostgreSQL (итого: 10 ядер 32 ГБ), RuBackup — 4 ядра 4 ГБ ОЗУ + 4 ядра 64 ГБ ОЗУ (итого: 8 ядер и 68 ГБ). 

Для тестов в лаборатории мы использовали формат «всё-в-одном» с характеристиками — 16 виртуальных ядер и 32 ГБ ОЗУ, а также несколько дополнительных силовых серверов. Единый сервер «Бересты» с клиентами в виде файлового и постгрес агентов дополнили отдельно вынесенными силовым сервером и файловым клиентом. Для хранения резервных копий мы выбрали локальный диск на силовых серверах и TATLIN.BACKUP с интеграцией по протоколу TBOOST.

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

Интерфейс

«Береста» управляется через веб-интерфейс. 

Центр управления отвечает за мониторинг и статистику. В нем доступны вкладки мониторинга состояния (ключевые метрики, обзор состояния системы, отчёты), а также мониторинг заданий со статусами политик РК. В разделе мониторинга сервисов содержится основная аналитика по метрикам, например RPO/RTO.

Раздел «Конфигурация» позволяет настраивать все основные параметры работы системы:

• регламент РК; 

• политики РК;

• устройства хранения РК;

• силовые серверы;

• источники данных (настройка РК по трём типам: агентские, безагентные и

• кластеризованные);

• уведомления; 

• классы критичности/ИТ-сервисы; 

• зоны доступности и т.д.

В журнале аудита доступны логи работы системы, а во вкладке «Восстановление» происходит запуск соответствующей процедуры. В «Каталоге Резервных Копий» виден список всех хранимых копий с фильтрами и указанными возможностями восстановления, клонирования и валидации.

Тестирование

Ну что же, давайте проверим, что может «Береста». На этапе создания политики нам предлагают широкий выбор возможностей: имя и тип, ограничения по скорости РК, что защищаем и куда копируем.

Затем необходимо сделать привязку к политике расписания. При создании расписания  выбираем:

• время ожидания и количество попыток копирования;

• тип РК — полный, инкремент и т.д.;

• время хранения (в днях) и периодичность запуска;

• окно резервного копирования.

Для тестирования работы СРК мы использовали гипервизор zVirt. Чтобы настроить интеграцию с ним,  необходимо перейти во вкладку «Источники данных» > «Безагентные» и запустить процедуру добавления нового источника. Список поддерживаемых источников большой, на скрине ниже представлена часть из них:

Чтобы продолжить работу в «Бересте», нужно запустить обнаружение ВМ. 

Если все работает корректно, на выходе мы получаем список всех доступных ресурсов в среде виртуализации. 

Перейдем непосредственно к тестам. Задания по созданию резервных копий виртуальных машин (РК ВМ) выполняются параллельно, без каких-либо проблем.

Проверка параллелизма в 4 одновременных сессиях связана с ограничением нагрузки на Hosted Engine нашего тестового стенда, так как слишком большое количество сессий может привести к недоступности управляющего механизма zVirt. Скорость резервного копирования идёт на уровне 350 МБ/c, что очень прилично!

После выполнения задания статистика резервного копирования будет доступна в разделе «Мониторинг заданий» — достаточно выбрать задание и раскрыть детали:

На этапе проверки функционала РК выявили интересную особенность: все изменения происходят не моментально, поэтому следует дождаться синхронизации с zVirt. Например, если добавить диски ВМ и сразу же запустить бэкап, то в бэкап попадёт предыдущая конфигурация ВМ — новые диски будут проигнорированы.

Чтобы выбрать диск, который необходимо включить или исключить в/из РК, нужно зайти во вкладку «Включения» в свойствах ВМ объектов.

Восстановление для всех типов данных идентично: необходимо перейти в Каталог РК,

выбрать необходимую копию и запустить процедуру восстановления, нажав на кнопку ВД. Выбираем стандартные опции: кластер, хранилище, имя виртуальной машины и т.д., но также можно выбрать и потоки (максимальное количество — 32).

В итоге скорость восстановления наших образов составила 786.4 МБ/с. Отличный результат!

Из нюансов этого процесса мы отметили:

• Восстановление возможно только в новую ВМ, варианта отката текущей ВМ не предусмотрено.

• Несмотря на создание новой ВМ, диски остаются с оригинальными названиями.

К сожалению, размеры нашего стенда не позволяют устроить полноценное нагрузочное тестирование многопоточности. Нам удалось базово проверить этот функционал на небольшой ВМ с 4 дисками: механизм работает штатно, все диски защищаются одновременно.

Для проверки работы РК в 1 поток пришлось в самой виртуальной машине как источнике выставить 1 поток (соответствующий параметр в политике относится к параллелизации объектов, добавленных в политику, а параллелизация на уровне объекта задается в объекте). 

Прирост в производительности от многопоточности, конечно, незначителен в инсталляции такого масштаба, но полученные цифры все равно стали показательными: задание в 1 поток прошло немного медленнее — 05:29 вместо 04:50 при работе в 4 потока.

Защита СУБД

Если работа с файловыми хранилищами, а также запуск разовых РК вручную реализованы в «Бересте» достаточно стандартно, то защита СУБД является сильной стороной продукта. Вендор действительно продумал и проработал многие нюансы и, чтобы проверить их на деле, мы создали выделенную ВМ с объемом диска 200 ГБ.

Помимо базовой инсталляции, также были созданы тестовые БД и синтетически (через

pgbench) сгенерированы данные. На момент тестирования это выглядело вот так:

Для настройки РК необходимо зайти в источник и перейти во вкладку с БД. В нашем случае (PG14 и PG15) БД определилась и подтянулась автоматически, никаких

настроек в конфигах делать не потребовалось. Политика РК аналогична другим нагрузкам — выбирается тип политики, потоки, объект защиты и место хранения.

Темпы резервного копирования утилизировали все свободные ресурсы, пиковая скорость перевалила за 1000 МБ/с, средняя составила 790 МБ/с.

Пулы хранения

«Береста» позволяет балансировать нагрузку в зависимости от различных параметров — количество заданий, скорость, свободное место и нагрузка:

Размеры тестовой инфраструктуры не позволили в полной мере проверить этот функционал, но в зависимости от параметров  jobs  или  used система выбирала разные хранилища. 

Интересные результаты показало небольшое тестирование технологии хранения HSM (Hierarchical Storage Management), которая автоматически распределяет данные между разными типами хранилищ. Можно считать ее прямым аналогом Storage Lifecycle Policy в NetBackup.

Для эксперимента мы выбрали локальное хранилище на 1 день и TBOOST на 3 дня. В результате сначала задание было записано на первичное хранилище, и потом перенесено на вторичное. Именно поэтому сразу после окончания РК хранилище отображает две копии.

Дополнительные возможности

Среди интересных возможностей решения мы отметили:

• мониторинг работы сервисов и системная аналитика прямо в веб-интерфейсе;

• сохранение резервных копии метаданных серверов и каталогов дедупликации для восстановления в сценариях Disaster Recovery;

• поддержка стандартной тенантной модели доступа;

• удобный и дружественный API, доступный прямо из веб-интерфейса;

• мощные инструменты для анализа логов — как протоколов РК, так и системных логов;

• поддержка трех типов кластеризации — Keepalived, Kubernetes и Pacemaker;

• поддержка ленточных накопителей в качестве второго хранилища;

• прозрачная схема лицензирования по объему защищаемой информации;

• и особенно стоит отметить наличие функций управления сторонним ПО и возможность сбора аналитики с него (например, из параллельно работающих систем NetBackUp).

Выводы

По результатам тестирования «Береста» произвела впечатление современного решения, которое уверенно займет свое место на рынке СРК. Безусловно, есть и зоны роста, которые следует учитывать и вендору в дорожной карте развития решения, и заказчикам, планирующим внедрение. Если резюмировать, в качестве сильных сторон системы нельзя не отметить: 

1. Высокую производительность и современную архитектуру. Система демонстрирует выдающуюся скорость обработки данных (900+ МБ/с на стенде — то есть фактически «Бреста» смогла утилизировать всю имеющуюся пропускную способность сети), поддерживает реальную многопоточность и уникальные разработки, такие как проприетарный TBOOSTAPI, не имеющий аналогов у других производителей).

2. Надёжность и отказоустойчивость. Поддержка различных вариантов кластеризации (Kubernetes, Pacemaker, Keepalived) позволяет строить высокодоступные конфигурации. Система может выполнять балансировку хранилищ (пулы) и обеспечивает полноценное иерархическое хранение (HSM).

3. Удобство использования. Процесс установки у «Бересты» действительно простой, а современный и интуитивно понятный веб-интерфейс является приятным дополнением. Отдельно стоит отметить наличие полнофункционального REST API, который открывает широкие возможности для автоматизации процессов РК и ВД. Процесс обновления из веб-консоли в несколько кликов позволяет обновить основной и резервные узлы, силовые сервера и агенты.

Подводные камни, о которых следует знать:

• В настоящее время продукт находится на активной стадии развития, что может приводить к нестабильности отдельных функций в очередных билдах (например, в тестовом билде был исправлен TBOOST, но перестал работать модуль Postgres). Плюс в том, что производитель оперативно реагирует на любые запросы.

• В системе есть критически важные элементы, такие как защита компонентов СРК, защита пула дедупликации, и это большой плюс. Для защиты файловых систем в решение добавлены «динамические» политики: это означает, что система автоматически создает ФС объекты, если они существуют на агентах.

• Функциональность управления сторонними СРК ограничивается пока работой с NetBackup и носит базовый характер, что может не покрывать всех потребностей в консолидации управления разнородными системами. 

• На рынке представлено мало референсов использования «Бересты».

• Ограниченный перечень поддерживаемых ресурсов — источников для бэкапа (некоторые СУБД пока не поддерживаются, однако вендор активно расширяет перечень совместимостей: поддержка VMware должна появиться в январе 2026 года, уже подтверждена совместимость с VK Cloud Object Storage (S3), вслед за этим ждем поддержку VK Private Cloud (OpenStack).

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

Итак, сегодня мы заносим «Бересту» в список решений, которые можно использовать для ряда корпоративных задач. Напомню, что недавно я рассказал об итогах тестирования программной платформы для хранения бэкапов BRO (Backup Recovery OnTime). Тем временем мы уже готовим детальный обзор еще одного отечественного решения – обязательно поделюсь результатами в блоге.