Привет, Хабр! Я Михаил Косцов, руковожу практикой вычислительной инфраструктуры и систем резервного копирования в К2Тех. Сегодня сделаю обзор и поделюсь с вами результатами теста еще одного интересного российского решения. Это программная система хранения резервных копий BRO с мощной дедупликацией для быстрого бэкапа и восстановления из него. Мы давно знали о разработке этой платформы, и уговорили вендора предоставить нам возможность «погонять» ее на реальном железе еще до официального релиза. Под катом — проверка производительности в реальных условиях, анализ уже реализованных и перспективных фичей, история с устранением багов, а также разбор аспектов настройки новинки для работы с популярными средствами РК.
BRO (Backup Recovery OnTime) — это программная платформа для эффективного хранения бэкапов со встроенной дедупликацией и компрессией (которая на момент тестирования была в режиме экспериментального функционала). Фактически это аналог TATLIN.BACKUP и ExaGrid. В ее основе лежит защищенная ОС Astra Linux с сертификатами ФСТЭК, ФСБ России и Минобороны. Поверх нее установлены компоненты, которые и делают BRO интересным решением.
Вот основные фишки системы, которые отличают ее от конкурентов:
Дедупликация CDC: Дедупликация с использованием технологии Content Defined Chunking (CDC) задействует блоки переменной длины. Это позволяет обнаруживать дублированные блоки даже в данных, ранее прошедших стандартный процесс дедупликации. Технология использует алгоритм хэширования Gear, который может быстро вычислять текущие результаты хэширования и сохранять равномерное распределение результатов.
Доступ происходит как по стандартным протоколам CIFS/NFS, так и продвинутый вариант BR-Boost.
Веб-интерфейс на React JS.
Работа с кэшем: Вытеснение «холодных» данных на диск, что должно давать экономию ОЗУ и улучшать параметры дедупликации.
Пресеты для монтирования: Позволят настроить дедупликацию под конкретные типы данных или системы бэкапа.
В проекте — сжатие резервных копий по алгоритму ZSTD, которое задокументировано, но на момент нашего тестирования не работало через веб-интерфейс.
Что касается надёжности, в системе реализован ряд мер по обеспечению бесперебойной работы. Вот основные из них:
RAID60 – комбинация RAID6 и RAID0, обеспечивающая высокую отказоустойчивость (выдерживает одновременный выход из строя нескольких дисков) и хорошую производительность за счёт распределения нагрузки.
BBU Cache (Battery Backup Unit) – кэш-память с резервным питанием, которая сохраняет данные при внезапном отключении электроэнергии и обеспечивает их безопасную запись на диск после восстановления питания.
T10PI (Protection Information) – технология контроля целостности данных, добавляющая служебную информацию к каждому блоку, что помогает обнаруживать и предотвращать ошибки при передаче и записи данных.
ECC (Error-Correcting Code) – механизм автоматического обнаружения и исправления ошибок в памяти или на дисках, повышающий надёжность хранения и обработки.
На старт, внимание…тестируем!
Что же, мы решили проверить, насколько все это работает в реальности, и какие преимущества дает BRO. Для этого изучили рекомендуемые производителем характеристики и подобрали подходящие сервера.
Собрали в соответствии с ними тестовый стенд… а точнее, нашли завалявшийся в лабе 4-сокетный сервер с платиновыми процессорами.
Установка самого BRO приятно удивила.
Фактически мы просто развернули предложенный вендором образ Astra Linux, в котором уже содержались все необходимые компоненты.
QUOTE:
В продуктовой поставке ОС и система BRO будут предустановлены на сервер.
/QUOTE
Сразу после установки система перезагружается два раза и вы попадаете в оболочку BRO:
После настройки сети и монтирования дисков в разделы /storage и /nvme можно заходить в веб-интерфейс.
Уже работая с ним (поскольку доступа к ОС или оболочке BRO по SSH не предусмотрено производителем), мы и проводили тестирование.
Тестируем BRO
Чтобы проверить, как работает BRO в сетевом окружении, мы развернули небольшой тестовый стенд с СРК Vinchin и Кибер Бэкап. И прогнали на нем несколько тестовых задач резервного копирования.
Проверка работы в многопоточном режиме помогла нам найти один пред-релизный баг. В процессе тестирования обнаружили проблему с многопоточностью.
В сравнительном тестировании использовалось 4 задачи одновременно, однако, судя по мониторингу Vinchin, шли неравномерно – в основном 2-3 задачи выполняются, остальные ждут:
А уже через пару минут их было уже два:
Неравномерно выглядит и график выполнения задач:
Для проверки нагрузки была развернута ВМ с файлами внутри на 1 ТБ – это разные образы, системные файлы, логи и синтетика. ВМ находится на гипервизоре, в той же подсети, что и сервер BRO. По результатам мониторинга система показала следующую скорость:
Обо всем этом мы сообщили разработчику и довольно быстро получили обновление, решающее эту проблему. После установки версии ПО от 06.2025 плотность записи стабилизировалась, просадки пропали. Мониторинг показал следующую картину при запуске 4 задач по 8 потоков:
Самым приятным здесь была скорость реагирования вендора и успешное решение бага, которого в продуктиве уже не будет.
Резервное копирование с Vinchin
Чтобы оценить, насколько BRO способен улучшить эффективность дедупликации и компрессии, мы решили сравнить основных конкурентов BRO по критерию оптимизации резервных копий. В нашей таблице приведены данные для четырех СХД и одной классической СРК. Однако прошу обратить внимание, что все значения, кроме BRO, носят архивный характер и перенесены из предыдущих отчётов о тестировании, потому что обеспечить единые условия и связность 10 Гбит/с для реальных сравнительных тестов не представляется возможным. Как следствие, тут мы не оцениваем производительность.
Основной набор тестовых данных – это ВМ, суммарным объёмом 1 ТБ, основное ПО РК – Vinchin, так как в нем очень просто настроить многопоточность. Да и другие платформы мы тестировали на Vinchin, так что сравнивать логично результаты работы с этой СРК.
Чтобы изучить “чистые” результаты, мы отключили в Vinchin все оптимизации.
Причина такого поведения системы в том, что в отличие от других решений здесь работает только дедупликация, без компрессии.
Таким образом, можно сделать вывод, что для системы BRO средний прирост уникальных данных для тестового набора данных составляет - 2.3%, в то время как у ExaGrid - 0.6%, TATLIN.BACKUP - 0.2%.
Поэтому мы дополнительно проверили сжатие (экспериментальный функционал). Режим ZSTD хоть пока и скрыт, но его можно включить через конфигурационный файл конкретной точки монтирования. Сделав это, мы, с одной стороны, увидели, что режим сжатия действительно дает дополнительную оптимизацию, а с другой — разобрались, почему он пока скрыт от пользователей. В ходе тестирования возникли ошибки со стабильностью работы точек монтирования – вендор все еще дорабатывает функционал.
Из статистики ��ыше можно понять, что дедупликация BRO и TATLIN.BACKUP, в целом близки по своей эффективности (1:1.45 против 1:1.7 для первой копии), но следующим шагом идёт компрессия, которая в BRO пока не готова для полноценного использования. Если учитывать этот факт, результаты BRO вполне приличные.
Тест с Кибер Бэкап
В рамках данного теста сравнивается запись через КБ на BRO тремя методами
На стандартную CIFS точку монтирования
На точку монтирования со сжатием (параметр - common.zstd )
С дедупликацией самого Кибер Бэкап
Количество резервных копий – 5. В качестве данных взяты такие, которые сложно оптимизировать: различные образы, логи, синтетически сгенерированные данные и так далее. На выходе получается следующая картина:
В итоге даже на неоптимальном датасете и записи при помощи Кибер Бэкапа система всё равно может сжать некоторые данные. Это интересный результат.
Далее мы решили проверить, как различный уровень сжатия Кибер Бэкапа сказывается на утилизации места. Для этого мы использовали встроенную оптимизацию Кибер Бэкапа (Версия архива 12, .tibx файлы), взяв неоптимальные данные из предыдущего теста.
Как видно из таблицы, результаты работы BRO выглядят вполне неплохо на неоптимальных данных. Мы попробовали улучшить результат. Для этого те же самые данные записываем напрямую: создаём корневую директорию /mountbro и уже туда монтируем каталог mount -t nfs4 172.24.5.145:/storage/ca7b2f0f-1b70-485a-b457-b875b109a7a6/mnt /mountbro/mnt1/
Результат получается несколько лучше, точка монтирования со сжатием хоть и немного, но смогла уменьшить объём копии.
Далее мы провели аналогичные тесты на более привычном наборе данных — как на первом тесте в Vinchin:
Статистика оптимизации со стороны Кибер Бэкапа выглядит так:
То есть для продуктивного резервного копирования необходим баланс между сжатием Кибер Бэкапа и оптимизацией BRO. Наилучшим вариантом на момент тестирования является высокое сжатие Кибер Бэкапом и запись на обычную точку монтирования. Но не факт, что все будет именно так и на других данных.
Тест типов точек монтирования
В этом тесте проверяется, как тип точки монтирования влияет на производительность РК. При этом тестовый набор данных аналогичен тестам 2 и 3, используются те же самые пресеты (приложения) для проверяемых точек монтирования – рекомендуемый (Cyberprotect), Veeam, Generic Files и Big Static Files. Резервное копирование выполняется на точку монтирования CIFS/NFS со стандартными настройками. Результаты представлены в таблице ниже:
Можно сделать вывод, что размер блока, устанавливаемый в системе, всё же влияет на процесс резервного копирования. Рекомендуемые производителем параметры обеспечивают наилучший процесс РК.
Тест на восстановление
Для проверки эффективности возможностей восстановления мы запустили резервное копирование и восстановление 500 ГБ файловых данных из предыдущих тестов при помощи Кибер Бэкапа. И получили следующий результат – из-за механизмов оптимизации восстановление занимает дополнительное время:
Чтобы сохранить непредвзятость, мы проверили работу сети как в одну сторону:
Так и обратно — с BRO на север РК:
Как видите, скорость сети идентична, что исключает проблему при передаче данных.
Утилизация ресурсов сервера с BRO
Как бы мы ни старались, нам удалось загрузить максимум 9% процессора сервера и 200 Гбайт ОЗУ. То есть, несмотря на очень мощный сервер, взятый под тесты, загрузить его удалось всего на 9-10%, и в продуктиве перезакладываться на сайзинг не имеет смысла.
BOOST
Технология BR-BOOST в текущей ее реализации – это способ записи на систему, а не дополнительная оптимизация как в Dell DataDomain / HPE StoreOnce, где карта уникальных блоков хранится на клиенте, и за счёт этого на основную систему передаются только уникальные блоки. В BRO это реализовано как дополнительный запрос в основную систему, аналитика и уже последующая передача. Максимальный эффект текущей реализации протокола BOOST проявляется при передаче данных по медленной сети, т.к. повторно будут переданы только отличающиеся блоки и, вероятно, на больших объёмах одинаковых данных результаты будут намного более впечатляющими.
Выводы
Начнем с замечаний. Во-первых, протокол BOOST оказался по большей части ещё одним каналом передачи данных, хотя мы ожидали аналогичный прирост скорости РК как при использовании ddboost/t-boost. Во-вторых, зачастую аналитика Кибер Бэкапа показывает странные цифры и непонятную оптимизацию. В-третьих, есть вопросы к скорости восстановления. И, наконец, режим ZSTD в предоставленной на момент тестирования версии продукта не всегда работал стабильно.
При этом мы понимаем, что BRO — молодой продукт, но уже сейчас предлагает мощное решение для резервного копирования с отличной дедупликацией. Да, BRO требует доработок в производительности восстановления, интеграциях и управлении. Но если заявленная дорожная карта будет реализована, у системы есть все шансы стать универсальным и надёжным решением и занять свое место в ИТ-контуре компаний.
Кстати, пока мы писали этот текст, вендор успел серьезно расширить функциональность продукта, добавив ряд ключевых enterprise-функций:
Глубокая работа с протоколом BR-BOOST
Алгоритмы высокоскоростного протокола BR-BOOST были существенно доработаны. Теперь вся работа с таблицей хешей для дедупликации полностью происходит на стороне клиента. Это решение коренным образом меняет эффективность работы: по сети передаются только уникальные данные, что сокращает трафик в десятки раз и радикально ускоряет процесс создания и восстановления резервных копий.
Технология BRO Mirroring Writes для бескомпромиссной отказоустойчивости
Была анонсирована и реализована новая уникальная возможность — BRO Mirroring Writes. Эта технология позволяет клиенту с поддержкой BR-BOOST производить синхронную запись потока данных одновременно на два независимых устройства BRO. Это гарантирует высочайший уровень доступности и защиту данных, обеспечивая мгновенную доступность копии даже при полном отказе одного из массивов.
Помимо этого, вендор представил еще несколько важных нововведений:
Режим WORM (Write Once Read Many): Для критически важных данных теперь можно включать режим неизменяемого хранилища. После записи данные нельзя изменить или удалить в течение заданного срока, что обеспечивает защиту от ransomware-атак и соответствие регуляторным требованиям.
Журнал предзаписи (WAL): Для обеспечения максимальной консистентности данных при любых сценариях сбоя (например, отключении питания) в систему был добавлен механизм Write-Ahead Log. Это гарантирует, что незавершенные операции не повредят целостность данных.
Гибкая система управления доступом: Была полностью переработана система ролевого управления (RBAC), предоставив администраторам более тонкие и детальные настройки прав для пользователей и групп.
Существенный прирост производительности: Проведена низкоуровневая оптимизация, результатом которой стала заметно возросшая скорость как записи, так и чтения данных.
Официальный релиз версии с этими и другими обновлениями запланирован на 30 сентября.
Из явных плюсов:
оптимизация показала высокую эффективность (на выборочных данных коэффициент достигал 20X);
производитель создал удобный веб-интерфейс с интуитивно понятным управлением (настройка точки монтирования и её последующее добавление в СРК делается за пару шагов);
функциональность выбора типа данных позволяет манипулировать размером блока и улучшать процесс резервного копирования для конкретного приложения.
Мы продолжим следить за развитием продукта, и если вы захотите рассмотреть BRO и протестировать его на реальных задачах, мы готовы поделиться своим опытом и экспертизой. Вполне возможно, что в итоге получатся интересные результаты уже в текущей версии решения.