На этапе масштабирования инфраструктуры вчерашние рабочие процессы часто превращаются в архитектурные Барьеры. Линейный рост расходов на хранение, неочевидная консистентность СУБД при восстановлении из снапшотов и зависимость миграции от наличия и «капризов» API целевой платформы — это реальность, с которой сталкиваются многие команды. Ситуация усложняется, когда бэкапы становятся целью для атак, а стандартного контроля доступа оказывается недостаточно для гарантии сохранности данных. В релизе Хайстекс Акура 4.5 мы собрали как раз те возможности, отсутствие которых в 2026 году уже сложно себе представить. 

Direct2Target — миграция вопреки ограничениям

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

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

Direct2Target — это подход, при котором Акура реплицирует данные ВМ и выполняет восстановление на уровне диска, не обращаясь к API управления целевой платформы. На целевой стороне развёртывается специальный агент D2T (его можно скачать из панели управления Акуры и идентифицировать в интерфейсе по IP-адресу). Агент самостоятельно обрабатывает приём реплики, разметку диска и восстановление. Акура напрямую доставляет данные на целевые хосты или в хранилище. Платформа умеет работать на уровне гипервизора и систем хранения данных, что делает процесс миграции полностью независимым от «капризов» или ограничений управления облаком. 

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

Бэкап 2.0: новый слой хранения данных

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

Бэкап 2.0 — это новый слой хранения с пересмотренной архитектурной основой. Ключевые возможности реализации в версии 4.5:

• Глобальная дедупликация: движок работает на уровне всего пула хранилища, а не отдельного устройства. Идентичные блоки данных из разных машин и разных точек восстановления сохраняются только один раз, что значительно снижает объём занятого пространства в средах с однотипными ВМ.

• Шифрование: данные резервных копий шифруются на уровне хранилища. Это обеспечивает защиту данных в покое без необходимости развёртывания внешней инфраструктуры управления ключами.

• Настраиваемое сжатие: предусмотрена возможность выбора алгоритма сжатия под конкретные приоритеты — пропускную способность, степень компрессии или нагрузку на CPU.

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

• Совместимость с Kopia: формат хранилища совместим с Kopia, что обеспечивает проверенную архитектуру структуры данных и логики дедупликации.

Для сред с большим количеством однотипных ВМ (характерных для VDI, DevOps-пайплайнов или шаблонной облачной инфраструктуры) глобальная дедупликация позволяет существенно сократить расходы на хранение по сравнению с традиционными методами. Встроенное шифрование закрывает требования по безопасности данных без внесения дополнительной операционной сложности, а гибкая настройка сжатия позволяет адаптировать систему под разные профили нагрузки.

Нативное резервное копирование PostgreSQL

Резервное копирование PostgreSQL путём создания снапшотов всей виртуальной машины фиксирует только состояние диска на уровне блоков. Такой подход не учитывает требования СУБД к внутренней согласованности данных. Снимок, сделанный в момент выполнения активных транзакций, может быть технически полным на уровне ФС, но несогласованным на уровне базы данных. Это вынуждает администраторов выполнять дополнительные шаги по восстановлению консистентности, что увеличивает время простоя и риски потери данных. Инженерам необходим инструмент, который понимает семантику СУБД, а не просто копирует состояние диска.

В принцип работы Хайстекс Акура 4.5 добавлен специализированный агент резервного копирования PostgreSQL. Это компонент файлового уровня, интегрированный с нативными потоками бэкапа и восстановления СУБД. Вместо создания снимка всего диска ВМ, агент инициирует внутренний процесс резервного копирования базы данных, обеспечивая её согласованность. Рабочие процессы восстановления полностью соответствуют стандартным практикам администраторов PostgreSQL и используют нативные механизмы СУБД.

Организации, эксплуатирующие PostgreSQL как self-hosted или управляемую базу данных, теперь могут защищать её с помощью инструмента, понимающего структуру данных СУБД. Это позволяет отказаться от снимков всей ВМ и исключить необходимость в ручных шагах по восстановлению базы. Решение особенно актуально для команд, которые уже используют типовые практики обслуживания PostgreSQL и стремятся к предсказуемости процессов восстановления. О границах ответственности между PostgreSQL и внешней платформой мой коллега Виктор недавно писал тут.

Поддержка S3 Object Lock: неизменяемые точки восстановления

Один из наиболее эффективных векторов атак программ-вымогателей на инфраструктуру резервного копирования — это атака на само хранилище бэкапов. Если данные можно удалить или перезаписать, резервная копия перестаёт быть надёжным инструментом восстановления.

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

В Хайстекс Акура 4.5 добавлена поддержка S3 Object Lock для создания неизменяемых точек восстановления. При активации этой функции данные, записанные в S3-совместимое хранилище, блокируются на определённый период. В течение этого времени их нельзя удалить или перезаписать никакими средствами — включая административный доступ, автоматизированные процессы или программы-вымогатели.

Что внутри:

• Гибкость настройки: параметры Object Lock задаются отдельно для каждой цели облачного хранилища.

• Защита от ошибок: интерфейс отображает предупреждения при активном Object Lock, что предотвращает случайную неправильную настройку периодов хранения.

• Корректная логика удаления: операции удаления машин или бэкапов с активными блокировками обрабатываются системой с учётом защитных ограничений.

• Legal hold: поддерживается режим «юридического удержания» для сценариев, требующих неопределённого срока хранения данных.

• Универсальность: неизменяемые копии совместимы как с блочным, так и с файловым потоками резервного копирования Акуры.

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

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

Новые целевые платформы

В версии 4.5 расширен список поддерживаемых платформ для сценариев миграции, аварийного восстановления и резервного копирования:

• Deckhouse Virtualization Platform — решение на базе Kubernetes, разработанное компанией «Флант» на основе открытого проекта Deckhouse. Платформа позволяет запускать виртуальные машины в Kubernetes-окружении, используя унифицированный стек управления.

• РЕД Виртуализация — сертифицированная отечественная платформа, включённая в реестр российского ПО. Решение построено на базе технологий oVirt/RHEV и активно применяется в организациях с требованиями по импортозамещению, включая банковский сектор.

Оптимизация производительности для платформ на базе oVirt

Акура 4.5 включает целевые улучшения производительности репликации для oVirt и производных от него платформ — в том числе zVirt, РЕД Виртуализации и других совместимых систем. Изменения устраняют конкретные узкие места в пути передачи данных, повышая пропускную способность и сокращая время репликации для крупных ВМ или высоконагруженных задач репликации. Дополнительные улучшения включают более качественную балансировку облачных агентов, а также настраиваемый лимит числа параллельных репликаций для предотвращения исчерпания ресурсов при высокой нагрузке.

Управление аудитом и обновления безопасности

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

Теперь в Хайстекс Акура 4.5 представлен новый фреймворк событий аудита, который фиксирует и транслирует связанные с безопасностью события по всей платформе:

• Сбор на уровне API: события аудита собираются на уровне REST API и распространяются через основные сервисы платформы.

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

• Визуализация: данные событий аудита доступны через встроенный в платформу стек наблюдаемости на основе Grafana.

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

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

Обновление 4.5 — это попытка сделать процесс миграции и защиты данных независимым от «капризов» API и закрытости целевых платформ. Переход на нативные агенты для PostgreSQL и внедрение дедупликации на уровне всего хранилища превращают бэкап из тяжеловесного снапшота в защищенный инструмент. А поддержка неизменяемых точек в S3 фактически подводит черту под вопросом выживаемости данных при компрометации основной инфраструктуры. Теперь дело за практикой — тестированием этих механизмов в реальных высоконагруженных контурах.