В офисном редакторе автосохранение включается одним переключателем. Последние полгода почти каждый разговор о смене платформы виртуализации заканчивается одним и тем же вопросом: «а где у нас такой же переключатель для всего ЦОД?» Его нет. Есть лестница механизмов, и каждая ступень закрывает свой класс проблем.
Путаница начинается со слов. Снапшот называют бэкапом, репликацию называют защитой от шифровальщика, вторую площадку — резервным копированием. Каждое из этих слов верно наполовину. И каждая половина всплывает в самый неудобный момент: при аудите, при сбое обновления или при атаке.
Этот выпуск — попытка разложить лестницу целиком: от клона виртуальной машины перед рискованной операцией до копии в S3 у локального оператора ЦОД. Отдельно разбираем, что из этого входит в лицензию платформы, а что докупается, на примере Nutanix — по актуальным на начало октября 2026 года версиям NCI 7.5–7.6.
Карта угроз
Каждая ступень отвечает на свой вопрос
Матрица «механизм × угроза» быстро показывает, где защита есть, а где она только кажется.
Первое, что стоит сделать до выбора продукта, — выписать угрозы, от которых нужно защититься. Их немного: ошибка администратора или сбой обновления, отказ узла или всего кластера, потеря площадки, шифровальщик с правами администратора, требование аудитора или регулятора хранить копии долго и доказуемо.
Дальше каждый механизм проверяется по этой матрице. Вывод обычно неприятный: ни одна ступень не закрывает все угрозы, а самые дорогие из них закрывают как раз не ту, которой боятся больше всего.
Синхронная репликация на вторую площадку — самый дорогой механизм в лестнице. От шифровальщика она не защищает никак: она добросовестно и без задержки передаёт на резервную площадку уже зашифрованные блоки. От ошибки администратора тоже: удалённая таблица удаляется на обеих площадках одновременно.
Поэтому правильный вопрос звучит не «какой DR выбрать», а «какими двумя-тремя ступенями мы закрываем каждую строку матрицы». Одна ступень на всё — это не архитектура, а надежда.
Первая линия
Клон перед операцией и локальный снапшот
Откат за минуты вместо часов, но только пока жив сам кластер.
Самая дешёвая ступень и самая недооценённая. Перед обновлением прикладного софта, миграцией базы или сменой версии драйверов делается клон или снапшот, и откат занимает минуты, а не часы.
Эта ступень входит в базовую лицензию. У Nutanix снапшоты и клоны ВМ, включая application-consistent, есть во всех редакциях, начиная со Starter, а в Pro добавляется самостоятельное восстановление файлов пользователем.
Ограничение у этой ступени одно, но принципиальное: снапшот живёт на том же кластере, что и сама машина. Отказ кластера уносит и данные, и все их точки восстановления. Поэтому снапшот — это не резервная копия, как бы часто его ни снимали.
Вторая грабля — эксплуатационная. Снапшот, который забыли удалить после обновления, через полгода превращается в цепочку, которая съедает ёмкость и мешает производительности. Правило простое: у каждого ручного снапшота есть срок жизни, и он записан в регламенте работ.
Вторая площадка
Равнозначная площадка: Async, NearSync, Metro
Копия по расписанию, короткий интервал или синхронная запись: у каждого режима своя цена в канале и в бюджете.
Следующая ступень — копия на второй кластер, способный поднять нагрузку. Здесь три режима, и они различаются не только RPO, но и тем, что требуют от канала и от бюджета.
Асинхронная репликация передаёт снапшоты по расписанию. В базовой редакции Nutanix шаг — от 1 часа. Канал нужен под объём изменений за интервал, задержка между площадками почти не важна. Это рабочая лошадка для большинства систем.
NearSync сокращает интервал до 1–15 минут за счёт облегчённых снапшотов. Для систем, где час потерянных транзакций неприемлем, а синхронная схема не проходит по расстоянию, это обычно правильный компромисс.
Metro — синхронная запись на обе площадки, RPO равен нулю. Цена этого нуля: каждая операция записи ждёт подтверждения с удалённой стороны, поэтому схема работает только при малой задержке, то есть на небольших расстояниях. Про развилку «50 км против 600» подробно писали в выпуске про аренду и собственную инфраструктуру. Автоматическое переключение в Metro возможно только со свидетелем на третьей площадке, иначе при разрыве связи система не отличит отказ площадки от отказа канала.
И общая оговорка для всей ступени: вторая площадка — это вторая инфраструктура. Узлы, лицензии на их ядра, место в стойке, питание. Стоит она почти столько же, сколько первая, а работает в основном в режиме ожидания.
Редакции Nutanix
Что входит в лицензию, а что докупается
Pro, Advanced Replication и Ultimate: что открывает каждая ступень и по каким ядрам она считается.
Лестница есть не только в механизмах, но и в лицензиях. Ошибка, которую мы видим регулярно, — выбирать редакцию по названию, а не по сценарию.
Ступеней три. В NCI Pro входят асинхронная репликация с RPO от 1 часа, DR на несколько площадок, базовые планы восстановления и снапшоты в объектное хранилище. Add-on Advanced Replication (в прайсе — Advanced Disaster Recovery) к Pro открывает Metro, синхронную репликацию, NearSync, расширенную оркестрацию и живую миграцию между кластерами. В NCI Ultimate всё это уже включено, плюс микросегментация. Ниже Pro есть ещё Starter с асинхронной репликацией на одну площадку, но это редакция для небольших гибридных кластеров.
Что из этого следует на практике. Если системе нужен RPO меньше часа или ноль, это сразу add-on, на Pro такой схемы не построить. Тестовое переключение, запуск по этапам со скриптами и сменой адресов относятся к расширенной оркестрации, и об этом стоит помнить, когда дойдёт до аудита. А вот снапшоты в объектное хранилище и clean room на их основе доступны уже в Pro.
Ошибка, которую мы видим регулярно, — выбирать редакцию по названию, а не по сценарию.
Отдельно про метрику. Лицензия NCI и add-on считаются по ядрам кластера целиком: если NearSync нужен трём машинам, add-on всё равно покупается на все ядра кластера, где они живут. Площадки DR лицензируются отдельно, по ядрам своих кластеров. Поэтому критичные системы выгоднее держать в отдельном кластере, а не размазывать по общему. Про то, как лицензионный периметр незаметно расползается, писали в выпуске про СРК.
Состав редакций дан по официальным материалам Nutanix на начало октября 2026 года. Он меняется чаще, чем цикл закупки, поэтому на дату конкурса его стоит перепроверить.
DR под аудит
Что видно на резервной площадке
Штатное поведение платформы, которое на аудите выглядит как проблема.
Один из самых частых вопросов по DR задают не инженеры, а аудиторы. И он звучит просто: «покажите».
Недавний случай. У заказчика две площадки на Nutanix с асинхронной репликацией через Recovery Plans. Архитектор заказчика открыл список ВМ на резервной площадке, не нашёл там защищённых машин и всерьёз забеспокоился: как это объяснить аудиту. Наше участие здесь было консультационным — разобрать поведение платформы и подготовить доказательную базу, настройку делала команда заказчика.
Поведение, на самом деле, штатное. На резервной площадке лежат не машины, а точки восстановления. Машина появляется в списке только при переключении или тестовом переключении. Это не дефект, а принцип: пока площадка резервная, в её инвентаре нечему занимать ресурсы.
Но аудитору от этого не легче. Ему нужны не принципы, а артефакты. Что имеет смысл показывать: список точек восстановления по каждой защищаемой системе с их возрастом, отчёт о соблюдении RPO за период, план восстановления с порядком запуска и, главное, протокол регулярного тестового переключения с фактическим временем подъёма.
Отдельная деталь, которую стоит проверить на своей версии и своей лицензии: в описании add-on Advanced Replication тестовое переключение указано в составе расширенной оркестрации. Если аудит требует регулярных тестов, это аргумент в пользу грейда выше базового.
Хранение и проверка
Архивный кластер без пуска
Копии вне основного кластера без постоянных вычислительных узлов: дёшево, но с оговорками.
Не каждой системе нужна вторая площадка, готовая принять нагрузку. Для многих достаточно, чтобы копии лежали вне основного кластера, их можно было проверить и при необходимости поднять — пусть не за минуты.
У Nutanix для этого есть Multicloud Snapshot Technology, она входит в Pro и Ultimate без доплаты. Снапшоты хранятся в S3-совместимом хранилище, в том числе в Nutanix Objects, а восстановить их можно на любом кластере платформы. В схеме zero compute постоянный второй кластер не нужен: целевой кластер поднимается по требованию, в том числе в облаке.
Долгое время слабым местом был подъём: данные сначала вытягивались из объектного хранилища на кластер, и для крупных машин это были часы. В NCI 7.5.1 вышел Instant Restore: машина включается, как только на кластер загружены метаданные снапшота, а данные догружаются в фоне.
Но у этой ступени есть оговорка, которую легко пропустить: неизменяемость. Официального подтверждения, что MST работает с объектной блокировкой на бакете, у Nutanix нет, а один из сертифицированных провайдеров хранилища прямо запрещает её включать. Пока не доказано обратное, это дешёвый и удобный слой, но не неизменяемый. На этой же технологии Nutanix строит clean room — изолированную среду восстановления, которая поднимается по требованию.
Второй вариант — недорогой гибридный кластер, хотя бы на NCI Starter с NVMe или SSD плюс HDD. Он может быть и целью асинхронной репликации, и хранилищем, куда пишет условный Commvault. Для роли точки восстановления этого достаточно, а вот запускать на нём всю продуктивную нагрузку после аварии мы бы не стали. И для любого варианта: хранение без регулярной проверки восстановления — не защита, а надежда.
Резервное копирование
Горячий и тёплый слой: NVMe и HDD
Хранилище копий оценивают по тому, как быстро из него поднимаются, а не по тому, сколько в него помещается.
Здесь заканчивается территория платформы виртуализации и начинается резервное копирование в привычном смысле: отдельный софт, отдельное хранилище, отдельные учётные записи. Логика одинакова для любого зрелого продукта резервного копирования, примеры мы приводим на Commvault.
Главный параметр хранилища резервных копий — не ёмкость, а скорость восстановления. Ёмкость считают все, скорость восстановления почти никто. А в день инцидента руководство спрашивает не «сколько у нас копий», а «когда заработает».
А в день инцидента руководство спрашивает не «сколько у нас копий», а «когда заработает».
Горячий слой на NVMe нужен там, где восстанавливать приходится много и быстро. Недавно мы считали цель резервного копирования на несколько петабайт физической ёмкости на площадку, с требованием к восстановлению в сотни терабайт в час. На таком масштабе дедупликация уже не выручает: данные приходят от Commvault сжатыми, и хранилище приходится считать по физической ёмкости. Про то, как коэффициент сокращения тает на сжатых и шифрованных данных, подробно писали в выпуске про СРК.
Тёплый слой на HDD дешевле за терабайт и отлично подходит для точек восстановления старше нескольких дней, которые поднимают редко. Нормальная схема — не выбор между слоями, а их сочетание: свежие копии на быстром слое, старые переезжают на медленный по политике.
Физический разрыв
Лента: холодный слой
Архаизм, который до сих пор даёт то, чего нет у онлайн-носителей.
Лента выглядит архаизмом до тех пор, пока не посчитаешь стоимость хранения петабайта на десять лет и не вспомнишь, что картридж на полке физически недоступен по сети. Такой изоляции не даёт ни один онлайн-носитель.
Цена этой изоляции — время. Восстановление с ленты — это часы и дни, а не минуты, и оно упирается в количество приводов. Поэтому лента — слой для долгого хранения и для сценария «всё остальное уже скомпрометировано», а не для оперативного восстановления.
Сейчас на столе у нас задача обратного направления: крупная библиотека на два десятка приводов и несколько сотен картриджей, заказчик хочет полностью уйти на флеш. Аргументы понятны: скорость, плотность, отказ от механики. Но первым задаём вопрос: что в новой схеме заменит физический разрыв. Если ответа нет, ленту стоит оставить хотя бы для самого долгого хранения.
Защита от шифровальщика
Immutable и апплайнсы
Копию, которую может удалить администратор, может удалить и тот, кто украл его учётную запись.
Современный шифровальщик сначала ищет резервные копии и только потом шифрует основные данные. Поэтому неизменяемость копий — уже не опция, а базовое требование.
Механизмов три. Защищённый Linux-репозиторий, где у сервиса резервного копирования нет прав на удаление. Объектная блокировка S3, которая запрещает удаление до истечения срока хранения. Блокировка хранилища на стороне Commvault. У всех один принцип: срок хранения задаётся при записи, и до его истечения копию не может удалить никто, включая администратора резервного копирования.
Неизменяемость не отменяет разделения учётных записей. Если хранилище копий, консоль резервного копирования и основная инфраструктура сидят в одном домене с одними администраторами, злоумышленнику достаточно одной учётной записи.
Про готовые решения. HyperScale X у Commvault хорош тем, что поставляется уже защищённым и не требует собирать и укреплять репозиторий вручную.
S3 в Узбекистане
Бэкап в локальное облако
Закон о локализации в редакции 2026 года, модель размещения и арифметика канала.
Вишенка на торте — копия за пределами собственной инфраструктуры. Для Средней Азии это почти всегда локальное облако, и причина не только техническая.
С 2021 года статья 27-1 Закона о персональных данных требовала хранить персональные данные граждан на технических средствах внутри страны. В марте 2026 года закон смягчили: обязательной локализация осталась для биометрических и генетических данных и для данных абонентов телеком-операторов. Остальные можно хранить за рубежом при адекватной защите в стране хранения, утверждённых договорных условиях или международных стандартах. Для банков к этому добавляются требования отраслевого регулятора, их стоит проверять отдельно. Так что зарубежное облако перестало быть запретом по умолчанию, но для телекома и биометрии вопрос по-прежнему закрыт.
Для локальной копии остаются два варианта. Первый — собственное объектное хранилище в арендованной стойке у оператора ЦОД: железо и софт свои, площадка чужая. Второй — S3 как услуга от самого оператора. Второй быстрее запускается, первый даёт больше контроля.
Что проверять в обоих случаях: поддерживается ли объектная блокировка, где физически лежат данные и кто имеет к ним административный доступ, на каких условиях можно забрать данные при выходе из договора.
И арифметика канала, которую почему-то делают последней. Первая полная копия на 100 TB по каналу 1 Gbit/s при полной загрузке идёт больше 9 суток, при реальных 70% — около двух недель. На 10 Gbit/s — от 22 часов до полутора суток. Восстановление из облака подчиняется той же арифметике, только в день инцидента ждать две недели уже никто не будет. Поэтому облачная копия — это последняя ступень лестницы, а не первая линия восстановления.
Чек-лист
Что проверить до выбора схемы
Двенадцать вопросов, которые стоит задать до выбора продуктов и редакций.
Итог
Вместо вывода
Переключателя «Autosave mode=ON» для ЦОД не существует. Есть лестница от клона до облака, и каждая ступень закрывает свою часть рисков за свою цену.
Ошибка, которую мы видим чаще всего, — купить самую дорогую ступень и считать вопрос закрытым. Метро-кластер без неизменяемой копии рядом защищает от пожара, но не от шифровальщика и не от своего администратора.
Если вы выбираете платформу или пересматриваете защиту данных, давайте разложим лестницу под ваши системы: какие угрозы реальны, какие ступени уже есть и что покрыто лицензией.