Выход из VMware может оказаться не только заменой гипервизора, но и ревизией всей схемы защиты данных: от снапшотов до восстановления площадки. Для русскоязычных IT-команд это практичный сигнал: миграцию нельзя считать завершённой, если вместе с виртуальными машинами переехали старые слабые места.
В партнёрском материале, опубликованном 2 октября 2026 года, The Register пересказывает позицию VergeIO: уход с VMware стоит использовать как повод заново распределить роли между производственной платформой и системой резервного копирования. Автор текста — Джордж Крамп, директор по маркетингу VergeIO, ранее основавший аналитическую компанию Storage Switzerland. Поэтому материал лучше читать не как нейтральный обзор рынка, а как аргумент поставщика, который продвигает собственную архитектуру VergeOS.
Главная мысль проста и неприятна для тех, кто любит миграции по принципу «перенесли как было». Типичная схема защиты в среде vSphere завязана на конкретные механизмы VMware: changed block tracking, vStorage APIs, поведение снапшотов во время задания резервного копирования, интеграции с хранилищами через инвентарь vCenter и прокси, разложенные по кластерам. В некоторых инфраструктурах к этому добавляется Site Recovery Manager или похожий оркестратор для сценариев аварийного переключения. При смене гипервизора все эти допущения приходится проверять заново.
По версии VergeIO, ошибка многих команд в том, что они хотят перенести старую модель защиты почти без изменений: продакшен отдельно, резервное копирование отдельно, репликация отдельно, отказоустойчивость отдельно, консоли и лицензии тоже отдельно. Такая схема была логичной для классической серверной виртуализации: гипервизор абстрагировал один сервер, а устойчивость хранения и восстановление отдавались массивам, backup-софту и дополнительным продуктам. Первое поколение HCI во многом сохранило тот же подход, только перенесло storage ближе к серверам.
Проблема всплывает в день аварии. Если падает площадка, инженерам приходится одновременно трогать гипервизор, систему хранения, приложение резервного копирования, репликацию и сетевую конфигурацию. Восстановление проходит через несколько границ ответственности, и каждая из них добавляет задержку, риск ошибки и отдельный набор лицензий. Выход из VMware, как пишет VergeIO, впервые за долгое время открывает окно, в котором эту конструкцию можно не просто воспроизвести, а пересобрать.
VergeIO предлагает модель «виртуализации дата-центра», где compute, storage, сеть и часть функций защиты данных живут в одной кодовой базе и используют общий набор метаданных. В такой логике производственная платформа должна брать на себя больше повседневной устойчивости: переживать сбои дисков, давать быстрый откат после неудачного патча, выполнять снапшоты, обеспечивать instant recovery и site failover. Тогда backup-приложение меньше участвует в мелких пожарах рабочего дня и остаётся для задач, где оно действительно нужно.
Роль резервного копирования при этом не исчезает. Наоборот, она становится более стратегической. В материале приводится пример Veeam Backup & Replication, который поддерживает VergeOS: уже существующие бэкапы VMware можно использовать как путь миграции, восстановив виртуальные машины в новой среде, протестировав их и переключившись по контролируемому графику. После переезда backup-система продолжает отвечать за долгосрочное хранение, архивы для compliance, offsite- и air-gapped-копии, а также точечное восстановление данных для владельцев приложений.
Для бизнеса здесь есть важная развилка. Если новая платформа берёт на себя больше функций защиты, компания потенциально сокращает число отдельных продуктов, консолей и контрактов. Но ответственность концентрируется у одного поставщика, и это уже не вопрос красивой схемы в презентации. VergeIO советует проверять такие заявления живыми тестами: выдернуть диск на работающем приложении, затем второй диск сверх заявленного лимита защиты, удалить виртуальную машину и восстановить из неё отдельный файл, а затем отключить основную площадку и поднять окружение в другом месте. По словам компании, Аарон Ричман и Дэйв Винсент показывали эти четыре сценария на недавней сессии.
Для российских и русскоязычных команд вывод приземлённый: миграция с VMware — это не только таблица совместимости гипервизора и не только вопрос стоимости лицензий. Нужно заранее проверить, поддерживает ли выбранная backup-система старую и новую платформу, как будут восстанавливаться критичные VM, где проходит граница отказоустойчивости продакшена и где лежит независимая копия вне домена отказа. Иначе выход из VMware рискует превратиться в дорогой способ сохранить прежнюю архитектурную хрупкость на новом логотипе.
Следующий спор на рынке виртуализации, похоже, будет не о том, какой гипервизор дешевле. Главный вопрос жёстче: сколько защиты должна уметь сама производственная платформа, а сколько нужно оставлять независимому backup-слою, чтобы в день настоящей аварии инфраструктура не требовала героизма от всей команды сразу.