Российский рынок резервного копирования прошёл стадию, когда отечественные продукты выбирали преимущественно ради импортозамещения. К октябрю 2026 года несколько российских СРК способны защищать крупные корпоративные инфраструктуры, работать с различными гипервизорами, СУБД и системами хранения, а также обеспечивать восстановление после технических сбоев и кибератак. Но между наличием функции в документации и её надёжной работой в промышленной среде по-прежнему сохраняется существенная разница.
Для крупной смешанной инфраструктуры я ставлю на первое место «Кибер Бэкап». RuBackup практически сравнялся с лидером и выглядит особенно сильным кандидатом для организаций, переходящих на российские операционные системы, виртуализацию и базы данных. «Береста» занимает третью позицию, хотя по отдельным архитектурным решениям и работе с данными способна конкурировать с обоими лидерами. Отдельно развивается рынок специализированных платформ Disaster Recovery, систем хранения резервных копий и средств защиты облачных сервисов. Смешивать разные классы в один рейтинг было бы ошибкой.
Все оценки, выводы и прогнозы выражают моё личное мнение на основе проверяемых характеристик продуктов и собственных объективных и субъективных оценок. Рейтинг относится к выбранному сценарию на дату публикации и не заменяет пилот. Если отдельно не указано иное, я не проводил собственных лабораторных испытаний перечисленных продуктов.
Что я сравниваю и как выбирал участников
Под корпоративной системой резервного копирования и восстановления данных я понимаю централизованную программную платформу, которая защищает физические серверы, виртуальные машины, базы данных, файловые ресурсы и приложения. СРК должна управлять расписаниями, политиками хранения, репозиториями и точками восстановления, контролировать выполнение заданий и предоставлять инструменты полного и выборочного восстановления.
Для современного корпоративного продукта необходимы полное и инкрементальное копирование, прикладная согласованность данных, поддержка нескольких типов хранилищ, шифрование, разграничение полномочий, аудит, мониторинг и API. При работе с критичными системами добавляются требования к отказоустойчивости управляющего контура, репликации, изоляции резервных копий, восстановлению после компрометации инфраструктуры и проверке целостности.
Отдельную роль играет киберустойчивость. Схема 3-2-1 остаётся полезным ориентиром, но я предпочитаю расширенный вариант 3-2-1-1-0, который предполагает наличие изолированной или неизменяемой копии и проверку восстановления без выявленных ошибок. Реализовать такую архитектуру можно не только средствами СРК, но и за счёт отдельного хранилища, WORM, S3 Object Lock или физически отключаемых носителей.
Я разделяю универсальные СРК, специализированные средства аварийного восстановления, платформенные модули, продукты защиты отдельных приложений, системы хранения резервных копий и облачные BaaS-сервисы. Решения из разных групп могут работать совместно, но решают неодинаковые задачи. Высокая скорость репликации виртуальных машин не заменяет длительного хранения транзакционных резервных копий базы данных, а хорошая дедуплицирующая СХД не управляет прикладной согласованностью.
Типовой корпоративный сценарий
Для рейтинга я выбрал организацию с несколькими сотнями или тысячами защищаемых нагрузок, двумя ЦОД и филиалами. В инфраструктуре одновременно присутствуют Windows и Linux, VMware или Hyper-V, российские платформы виртуализации, PostgreSQL, Postgres Pro, файловые серверы, корпоративные приложения и объектные хранилища. Возможны ленточные библиотеки и Kubernetes.
Для наиболее критичных систем предполагаются целевые RPO от одного до четырёх часов и RTO от двух до восьми часов. RPO определяет допустимую потерю данных по времени, RTO задаёт срок восстановления работоспособности. Реальные показатели должны определяться бизнес-требованиями, а не возможностями продукта, указанными в рекламных материалах.
Российское происхождение я рассматриваю отдельно от присутствия в реестре ПО. Для включения в рейтинг необходимо подтверждение самостоятельной разработки и сопровождения российским правообладателем. Использование open source не исключает продукт из рассмотрения, но требует оценки собственного вклада разработчика и степени контроля над технологией. Простой ребрендинг или перепродажа иностранного ПО недостаточны.
Методика оценки
Каждый основной продукт оценивается по семи критериям. Итоговый балл рассчитывается как взвешенная сумма оценок по десятибалльной шкале.
| Критерий | Вес | Что оценивается |
|---|---|---|
| Функциональность и восстановление | 25% | Охват нагрузок, прикладная согласованность, гранулярность, способы восстановления |
| Архитектура и масштабируемость | 20% | Распределение компонентов, потоки данных, отказоустойчивость, работа с большими объёмами |
| Киберустойчивость | 15% | Защита репозиториев, шифрование, изоляция, аудит, разделение полномочий |
| Российские интеграции | 15% | ОС, гипервизоры, СУБД, почтовые платформы, системы хранения |
| Эксплуатация и автоматизация | 10% | Управление, обновления, диагностика, API, мониторинг |
| Зрелость и внедрения | 10% | История развития, промышленные внедрения, специалисты и доступный опыт |
| Лицензирование и регуляторная применимость | 5% | Предсказуемость лицензирования, условия сопровождения, сертификаты и ограничения |
Оценки носят экспертный характер. Я не превращаю заявленные производителем показатели скорости в сравнительные результаты без одинаковых условий испытаний. Разница в несколько десятых балла между двумя продуктами не означает измеримого превосходства одного над другим.
При изучении рынка я учитывал техническую документацию, историю релизов, реестровые сведения, опубликованные внедрения, материалы об эксплуатации и совместимости. Наиболее убедительными считаю сведения, которые подтверждаются независимо от производителя. Там, где доступны только заявления разработчика, уверенность в выводах ниже.
Российский рынок резервного копирования в 2026 году
Главное изменение последних лет заключается в переходе от формального импортозамещения к конкуренции продуктов. Раньше заказчик часто выбирал отечественную СРК из ограниченного списка, ориентируясь на совместимость и наличие обязательных документов. Теперь приходится сравнивать архитектуру, глубину интеграции, восстановление после аварии, надёжность обновлений и эксплуатационные затраты.
Спрос поддерживают сразу несколько процессов. Организации заменяют иностранные продукты, переводят серверы на российские ОС, внедряют отечественную виртуализацию и PostgreSQL-совместимые СУБД, модернизируют хранилища и пересматривают защиту после атак программ-вымогателей. При этом замена СРК часто оказывается сложнее миграции прикладного ПО.
Причина связана с историческими резервными копиями. В архивах могут храниться данные за несколько лет, созданные в проприетарных форматах прежних систем. Новая СРК обычно не умеет непосредственно восстанавливать такие архивы. Поэтому старый продукт приходится сохранять до окончания срока хранения либо организовывать отдельный перенос данных с проверкой восстановимости.
Вторая проблема связана с неоднородностью российской инфраструктуры. Вместо единой доминирующей платформы виртуализации компании используют различные реализации KVM, oVirt, OpenStack, Proxmox и самостоятельные российские разработки. Каждая платформа имеет особенности снимков, отслеживания изменённых блоков, хранения метаданных и управления виртуальными машинами.
В результате поддержка отечественного гипервизора превратилась в самостоятельное конкурентное преимущество. Но заказчику недостаточно увидеть название платформы в матрице совместимости. Нужно проверить работу с конкретной версией, резервное копирование без агента, инкрементальные копии, перенос на другой кластер и восстановление после полной потери гипервизора.
Третья проблема связана с ростом PostgreSQL. Базы данных требуют согласованного резервирования, сохранения WAL, восстановления на определённый момент времени и контроля целостности. Снимок виртуальной машины может обеспечить crash-consistent копию, но не заменяет специализированные механизмы защиты транзакционной базы.
Четвёртое направление связано с ransomware. Злоумышленники всё чаще атакуют не только продуктивные данные, но и управляющие серверы, сервисные учётные записи и репозитории резервных копий. Система, которая успешно создаёт копии, но позволяет одному скомпрометированному администратору удалить весь архив, оставляет организации серьёзный риск.
Поэтому рынок постепенно разделяется на программные СРК и специализированные хранилища. Программный продукт отвечает за источники, политики, согласованность и восстановление. Хранилище обеспечивает ёмкость, дедупликацию, изоляцию, репликацию и дополнительную защиту копий. В крупной инфраструктуре качество связки становится важнее отдельных рекламных характеристик каждого компонента.
Отдельная тенденция связана с SaaS. Компании всё чаще переносят почту, файлы и коммуникации в облачные сервисы, но не всегда получают независимую резервную копию с необходимым сроком хранения. Наличие нескольких реплик внутри облачной платформы не равнозначно защите от ошибочного удаления, компрометации администратора или прекращения доступа к сервису.
Достоверную общую денежную оценку российского рынка СРК за 2026 год я не привожу. Публичные исследования используют разные границы, иногда объединяя программное обеспечение, СХД, облачные услуги и интеграционные проекты. Выручка отдельного разработчика и количество его заказчиков также не позволяют автоматически рассчитать долю в конкретном сегменте.
Рейтинг универсальных российских СРК
В выбранном корпоративном сценарии наиболее сильными участниками считаю «Кибер Бэкап», RuBackup и «Бересту». Другие самостоятельные российские разработки существуют, но доступных независимых данных пока недостаточно для сопоставимой оценки по всем критериям.
| Продукт | Итог | Лучший сценарий | Преимущество | Ограничение | Потенциал | Уверенность |
|---|---|---|---|---|---|---|
| Кибер Бэкап | 9,2 | Крупная смешанная инфраструктура | Широта функций, зрелость, разнообразие поддерживаемых платформ | Неодинаковая глубина интеграций, вопросы актуального сертифицированного исполнения | Высокий | Высокая |
| RuBackup | 9,0 | Российский инфраструктурный стек, крупные ЦОД | Развитые российские интеграции, модульная архитектура | Неоднородная зрелость новых компонентов и функций | Высокий | Выше средней |
| Береста | 8,3 | Нагруженные инфраструктуры, СУБД, современные хранилища | Многопоточная архитектура, гибкая работа с потоками и репозиториями | Меньше независимых эксплуатационных данных и накопленного опыта | Высокий | Средняя |
1. Кибер Бэкап
«Кибер Бэкап» остаётся наиболее универсальным выбором для крупной компании со смешанной инфраструктурой. В его пользу работают широкий охват платформ, развитые средства управления, накопленная история эксплуатации и наличие специалистов. Актуальная версия 18.6 вышла 2 июля 2026 года. Документация включает руководства по установке, управлению, кластеризации, API и ленточным устройствам.
Продукт построен по трёхкомпонентной архитектуре. Сервер управления отвечает за политики, расписания, состояние задач и централизованную консоль. Агенты взаимодействуют с защищаемыми ресурсами, а узлы хранения обслуживают резервные копии и операции с репозиториями. Поддерживаются распределённые конфигурации и отказоустойчивое развёртывание управляющего контура. Для большой компании такая структура позволяет отделить управление от передачи и хранения данных.
Функциональный охват остаётся главным преимуществом. Система защищает физические Windows- и Linux-серверы, виртуальные машины, файловые ресурсы, СУБД и контейнеризированные среды. В матрице совместимости представлены VMware, Hyper-V, платформы на базе oVirt, OpenStack, Proxmox и ряд российских решений. Поддерживаются прикладные сценарии резервирования PostgreSQL, Oracle и других корпоративных систем, но доступность конкретной функции зависит от версии продукта и защищаемой платформы.
Глубина интеграций неодинакова. Безагентское копирование, отслеживание изменённых блоков, гранулярное восстановление и прикладная согласованность могут реализовываться разными механизмами. Например, защита виртуальной машины на одном гипервизоре не гарантирует идентичного набора возможностей на другом. Для проектов с большим количеством российских платформ я бы требовал подробную матрицу поддерживаемых операций, а не ограничивался общим перечнем совместимости.
Отдельного внимания заслуживает Kubernetes. В документации версии 18.6 описано резервное копирование постоянных томов с использованием снимков и временных компонентов внутри кластера. Подход позволяет работать с данными контейнерных приложений, но предъявляет требования к CSI, снимкам томов и доступности служебных ресурсов. Прикладную согласованность распределённого приложения всё равно необходимо проверять отдельно. Копия PersistentVolume не гарантирует корректного состояния всех сервисов приложения.
Для корпоративной эксплуатации предусмотрены централизованные планы защиты, распределение ролей, мониторинг, различные варианты хранения, дедупликация и работа с ленточными библиотеками. Часть возможностей зависит от редакции и лицензии. Поэтому при выборе необходимо оценивать не только количество источников, но и требуемые функции узла хранения, режимы отказоустойчивости и сопровождение в течение нескольких лет.
По зрелости «Кибер Бэкап» имеет преимущество перед молодыми конкурентами, но большое количество поддерживаемых сценариев увеличивает сложность обновлений. В заметках к версии 18.6 перечислены исправления ошибок установки агентов на РЕД ОС с FIPS, подключения через прокси и гранулярного восстановления. Нельзя автоматически считать каждую исправленную ошибку массовой проблемой. Однако опубликованные исправления показывают, насколько разными бывают реальные эксплуатационные условия.
Есть и более показательный нюанс. В рекомендациях технической поддержки по переходу на версию 18 для отдельных старых веток предусмотрено поэтапное обновление, а для перехода между мажорными версиями требуется учитывать обновление лицензионных ключей. При планировании миграции нельзя рассчитывать, что любая установленная версия обновится непосредственно до последней без дополнительных действий.
Киберустойчивость необходимо проверять вместе с выбранным хранилищем. Защита паролями, шифрование и разграничение прав важны, но не заменяют неизменяемую или изолированную копию. Я бы проверял устойчивость всей конфигурации к удалению репозитория через управляющую консоль, компрометации сервисной учётной записи и потере каталога резервных копий.
Регуляторный статус требует отдельного внимания. У продукта существует сертифицированная линия, однако опубликованная разработчиком таблица указывает срок действия сертификата ФСТЭК № 4337 до 11 декабря 2025 года. Для ветки 18 сообщалось о процедуре продления. Поэтому я не считаю актуальную 18.6 автоматически подтверждённым сертифицированным исполнением. В регулируемом проекте нужно получить документальное подтверждение конкретной версии и её допустимости.
Мой вывод. «Кибер Бэкап» остаётся первым кандидатом для крупной смешанной инфраструктуры. Основное преимущество заключается в сочетании функциональной широты, зрелости и возможностей восстановления, а не в одной уникальной технологии.
Прогноз. Потенциал высокий. Я ожидаю сохранения продукта среди лидеров до 2028–2029 годов. Рост будут поддерживать широкая установленная база, российские интеграции и развитие инфраструктурной экосистемы. Главный риск связан с усложнением кода и сопровождения большого количества платформ. Позицию в рейтинге я пересмотрю, если конкуренты обеспечат более предсказуемое восстановление и существенно упростят эксплуатацию крупных инсталляций.
2. RuBackup
RuBackup превратился в полноценного конкурента «Кибер Бэкапа», особенно в инфраструктурах с высокой долей российского ПО. В августе 2026 года разработчик выпустил версию 3.0. Главные изменения затронули архитектуру передачи данных, поддержку платформ виртуализации, работу с СУБД и почтовыми системами, хранение резервных копий и гранулярное восстановление.
RuBackup построен как модульная распределённая система. В архитектуре используются основной и резервный серверы, медиасерверы, клиентские компоненты и отдельные модули для различных типов нагрузки. Служебная база данных работает на PostgreSQL. Такой подход позволяет распределять ресурсы и потоки резервного копирования между компонентами, но предъявляет более высокие требования к проектированию и сопровождению.
Сильнейшая сторона RuBackup связана с российской экосистемой. В документации представлены Astra Linux, другие отечественные Linux-дистрибутивы, российские гипервизоры, PostgreSQL, Postgres Pro, Tantor, Jatoba, RuPost и другие прикладные системы. Поддерживаются платформы на базе oVirt, Proxmox, OpenStack, KVM и самостоятельные российские решения. Для организаций, которые одновременно меняют ОС, виртуализацию и СУБД, такая интеграция может оказаться важнее формальной широты продуктового каталога.
В версии 3.0 разработчик переработал передачу данных для ряда сценариев. Резервное копирование виртуальных машин, СУБД и почтовых систем теперь может выполняться без промежуточного хранилища. Отказ от дополнительной стадии передачи потенциально сокращает I/O и требования к свободной ёмкости. Но выигрыш зависит от типа источника, сетевой архитектуры и репозитория. Реальные показатели необходимо измерять на собственном стенде.
Серьёзно изменился и слой хранения. Появились новые поколения файловых и облачных пулов, поддержка размещения копий в отдельных S3-бакетах и возможность записи сразу в два независимых файловых пула. Улучшены механизмы работы с ленточными библиотеками. Для крупных ЦОД подобные изменения могут уменьшить зависимость от одного репозитория и упростить построение нескольких контуров хранения.
Особенно интересна возможность восстановления резервных копий zVirt на VMmanager. Для российского рынка такой сценарий важнее, чем может показаться. Организации нередко используют несколько платформ виртуализации и хотят сохранять свободу последующей миграции. Но наличие одного поддерживаемого маршрута восстановления не означает универсальной конвертации между всеми гипервизорами. Перед внедрением необходимо проверить сетевые настройки, драйверы, дисковые контроллеры и корректность загрузки приложения.
Новая версия усилила гранулярное восстановление и расширила интеграции с российскими приложениями. Показательный пример появился 8 октября 2026 года, когда разработчик представил RuBackup Catalog Granular Recovery для ALD Pro. Решение предназначено для точечного восстановления объектов LDAP-каталога и их атрибутов без остановки службы. Такой сценарий действительно полезен. Ошибочное удаление группы, пользователя или изменение атрибута каталога не всегда должно приводить к восстановлению целого контроллера домена.
Но быстрое развитие имеет обратную сторону. В документации RuBackup 3.0 часть новых возможностей отчётности и отдельных сценариев отмечена как экспериментальная. Некоторые модули развиваются независимо, а поддержка старых версий платформ постепенно прекращается. В крупной инсталляции приходится тщательно сопоставлять версии серверных компонентов, агентов, СУБД и интеграционных модулей.
По публичным материалам RuBackup уже используется в достаточно крупных инфраструктурах, включая проекты с тысячами защищаемых ресурсов. Подобные внедрения подтверждают промышленное применение продукта, но не дают возможности сравнить его производительность с конкурентами. Для корректного вывода нужны одинаковые нагрузки, объёмы, сроки хранения, репозитории и сетевые условия.
Лицензирование отличается гибкостью. Доступны модели Frontend, Backend и Configuration. Frontend учитывает объём исходных данных по установленным правилам, Backend ориентирован на объём хранимых резервных копий, а Configuration использует параметры инфраструктуры с собственными ограничениями. При исчерпании объёмной лицензии в некоторых моделях новые резервные копии создать нельзя, хотя восстановление остаётся доступным. Для бизнеса такая особенность означает необходимость постоянного контроля лицензируемой ёмкости.
RuBackup имеет сертификат ФСТЭК № 4879 по четвёртому уровню доверия. Опубликованный срок действия сертификата заканчивается 25 ноября 2029 года. При этом сертификат относится к установленному исполнению, а не автоматически ко всем последующим версиям. В проектах с обязательной сертификацией необходимо сверять формуляр и точный состав поставки.
Мой вывод. Для инфраструктуры, построенной преимущественно на российских ОС, виртуализации, СУБД и почтовых системах, RuBackup способен оказаться лучшим выбором. В смешанном сценарии продукт уступает «Кибер Бэкапу» минимально, а при изменении весов рейтинга может выйти на первое место.
Прогноз. Потенциал высокий. Я ожидаю дальнейшего сближения с лидером и усиления позиций в крупных регулируемых инфраструктурах. Основной фактор роста связан с глубиной российских интеграций и развитием экосистемы. Главный риск заключается в неоднородной зрелости быстро добавляемых модулей. Если ветка 3.x стабилизирует новые функции, RuBackup сможет претендовать на лидерство в универсальном enterprise-сегменте.
3. Береста
«Береста» представляет самостоятельную российскую разработку корпоративной СРК. Продукт создавался с ориентацией на современные российские инфраструктуры и большие объёмы данных. По сравнению с двумя лидерами у него меньше накопленной истории публичных внедрений, но архитектурные решения и документированный функциональный охват заслуживают внимания.
Архитектура разделена на Master Server, Power Server и агентов. Master Server управляет конфигурацией, политиками и заданиями. Power Server принимает на себя передачу и обработку потоков резервного копирования. Агенты работают с источниками данных. Такая схема позволяет масштабировать транспортный контур отдельно от управляющего и распределять потоки между несколькими серверами.
Для взаимодействия компонентов используются защищённые соединения и внутренние механизмы обмена сообщениями. Документация раскрывает требования к сетевой связности, ролям серверов и типовым конфигурациям. При развёртывании в крупном ЦОД потребуется заранее рассчитать ресурсы Master Server, Power Server, дисковых пулов и сети. Ошибочное проектирование способно ограничить производительность даже при достаточной мощности отдельных узлов.
«Береста» поддерживает файловое резервирование, PostgreSQL-совместимые СУБД, Oracle, MySQL и различные корпоративные приложения. В документации описаны сценарии для CommuniGate Pro, RuPost и ALD Pro. Также представлены интеграции с российскими платформами виртуализации, включая решения на базе oVirt и Basis Dynamix.
Прикладная поддержка имеет разную глубину. Например, резервирование CommuniGate Pro использует потоковое файловое копирование и может требовать специальных сценариев предварительной подготовки приложения. Для ALD Pro предусмотрен сценарий с выгрузкой данных штатными средствами и последующим резервированием подготовленных файлов. Такая интеграция может успешно решать задачу восстановления, но отличается от полностью нативного прикладного агента. При выборе необходимо понимать, какой механизм обеспечивает согласованность данных.
Для PostgreSQL доступны специализированные сценарии, включая работу с журналами транзакций. Многопоточная передача позволяет эффективнее использовать ресурсы при копировании больших объёмов. Разработчик также заявляет возможность создания полной копии с затратами времени, сопоставимыми с инкрементальной операцией. Подобные характеристики зависят от архитектуры хранения и конкретного режима. Я не распространял бы такое обещание на все типы данных без испытаний.
Система поддерживает разные типы репозиториев, включая файловые, блочные и объектные хранилища. Предусмотрены дедупликация, REST API, централизованные политики, мониторинг и интеграция с Zabbix. В документации опубликованы руководства по аварийному восстановлению самой СРК. Наличие таких материалов полезно, поскольку отказ Master Server не должен превращать сохранённые резервные копии в бесполезный набор файлов.
Отдельный вопрос связан с отказоустойчивостью управляющего контура. Разработчик описывает подходы к восстановлению Master Server, но для конкретной инфраструктуры необходимо проверить восстановление конфигурации и каталогов после полной потери управляющего узла. Высокая пропускная способность Power Server не компенсирует невозможность быстро восстановить саму систему управления.
Лицензирование строится на метрике Front-End Terabytes. Объём определяется по исходным защищаемым данным, но есть важная особенность. Для виртуальных машин учитывается выделенное пространство виртуальных дисков без учёта фактической утилизации. Для файловых систем на блочных или сетевых устройствах также могут применяться правила учёта полной доступной ёмкости. В инфраструктуре с большим количеством тонко выделенных виртуальных дисков лицензируемый объём способен существенно превышать фактически занятое пространство.
Лицензии бессрочные, а техническая поддержка и подписка имеют отдельные условия. Доступны базовый и расширенный уровни сопровождения. При проектировании необходимо учитывать не только объём данных, но и требуемое время реакции, режим поддержки и доступность компетентных специалистов.
Главное ограничение «Бересты» я вижу не в нехватке заявленных функций, а в меньшей доказательной базе. Независимых подробных эксплуатационных материалов заметно меньше, чем у двух лидеров. Поэтому сложнее оценивать частоту регрессий, поведение длинных цепочек резервных копий, стабильность каталога и время восстановления после нестандартной аварии.
Для продукта подтверждено включение в реестр российского ПО. Актуальный сертификат ФСТЭК на саму СРК я не считаю подтверждённым без соответствующей записи в официальном реестре. Для коммерческого заказчика отсутствие обязательной сертификации может не иметь решающего значения, но в регулируемом проекте вопрос необходимо закрыть до закупки.
Мой вывод. «Береста» заслуживает пилота в крупных инфраструктурах с большим количеством СУБД, российской виртуализацией и высокими требованиями к потоковой передаче данных. Третье место связано прежде всего с меньшей накопленной зрелостью и ограниченным независимым опытом, а не с отсутствием полноценной корпоративной архитектуры.
Прогноз. Потенциал высокий. До 2028–2029 годов продукт способен приблизиться к лидерам при условии расширения промышленной базы и стабилизации релизов. Главным фактором роста считаю современную архитектуру и ориентацию на актуальные российские системы. Основной риск связан с ограниченным количеством специалистов и необходимостью постоянно подтверждать качество эксплуатации по мере расширения функциональности.
Отдельный класс Disaster Recovery и миграции
Платформы Disaster Recovery не следует оценивать по тем же критериям, что традиционные СРК. Основная задача DR заключается в восстановлении работы приложений и инфраструктуры после серьёзной аварии, часто с запуском нагрузки на другой площадке или другой технологической платформе.
Хайстекс Акура
«Хайстекс Акура» работает на пересечении резервного копирования, репликации, миграции и аварийного восстановления. Актуальная версия 4.6 выпущена 5 августа 2026 года. Весенний релиз 4.5 существенно обновил слой хранения, а последующий 4.6 расширил механизмы репликации и Disaster Recovery.
Одна из наиболее интересных технологий называется Direct2Target. Механизм позволяет передавать данные между агентами без обязательной зависимости от управляющего API целевой платформы. В версии 4.6 появились дополнительные сценарии DR и оптимизации передачи данных. Для неоднородной инфраструктуры такая архитектура может оказаться особенно полезной при переходе между гипервизорами и облаками.
В версии 4.5 разработчик представил Backup 2.0 с дедупликацией на уровне репозитория, шифрованием и адаптивным сжатием. Также добавлена поддержка специализированного резервирования PostgreSQL и S3 Object Lock для создания неизменяемых точек восстановления. Возможность защитить резервную копию от изменения и удаления делает платформу интереснее для сценариев восстановления после ransomware.
В версии 4.6 добавлен механизм CBT для внешней репликации OpenStack, работающий на уровне QEMU/KVM без привязки к определённому хранилищу. Для крупных инфраструктур подобная независимость потенциально снижает ограничения, связанные с выбором СХД. Но эффективность зависит от используемых версий, настроек и профиля нагрузки.
«Акура» умеет работать с различными вариантами целевого хранения, включая блочные устройства, S3, NFS и SMB. При этом быстрый запуск с блочного хранилища и длительное хранение в объектном репозитории решают разные задачи. Архитектура DR должна учитывать время передачи данных, подготовку вычислительных ресурсов, сетевую связность и зависимости между приложениями.
По сравнению с универсальными СРК продукт сильнее ориентирован на восстановление целых нагрузок, перенос между платформами и сценарии катастрофоустойчивости. Если организация должна восстановить несколько сотен виртуальных машин на резервной площадке, возможности «Акуры» могут оказаться важнее широкого перечня прикладных агентов. Для многолетнего хранения разнообразных корпоративных данных я бы по-прежнему сравнивал её с универсальной СРК.
Мой вывод. «Хайстекс Акура» входит в число наиболее интересных российских платформ DR и миграции. В отдельный класс продукт попадает из-за различий в назначении, а не вследствие недостаточного качества.
Прогноз. Потенциал высокий. Фрагментация российского рынка виртуализации, развитие гибридных инфраструктур и потребность в переносе нагрузок между площадками должны поддерживать спрос. Главный риск связан с необходимостью сохранять надёжность интеграций при постоянном появлении новых платформ.
Частные оценки универсальных СРК
Итоговая оценка показывает пригодность продукта для выбранного сценария, а не абсолютное качество во всех условиях. Для исключительно российской инфраструктуры я увеличил бы вес отечественных интеграций. Для среды с жёсткими требованиями к регуляторному соответствию пришлось бы отдельно оценивать сертифицированные исполнения.
| Критерий | Вес | Кибер Бэкап | RuBackup | Береста |
|---|---|---|---|---|
| Функциональность и восстановление | 25% | 9,6 | 9,2 | 8,2 |
| Архитектура и масштабируемость | 20% | 9,3 | 9,0 | 9,0 |
| Киберустойчивость | 15% | 8,5 | 8,5 | 8,2 |
| Российские интеграции | 15% | 9,3 | 9,7 | 8,8 |
| Эксплуатация и автоматизация | 10% | 9,0 | 8,3 | 8,2 |
| Зрелость и внедрения | 10% | 9,6 | 8,6 | 7,2 |
| Лицензирование и регуляторная применимость | 5% | 7,7 | 9,3 | 7,4 |
| Итог | 100% | 9,2 | 9,0 | 8,3 |
Специализированные российские системы хранения резервных копий
Рынок резервного копирования невозможно полноценно оценить без систем хранения. Именно репозиторий часто определяет фактическую ёмкость архива, скорость чтения и записи, возможность репликации на удалённую площадку и устойчивость к удалению данных.
TATLIN.BACKUP
TATLIN.BACKUP представляет специализированную линейку российских систем хранения резервных копий. Продукт не заменяет универсальную СРК, поскольку не управляет резервированием всех прикладных нагрузок. Основная задача заключается в приёме, оптимизации, хранении и защите данных, поступающих от внешних систем.
Архитектура использует глобальную дедупликацию, компрессию, собственные механизмы работы с данными и протокол T-BOOST. Последний позволяет выполнять часть дедупликации на стороне источника, уменьшая объём передаваемого трафика. Заявленные показатели ускорения зависят от профиля данных и условий тестирования, поэтому переносить цифры производителя на конкретный проект без пилота нельзя.
В январе 2026 года вышла версия 1.4 с квотированием виртуальных файловых систем. Для многопользовательских сред такой механизм полезен при разделении ресурсов между подразделениями и независимыми задачами резервного копирования.
В августе 2026 года производитель объявил о начале приёма заказов на TATLIN.BACKUP.L и выпустил версию программного обеспечения 1.5. Старшая модель получила два контроллера и полезную ёмкость свыше петабайта. В версии 1.5 появилась асинхронная репликация виртуальных файловых систем между устройствами. Для резервного копирования крупных ЦОД подобная функция важна, поскольку позволяет формировать удалённую копию репозитория.
Отдельный интерес представляет запланированный режим «Бункер». Разработчик связывает его с дальнейшим повышением киберустойчивости хранилища, но относит реализацию к следующему выпуску 1.6. Я не считаю дорожную карту готовой функцией версии 1.5.
Мой вывод. TATLIN.BACKUP заслуживает отдельного пилота для крупных систем резервного копирования, где требуются высокая плотность хранения, дедупликация, репликация и дополнительная защита репозитория. Продукт нужно оценивать совместно с выбранной программной СРК.
XPlatform XTime
XPlatform XTime представляет программно-аппаратный комплекс хранения резервных копий из экосистемы «Группы Астра». В основе программной части используется платформа BRO, разработанная российской компанией «БРО Софтвер». Программная платформа отвечает за дедупликацию и хранение данных, а аппаратная составляющая поставляется в составе комплекса.
Особенно интересен сценарий распределённого хранения. На филиальной площадке может размещаться BRO-клиент, который записывает данные локально и одновременно передаёт их на центральный узел. Такая схема позволяет быстро восстанавливать данные филиала и сохранять дополнительную копию на центральной площадке.
Для XTime заявлены дедупликация, управление репозиториями, веб-интерфейс и собственная файловая система BroFS. Но публичной независимой эксплуатационной информации пока недостаточно, чтобы оценить зрелость всех режимов, особенно при больших объёмах и авариях каналов связи.
Сертификацию программных компонентов и операционной системы нельзя автоматически распространять на программно-аппаратный комплекс целиком. Для регулируемого проекта необходимо проверять документы на конкретную конфигурацию поставки.
Мой вывод. XTime представляет интерес для крупных заказчиков и филиальных инфраструктур, особенно при построении единого хранилища резервных копий. Сравнивать его непосредственно с универсальными СРК некорректно.
Другие российские решения
За пределами основной тройки существует несколько самостоятельных продуктов с узкой специализацией. Отдельно встречаются решения, для которых доступных сведений пока недостаточно для полноценной оценки. Я не присваиваю таким продуктам баллы без сопоставимого технического и эксплуатационного анализа.
Basis Virtual Protect
Basis Virtual Protect предназначен для резервного копирования и восстановления в экосистеме Basis. Платформа ориентирована на защиту виртуальных машин и соответствующих инфраструктурных ресурсов, включая отдельные сценарии контейнеризации.
Важное отличие заключается в тесной интеграции с собственной платформой виртуализации. Для стандартизированной среды такой подход может упростить администрирование и обеспечить более предсказуемую совместимость. Но продукт не следует считать полной заменой универсальной СРК для произвольного набора операционных систем, СУБД и гипервизоров.
Postgres Pro Backup Enterprise
Postgres Pro Backup Enterprise специализируется на резервном копировании PostgreSQL и Postgres Pro. Продукт поддерживает различные режимы копирования, инкрементальные сценарии, WAL, проверку целостности, удалённую работу, S3 и восстановление на заданный момент времени.
Актуальная версия 3.4.1 вышла 7 августа 2026 года. Выпуск исправил несколько серьёзных ошибок предыдущей версии, включая потенциальное повреждение данных при определённых условиях повторной записи и проблемы проверки цепочки резервных копий при объединении. Такой пример хорошо показывает, почему даже специализированный зрелый инструмент требует внимательного сопровождения и проверки восстановления после обновления.
Для крупной PostgreSQL-инфраструктуры продукт способен оказаться эффективнее универсальной СРК в отдельных сценариях. Но специализированное резервирование базы не заменяет защиту ОС, конфигурации, виртуализации и зависимых приложений.
ROC Backup
ROC Backup предназначен для резервного копирования данных Яндекс 360. Поддерживаются почта, диск и календарь, поиск отдельных объектов и выборочное восстановление. Продукт помогает сохранять данные уволенных сотрудников и возвращать случайно удалённые письма и файлы.
С 1 июля 2026 года минимальный пакет временных лицензий составляет 300 пользователей, также сохраняется требование лицензировать не менее 70 процентов пользователей Яндекс 360. Поэтому решение ориентировано прежде всего на корпоративные внедрения, а не на небольшие организации.
Handy Backup
Handy Backup представляет давно развивающуюся российскую линейку средств резервного копирования. Доступны редакции для рабочих станций, серверов и сетевых инфраструктур, резервирование файлов, баз данных, отдельных приложений и сетевых ресурсов.
Версия 8.7.4 датирована 29 сентября 2026 года. В ней исправлены ошибки обработки символических ссылок и сохранения настроек, а также обновлены отдельные интеграции с внешними хранилищами. Активная поддержка подтверждается историей релизов, но по масштабу централизованного управления и enterprise-сценариям продукт разумнее рассматривать отдельно от первой тройки.
1С Облачный архив
«1С Облачный архив» предназначен для автоматизированного резервного копирования информационных баз «1С:Предприятия». Поддерживаются копирование по расписанию, по требованию и хранение данных в удалённом сервисе.
Для небольшой организации такой сервис может закрыть конкретную потребность без развёртывания сложной СРК. Но для серверных баз данных, кластеров 1С и комплексного восстановления инфраструктуры требуются другие механизмы.
BAUM BaS
BAUM BaS представляет систему резервного копирования и восстановления данных от российского разработчика BAUM. Для продукта опубликованы описание архитектуры, функциональная матрица и руководство администратора. Заявлена защита физических и виртуальных сред, СУБД, файловых ресурсов и различных хранилищ.
В технических материалах заметна архитектурная основа Bacula, включая Director и Storage Daemon. Использование такой технологии само по себе не исключает продукт из российского рынка, но требует отдельной проверки собственных разработок, состава поставки, сопровождения и реализованных отличий от исходной платформы.
Я не включаю BAUM BaS в числовой рейтинг, поскольку публичных независимых подтверждений промышленной зрелости и собственных технологических преимуществ пока недостаточно. По назначению продукт относится к универсальным СРК, поэтому при появлении новых подтверждений заслуживает повторного рассмотрения.
Циркон-Резерв
«Циркон-Резерв» представляет российский программный комплекс резервного копирования и восстановления данных с возможностями кластеризации и управления хранилищами. Разработчик описывает веб-интерфейс, поиск и восстановление файлов, а также отказоустойчивую архитектуру.
Продукт присутствует на официальном сайте и имеет длительную историю, однако подробной актуальной документации и независимых эксплуатационных материалов недостаточно. Поэтому отсутствие числового балла не следует трактовать как отрицательную оценку качества.
Облачное резервное копирование как отдельный сегмент
Сервисы Backup as a Service работают по другой модели. Заказчик получает готовую услугу резервного копирования, а поставщик отвечает за определённую часть инфраструктуры хранения и управления. При этом распределение ответственности между клиентом и провайдером зависит от конкретного договора и архитектуры.
В России такие услуги предлагают несколько крупных облачных платформ, включая Yandex Cloud Backup, VK Cloud, Selectel и MWS. Функциональность и границы ответственности необходимо уточнять для конкретной услуги и региона размещения.
Облачное резервное копирование особенно удобно для филиалов, небольших инфраструктур и организаций, которые не хотят самостоятельно обслуживать весь backup-контур. Но перенос ответственности не означает исчезновения рисков. Клиент должен понимать, где хранятся данные, какие учётные записи могут удалить резервные копии и как получить доступ к архиву при недоступности управляющего облачного сервиса.
Отдельно необходимо проверять независимость резервных копий от основной облачной площадки. Если продуктивные ресурсы и все резервные копии находятся в одной зоне отказа, серьёзная авария может одновременно затронуть оба контура. Для критичных систем я предпочитаю архитектуру с дополнительной копией в независимом месте хранения.
Важен и сценарий выхода от провайдера. Данные должны быть доступны для выгрузки и восстановления после прекращения договора или миграции. Проприетарный формат архива способен создать зависимость от конкретной облачной платформы даже при стандартном объектном хранении.
Регуляторные требования и сертификаты
Для государственных и регулируемых информационных систем выбор СРК связан не только с техническими характеристиками, но и с нормативными требованиями. Приказ ФСТЭК России № 117 вступил в силу 1 марта 2026 года. С 1 сентября действует редакция с изменениями, внесёнными приказом № 137 от 8 мая 2026 года.
Пункт 55 предусматривает создание достаточного количества резервных копий программных и программно-аппаратных средств, конфигураций и информации, необходимой для выполнения значимых функций. Требования охватывают хранение копий на разных типах носителей, защиту от несанкционированного доступа и периодическую проверку возможности восстановления.
Особенно существенно требование проводить проверки восстановления значимых функций, в том числе в форме тренировок, не реже одного раза в два года. Формальное наличие резервных копий без проверки возможности восстановить систему не закрывает задачу.
Для конкретного проекта необходимо определить применимость нормативных требований, сформировать регламенты, установить RPO и RTO, выбрать схему хранения и подтвердить работоспособность восстановления. Сертификат продукта не заменяет проектирование и выполнение организационных мер.
Необходимо также различать включение в реестр российского ПО, сертификат ФСТЭК на средство защиты, сертификат совместимости и отраслевые разрешительные документы. Каждая категория подтверждает разные свойства. Наличие любого одного документа не означает автоматического выполнения всех требований к информационной системе.
На октябрь 2026 года сертификаты RuBackup и «Кибер Бэкапа» необходимо рассматривать с учётом конкретных версий и исполнений. Для RuBackup опубликован сертификат № 4879 со сроком действия до ноября 2029 года. Для «Кибер Бэкапа» опубликованные разработчиком сведения о сертификате № 4337 требуют уточнения применительно к актуальной ветке 18.6. Без проверки официального реестра и формуляра нельзя считать любую текущую сборку сертифицированной.
Какие реальные проблемы обнаруживаются при эксплуатации
Первый источник проблем связан с обновлениями. СРК работает с большим количеством агентов, драйверов, API и хранилищ. Изменение версии гипервизора или ядра Linux способно нарушить резервирование без явного изменения самой СРК. Поэтому крупные инсталляции нуждаются в тестовом контуре и контролируемой политике обновлений.
Вторая проблема связана с каталогом резервных копий. Система может продолжать хранить данные физически, но потеря служебной базы, индексов или конфигурации усложнит восстановление. Для критичной инфраструктуры необходимо проверять возможность вернуть саму СРК после потери управляющего сервера и восстановить доступ к существующим копиям.
Третья проблема касается производительности. Заявленная скорость резервного копирования часто относится к ограниченному набору условий. В реальном ЦОД на результат влияют маленькие файлы, сжатые и зашифрованные данные, сетевые задержки, нагрузка на хранилище, количество потоков и операции дедупликации. Особенно важно измерять не только запись, но и восстановление.
Четвёртая проблема связана с длинными цепочками инкрементальных копий. Со временем растёт нагрузка на каталог, операции синтетического полного резервирования, объединение цепочек и проверку целостности. Хорошие результаты на первой неделе пилота ничего не говорят о поведении репозитория через год.
Пятая проблема относится к защите от ransomware. Неизменяемый репозиторий способен сохранить резервную копию от удаления, но не гарантирует отсутствие вредоносных компонентов внутри данных. Если злоумышленник находился в инфраструктуре несколько недель, часть сохранённых точек восстановления уже может содержать изменённые файлы, вредоносные задания или скомпрометированные учётные записи.
Поэтому восстановление после кибератаки требует дополнительной проверки целостности и безопасности восстановленной среды. Организация должна знать не только момент создания копии, но и предполагаемое время компрометации. В противном случае восстановление способно вернуть в инфраструктуру прежнюю угрозу.
Наконец, остаётся проблема независимого пользовательского опыта. Публичных технических руководств и маркетинговых кейсов много, но сопоставимых отчётов о длительной эксплуатации существенно меньше. Я не стал бы превращать отдельную жалобу на обновление или интерфейс в характеристику всего продукта. Одновременно отсутствие публичных жалоб не следует воспринимать как доказательство надёжности.
Что проверить на пилоте перед закупкой
Пилот резервного копирования должен завершаться проверенным восстановлением, а не только отчётом об успешном создании копий. Я бы включил следующие испытания.
- Совместимость инфраструктуры. Проверить конкретные версии ОС, гипервизоров, СУБД и приложений. Результатом должна стать подтверждённая матрица поддерживаемых операций, а не общий список платформ.
- Полное резервное копирование. Измерить время создания полной копии типичного набора нагрузок. Одновременно фиксировать нагрузку на CPU, сеть, дисковые системы и продуктивные приложения.
- Инкрементальное резервирование. Проверить работу длинной цепочки копий и изменение объёма репозитория. Оценить стабильность после нескольких циклов объединения и очистки.
- Полное восстановление виртуальной машины. Удалить тестовую ВМ и восстановить её на исходную площадку. Зафиксировать фактические RPO и RTO, включая запуск приложения.
- Восстановление на другую платформу. Если функция заявлена, проверить перенос между используемыми гипервизорами. Убедиться в работоспособности загрузки, сети, драйверов и приложения.
- Восстановление СУБД. Проверить полную базу, журналы транзакций, восстановление на определённый момент времени и прикладную согласованность.
- Гранулярное восстановление. Вернуть отдельный файл, объект каталога, почтовое сообщение или другой элемент приложения без полного восстановления системы.
- Потеря сервера управления. Вывести из строя центральный сервер СРК и восстановить доступ к существующим копиям. Измерить время возвращения каталога и политик.
- Потеря медиасервера. Отключить компонент передачи данных во время резервирования и проверить корректное завершение или повтор операции после восстановления связи.
- Компрометация администратора. Попытаться удалить копии через максимально привилегированную учётную запись. Независимый защищённый репозиторий должен сохранить данные.
- Проверка неизменяемости. Проверить невозможность удалить или изменить резервные копии в пределах retention, включая сценарии через административный интерфейс хранилища.
- Восстановление после ransomware. Смоделировать наличие заражённых файлов в старых точках и проверить процесс выбора безопасной копии и развёртывания изолированной среды.
- Обновление компонентов. Выполнить переход между поддерживаемыми версиями СРК и убедиться, что старые копии, политики, роли и интеграции продолжают работать.
- Нагрузочное испытание. Воспроизвести количество заданий, агентов и точек восстановления, близкое к ожидаемому промышленному масштабу.
- Проверка лицензий. Рассчитать потребление по фактическим метрикам, включая выделенную ёмкость виртуальных дисков, источники данных, репозитории и сроки хранения.
- Проверка поддержки. Открыть тестовое обращение со сложной диагностикой и оценить качество ответа, полноту инструкций и порядок эскалации.
В результате пилота должен появиться не перечень успешных заданий, а протокол с измеренными RPO и RTO, ограничениями, подтверждённой совместимостью, описанием аварийных сценариев и перечнем рисков, которые невозможно закрыть штатными средствами продукта.
Мой выбор для разных корпоративных задач
Крупная смешанная инфраструктура. Я бы начинал с «Кибер Бэкапа». Широкая поддержка платформ, зрелая архитектура и доступность эксплуатационных знаний делают его наиболее универсальным кандидатом.
Преимущественно российская инфраструктура. RuBackup выглядит особенно убедительно. Глубокая интеграция с российской виртуализацией, СУБД и корпоративными приложениями способна перевесить небольшое преимущество конкурента в общей функциональной зрелости.
Большие потоки данных и специализированные СУБД. Я бы обязательно включал «Бересту» в пилот. Архитектура хорошо подходит для оценки высоконагруженного резервирования, но промышленную надёжность необходимо подтвердить собственными испытаниями.
Disaster Recovery и миграция между гипервизорами. Предпочтительнее рассматривать «Хайстекс Акура». Платформа ориентирована на перенос и запуск нагрузок, а не только на хранение резервных копий.
Стандартизированная инфраструктура Basis. Basis Virtual Protect может оказаться рациональнее универсальной СРК для защиты собственной платформы виртуализации.
Большая PostgreSQL-инфраструктура. Postgres Pro Backup Enterprise заслуживает отдельного сравнения с универсальными решениями, особенно при строгих требованиях к восстановлению транзакционных данных.
Дедуплицирующее корпоративное хранилище. TATLIN.BACKUP и XPlatform XTime стоит рассматривать как самостоятельный слой архитектуры. Выбор зависит от совместимости с СРК, восстановления, репликации, отказоустойчивости и эксплуатационных требований.
Яндекс 360. ROC Backup решает специфическую задачу защиты корпоративных облачных данных, которую традиционная серверная СРК может не охватывать.
Малый бизнес и отдельные подразделения. Handy Backup способен закрыть необходимый набор сценариев без сложности большой корпоративной платформы. Для файловых баз 1С имеет смысл отдельно рассмотреть «1С Облачный архив».
Прогноз российского рынка СРК на 2027–2029 годы
В ближайшие два-три года функциональные различия между универсальными российскими СРК, вероятно, продолжат сокращаться. Поддержка новых Linux-дистрибутивов, PostgreSQL и распространённых гипервизоров постепенно станет стандартным требованием. Конкуренция переместится в области восстановления, киберустойчивости, автоматизации и эксплуатационной предсказуемости.
Первым направлением считаю неизменяемое хранение. Защита резервных копий от удаления и изменения постепенно перестанет быть дополнительным требованием особо осторожных заказчиков. Но универсальная поддержка S3 ещё не означает полноценной работы с Object Lock, а наличие аппаратных снимков не заменяет независимого административного контура.
Второе направление связано с восстановлением между платформами. Российская виртуализация остаётся фрагментированной, поэтому заказчикам нужны инструменты, которые позволяют переносить резервные копии и рабочие нагрузки между различными гипервизорами. Здесь возможности RuBackup и «Хайстекс Акуры» выглядят особенно интересными.
Третье направление связано с прикладным резервированием. Защита виртуальной машины недостаточна для многих СУБД, систем каталогов и контейнерных приложений. Я ожидаю дальнейшего развития специализированных агентов, согласованного копирования и гранулярного восстановления.
Четвёртое направление связано с системами хранения. TATLIN.BACKUP и XPlatform XTime показывают, что российский рынок постепенно формирует собственный слой backup storage. В ближайшие годы конкуренция будет затрагивать не только программные СРК, но и дедупликацию, репликацию, неизменяемость и восстановление непосредственно из репозитория.
Пятое направление касается автоматической проверки восстановления. Успешное завершение backup job ещё не подтверждает возможность запустить приложение. Более зрелые платформы будут стремиться автоматизировать развёртывание тестовых машин, проверку файловых систем, целостности СУБД и выполнение прикладных проверок.
Возможности искусственного интеллекта, вероятно, тоже появятся в маркетинговых материалах разработчиков. Я бы относился к таким функциям осторожно. Прогнозирование объёма репозитория, выявление аномалий и анализ журналов могут приносить пользу, но не заменяют проверенную архитектуру хранения и детерминированные процедуры восстановления.
Для «Кибер Бэкапа» я ожидаю сохранения сильных позиций за счёт зрелости и широкого охвата. Для RuBackup считаю вероятным дальнейшее усиление в инфраструктурах с российским стеком. «Береста» имеет хорошие шансы сократить отставание, если расширит промышленную базу и сохранит качество обновлений. «Хайстекс Акура» будет развиваться рядом с универсальным сегментом, используя спрос на катастрофоустойчивость и миграцию.
Главным ограничителем роста молодых участников останется доверие крупных заказчиков. Резервное копирование относится к инфраструктуре, качество которой окончательно проверяется в самый неприятный момент. Красивый интерфейс, высокая скорость записи и длинный список интеграций не компенсируют невозможность восстановить повреждённую базу данных или запустить критичное приложение после аварии.
Поэтому я ожидаю, что через два-три года расстановка сил будет зависеть не столько от количества функций, сколько от способности разработчиков демонстрировать стабильное восстановление в больших производственных средах, выпускать предсказуемые обновления и обеспечивать качественную техническую поддержку.
Итог
Российский рынок резервного копирования в 2026 году уже предлагает реальные альтернативы западным корпоративным СРК. «Кибер Бэкап» остаётся наиболее универсальным выбором для смешанной инфраструктуры. RuBackup практически сравнялся с ним и может оказаться сильнее в российском технологическом стеке. «Береста» представляет интерес как современная платформа с хорошими перспективами, хотя накопленного независимого опыта пока меньше.
Отдельно сформировался рынок продуктов для катастрофоустойчивости, прикладного резервирования и хранения резервных копий. «Хайстекс Акура», Basis Virtual Protect, Postgres Pro Backup Enterprise, TATLIN.BACKUP и XPlatform XTime решают задачи, которые не всегда эффективно закрываются одной универсальной системой.
Я бы не рекомендовал выбирать СРК только по рейтингу или матрице совместимости. Для корпоративной инфраструктуры решающим испытанием остаётся восстановление после реального отказа. Лучшая система резервного копирования не та, которая быстрее всех создаёт архив, а та, которая позволяет предсказуемо вернуть нужные данные и приложения в установленный срок, даже когда часть инфраструктуры уже потеряна.
