Autosave mode=ON — tenitskiy.net

В офисном редакторе автосохранение включается одним переключателем. Последние полгода почти каждый разговор о смене платформы виртуализации заканчивается одним и тем же вопросом: «а где у нас такой же переключатель для всего ЦОД?» Его нет. Есть лестница механизмов, и каждая ступень закрывает свой класс проблем.

В офісному редакторі автозбереження вмикається одним перемикачем. Останні півроку майже кожна розмова про зміну платформи віртуалізації закінчується одним і тим самим питанням: «а де в нас такий самий перемикач для всього ЦОД?» Його немає. Є драбина механізмів, і кожен щабель закриває свій клас проблем.

In an office editor, autosave is one switch. For the past six months almost every conversation about changing virtualisation platforms has ended with the same question: “where is the same switch for the whole data centre?” There is none. There is a ladder of mechanisms, and each rung covers its own class of problems.

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

Плутанина починається зі слів. Снапшот називають бекапом, реплікацію називають захистом від шифрувальника, другий майданчик — резервним копіюванням. Кожне з цих слів вірне наполовину. І кожна половина спливає в найнезручніший момент: під час аудиту, під час збою оновлення або під час атаки.

The confusion starts with the words. A snapshot gets called a backup, replication gets called ransomware protection, and a second site gets called backup. Each of those words is half true. And each half surfaces at the least convenient moment: during an audit, during a failed update, or during an attack.

Этот выпуск — попытка разложить лестницу целиком: от клона виртуальной машины перед рискованной операцией до копии в объектном хранилище у локального оператора ЦОД. Отдельно разбираю, что из этого входит в лицензию платформы, а что докупается, на примере Nutanix — по актуальным на начало октября 2026 года версиям NCI 7.5–7.6.

Цей випуск — спроба розкласти драбину цілком: від клона віртуальної машини перед ризикованою операцією до копії в об’єктному сховищі в локального оператора ЦОД. Окремо розбираю, що з цього входить у ліцензію платформи, а що докуповується, на прикладі Nutanix — за актуальними на початок жовтня 2026 року версіями NCI 7.5–7.6.

This issue tries to lay out the whole ladder: from cloning a virtual machine before a risky operation to a copy in object storage at a local data-centre operator. Separately, which of it the platform licence covers and which has to be bought on top — using Nutanix as the example, against NCI 7.5–7.6 as of early October 2026.

Карта угрозКарта загрозThe threat map

Каждая ступень отвечает на свой вопрос

Кожен щабель відповідає на своє питання

Each rung answers its own question

Матрица «механизм × угроза» быстро показывает, где защита есть, а где она только кажется.

Матриця «механізм × загроза» швидко показує, де захист є, а де він лише здається.

A mechanism-by-threat matrix shows quickly where protection exists and where it only looks like it does.

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

Перше, що варто зробити до вибору продукту, — виписати загрози, від яких треба захиститися. Їх небагато: помилка адміністратора або збій оновлення, відмова вузла або всього кластера, втрата майданчика, шифрувальник із правами адміністратора, вимога аудитора або регулятора зберігати копії довго і доказово.

The first thing to do before choosing a product is to write out the threats you need protection from. There are not many: an administrator error or a failed update, the loss of a node or of a whole cluster, the loss of a site, ransomware with administrative rights, and an auditor’s or regulator’s requirement to keep copies for a long time and provably.

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

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

Then each mechanism is checked against that matrix. The conclusion is usually unwelcome: no rung covers every threat, and the most expensive ones cover precisely the threat people fear least.

Ступени защиты данных и угрозы, которые они закрываютЩаблі захисту даних і загрози, які вони закриваютьThe rungs of data protection and the threats each one covers

Ни одна ступень не закрывает все угрозы, а самые дорогие закрывают как раз не ту, которой боятся больше всего.Жоден щабель не закриває всі загрози, а найдорожчі закривають якраз не ту, якої бояться найбільше.No single rung covers every threat, and the most expensive ones cover precisely the threat people fear least.

	Ошибка администратораПомилка адміністратораAdministrator error	Отказ узла или кластераВідмова вузла або кластераNode or cluster failure	Потеря площадкиВтрата майданчикаLoss of a site	ШифровальщикШифрувальникRansomware	Долгое доказуемое хранениеДовге доказове зберіганняLong, provable retention
Клон и локальный снапшотКлон і локальний снапшотClone and local snapshot
Асинхронная репликация на вторую площадкуАсинхронна реплікація на другий майданчикAsynchronous replication to a second site
Синхронная репликация, метрокластерСинхронна реплікація, метрокластерSynchronous replication, metro cluster
Снапшоты в объектное хранилищеСнапшоти в об’єктне сховищеSnapshots to object storage
Резервное копирование отдельным продуктомРезервне копіювання окремим продуктомBackup by a separate product
Неизменяемый репозиторий и объектная блокировкаНезмінний репозиторій та об’єктне блокуванняImmutable repository and object lock
Лента на полкеСтрічка на полиціTape on a shelf

закрываетзакриваєcovers it закрывает частичнозакриває частковоcovers it in part не закрываетне закриваєdoes not cover it

Рис.Рис.Fig. 1 Синхронная репликация добросовестно и без задержки передаёт на резервную площадку уже зашифрованные блоки. Удалённая таблица удаляется на обеих площадках одновременно.Синхронна реплікація сумлінно і без затримки передає на резервний майданчик уже зашифровані блоки. Видалена таблиця видаляється на обох майданчиках одночасно.Synchronous replication faithfully and instantly delivers already-encrypted blocks to the standby site. A deleted table is deleted on both sites at once.

Синхронная репликация на вторую площадку — самый дорогой механизм в лестнице. От шифровальщика она не защищает никак: она добросовестно и без задержки передаёт на резервную площадку уже зашифрованные блоки. От ошибки администратора тоже: удалённая таблица удаляется на обеих площадках одновременно.

Синхронна реплікація на другий майданчик — найдорожчий механізм у драбині. Від шифрувальника вона не захищає ніяк: вона сумлінно і без затримки передає на резервний майданчик уже зашифровані блоки. Від помилки адміністратора теж: видалена таблиця видаляється на обох майданчиках одночасно.

Synchronous replication to a second site is the most expensive mechanism on the ladder. Against ransomware it protects not at all: it faithfully and instantly delivers already-encrypted blocks to the standby site. Against an administrator error, likewise: a deleted table is deleted on both sites at once.

Поэтому правильный вопрос звучит не «какой режим аварийного восстановления выбрать», а «какими двумя-тремя ступенями мы закрываем каждую строку матрицы». Одна ступень на всё — это не архитектура, а надежда.

Тому правильне питання звучить не «який режим аварійного відновлення обрати», а «якими двома-трьома щаблями ми закриваємо кожен рядок матриці». Один щабель на все — це не архітектура, а надія.

So the right question is not “which disaster-recovery mode should we choose” but “which two or three rungs cover each row of the matrix”. One rung for everything is not an architecture; it is a hope.

Первая линияПерша лініяThe first line

Клон перед операцией и локальный снапшот

Клон перед операцією і локальний снапшот

A clone before the operation, and a local snapshot

Откат за минуты вместо часов, но только пока жив сам кластер.

Відкат за хвилини замість годин, але лише поки живий сам кластер.

A rollback in minutes instead of hours — but only while the cluster itself is alive.

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

Найдешевший щабель і найбільш недооцінений. Перед оновленням прикладного софту, міграцією бази або зміною версії драйверів робиться клон або снапшот, і відкат займає хвилини, а не години.

The cheapest rung and the most underrated. Before an application update, a database migration or a driver version change you take a clone or a snapshot, and the rollback takes minutes rather than hours.

Эта ступень входит в базовую лицензию. У Nutanix снапшоты и клоны виртуальных машин, включая согласованные с приложением, есть во всех редакциях, начиная со Starter, а в Pro добавляется самостоятельное восстановление файлов пользователем.

Цей щабель входить у базову ліцензію. У Nutanix снапшоти і клони віртуальних машин, зокрема узгоджені із застосунком, є в усіх редакціях, починаючи зі Starter, а в Pro додається самостійне відновлення файлів користувачем.

This rung is part of the base licence. In Nutanix, VM snapshots and clones — including application-consistent ones — are present in every edition from Starter upward, and Pro adds user self-service file restore.

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

Обмеження в цього щабля одне, але принципове: снапшот живе на тому самому кластері, що й сама машина. Відмова кластера забирає і дані, і всі їхні точки відновлення. Тому снапшот — це не резервна копія, хоч би як часто його знімали.

This rung has one limitation, but a fundamental one: the snapshot lives on the same cluster as the machine itself. A cluster failure takes both the data and all of its recovery points. Which is why a snapshot is not a backup, however often it is taken.

Вторая грабля — эксплуатационная. Снапшот, который забыли удалить после обновления, через полгода превращается в цепочку, которая съедает ёмкость и мешает производительности. Правило простое: у каждого ручного снапшота есть срок жизни, и он записан в регламенте работ.

Друга граблина — експлуатаційна. Снапшот, який забули видалити після оновлення, за півроку перетворюється на ланцюжок, що з’їдає ємність і заважає продуктивності. Правило просте: у кожного ручного снапшота є строк життя, і він записаний у регламенті робіт.

The second trap is operational. A snapshot nobody deleted after an update turns, six months on, into a chain that eats capacity and drags on performance. The rule is simple: every manual snapshot has a lifetime, and it is written into the work procedure.

Вторая площадкаДругий майданчикThe second site

Равнозначная площадка: по расписанию, с коротким интервалом или синхронно

Рівнозначний майданчик: за розкладом, з коротким інтервалом або синхронно

An equal site: on a schedule, at a short interval, or synchronously

Копия по расписанию, короткий интервал или синхронная запись: у каждого режима своя цена в канале и в бюджете.

Копія за розкладом, короткий інтервал або синхронний запис: у кожного режиму своя ціна в каналі і в бюджеті.

A scheduled copy, a short interval or synchronous writes: each mode has its own price in bandwidth and in budget.

Следующая ступень — копия на второй кластер, способный поднять нагрузку. Здесь три режима, и они различаются не только точкой восстановления, но и тем, что требуют от канала и от бюджета.

Наступний щабель — копія на другий кластер, здатний підняти навантаження. Тут три режими, і вони відрізняються не лише точкою відновлення, а й тим, що вимагають від каналу і від бюджету.

The next rung is a copy on a second cluster capable of taking the load. There are three modes here, and they differ not only in recovery point but in what they demand of the link and of the budget.

Ориентировочные диапазоны точки восстановления и времени подъёма по ступенямОрієнтовні діапазони точки відновлення і часу підйому за щаблямиIndicative recovery-point and start-up ranges by rung

Каждый режим различается не только точкой восстановления, но и тем, что требует от канала и от бюджета.Кожен режим відрізняється не лише точкою відновлення, а й тим, що вимагає від каналу і від бюджету.The modes differ not only in recovery point but in what they demand of the link and of the budget.

СтупеньЩабельRung	Точка восстановленияТочка відновленняRecovery point	Время подъёмаЧас підйомуTime to start up	Чего требуетЧого вимагаєWhat it demands
Клон или локальный снапшотКлон або локальний снапшотClone or local snapshot	момент снятиямомент зняттяthe moment it was taken	минутыхвилиниminutes	ничего сверх кластера — и умирает вместе с нимнічого понад кластер — і вмирає разом із нимnothing beyond the cluster — and dies with it
Асинхронная репликацияАсинхронна реплікаціяAsynchronous replication	от 1 часавід 1 годиниfrom 1 hour	десятки минутдесятки хвилинtens of minutes	канал под объём изменений за интервалканал під обсяг змін за інтервалa link sized for the changes in the interval
Репликация с коротким интерваломРеплікація з коротким інтерваломShort-interval replication	1–15 минут1–15 хвилин1–15 minutes	десятки минутдесятки хвилинtens of minutes	облегчённые снапшоты и лицензионный add-onполегшені снапшоти і ліцензійний add-onlightweight snapshots and a licence add-on
Синхронная запись, метрокластерСинхронний запис, метрокластерSynchronous writes, metro cluster	нольнульzero	минуты или без простояхвилини або без простоюminutes, or no outage at all	малая задержка, свидетель на третьей площадкемала затримка, свідок на третьому майданчикуlow latency and a witness on a third site
Копия в объектном хранилищеКопія в об’єктному сховищіA copy in object storage	сутки и режедоба і рідшеa day or more	от десятков минут до часоввід десятків хвилин до годинtens of minutes to hours	целевой кластер по требованиюцільовий кластер на вимогуa target cluster brought up on demand
ЛентаСтрічкаTape	сутки и режедоба і рідшеa day or more	часы и днигодини і дніhours and days	приводы, и их число определяет скоростьприводи, і їхня кількість визначає швидкістьdrives — and their number sets the speed

Рис.Рис.Fig. 2 Снапшот живёт на том же кластере, что и машина. Отказ кластера уносит и данные, и все их точки восстановления.Снапшот живе на тому самому кластері, що й машина. Відмова кластера забирає і дані, і всі їхні точки відновлення.A snapshot lives on the same cluster as the machine. A cluster failure takes the data and every one of its recovery points with it.

Асинхронная репликация передаёт снапшоты по расписанию. В базовой редакции Nutanix шаг — от 1 часа. Канал нужен под объём изменений за интервал, задержка между площадками почти не важна. Это рабочая лошадка для большинства систем.

Асинхронна реплікація передає снапшоти за розкладом. У базовій редакції Nutanix крок — від 1 години. Канал потрібен під обсяг змін за інтервал, затримка між майданчиками майже не важлива. Це робоча конячка для більшості систем.

Asynchronous replication sends snapshots on a schedule. In the base Nutanix edition the interval starts at one hour. The link has to carry the volume of changes in that interval, and latency between the sites barely matters. This is the workhorse for most systems.

Короткий интервал — от 1 до 15 минут за счёт облегчённых снапшотов. Для систем, где час потерянных транзакций неприемлем, а синхронная схема не проходит по расстоянию, это обычно правильный компромисс.

Короткий інтервал — від 1 до 15 хвилин за рахунок полегшених снапшотів. Для систем, де година втрачених транзакцій неприйнятна, а синхронна схема не проходить за відстанню, це зазвичай правильний компроміс.

The short interval runs from 1 to 15 minutes, using lightweight snapshots. For systems where an hour of lost transactions is unacceptable but a synchronous design does not fit the distance, this is usually the right compromise.

Синхронная запись на обе площадки даёт нулевую точку восстановления. Цена этого нуля: каждая операция записи ждёт подтверждения с удалённой стороны, поэтому схема работает только при малой задержке, то есть на небольших расстояниях. Про развилку «50 км против 600» подробно писал в выпуске 07 «Четыре контура». Автоматическое переключение возможно только со свидетелем на третьей площадке, иначе при разрыве связи система не отличит отказ площадки от отказа канала.

Синхронний запис на обидва майданчики дає нульову точку відновлення. Ціна цього нуля: кожна операція запису чекає підтвердження з віддаленого боку, тому схема працює лише за малої затримки, тобто на невеликих відстанях. Про розвилку «50 км проти 600» докладно писав у випуску 07 «Чотири контури». Автоматичне перемикання можливе лише зі свідком на третьому майданчику, інакше при розриві зв’язку система не відрізнить відмову майданчика від відмови каналу.

Synchronous writes to both sites give a zero recovery point. The price of that zero: every write waits for acknowledgement from the far side, so the design only works at low latency, which means short distances. I covered the 50 km versus 600 km fork in detail in issue 07, “Four environments”. Automatic failover is possible only with a witness on a third site; otherwise, when the link breaks, the system cannot tell a site failure from a link failure.

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

І загальне застереження для всього щабля: другий майданчик — це друга інфраструктура. Вузли, ліцензії на їхні ядра, місце у стійці, живлення. Коштує він майже стільки ж, скільки перший, а працює здебільшого в режимі очікування.

And a caveat for the whole rung: a second site is a second infrastructure. Nodes, licences for their cores, rack space, power. It costs almost as much as the first one and spends most of its time waiting.

РедакцииРедакціїEditions

Что входит в лицензию, а что докупается

Що входить у ліцензію, а що докуповується

What the licence covers and what you buy on top

Pro, дополнение на расширенную репликацию и Ultimate: что открывает каждая ступень и по каким ядрам она считается.

Pro, доповнення на розширену реплікацію і Ultimate: що відкриває кожен щабель і за якими ядрами він рахується.

Pro, the advanced-replication add-on and Ultimate: what each rung unlocks and which cores it is counted against.

Лестница есть не только в механизмах, но и в лицензиях. Ошибка, которую вижу регулярно, — выбирать редакцию по названию, а не по сценарию.

Драбина є не лише в механізмах, а й у ліцензіях. Помилка, яку бачу регулярно, — обирати редакцію за назвою, а не за сценарієм.

There is a ladder in the licensing too, not just in the mechanisms. A mistake I see regularly is choosing an edition by its name rather than by the scenario.

Редакции платформы в части аварийного восстановления: базовая поставка и дополнениеРедакції платформи в частині аварійного відновлення: базова поставка і доповненняPlatform editions for disaster recovery: what ships in the base and what is an add-on

Состав редакций Nutanix дан по официальным материалам на начало октября 2026 года — он меняется чаще, чем цикл закупки.Склад редакцій Nutanix подано за офіційними матеріалами на початок жовтня 2026 року — він змінюється частіше, ніж цикл закупівлі.The Nutanix edition contents are taken from official materials as of early October 2026 — they change more often than a procurement cycle.

	StarterStarterStarter	ProProPro	Pro + Advanced ReplicationPro + Advanced ReplicationPro + Advanced Replication	UltimateUltimateUltimate
Снапшоты и клоны, в том числе согласованные с приложениемСнапшоти і клони, зокрема узгоджені із застосункомSnapshots and clones, including application-consistent
Самостоятельное восстановление файлов пользователемСамостійне відновлення файлів користувачемUser self-service file restore
Асинхронная репликация на одну площадкуАсинхронна реплікація на один майданчикAsynchronous replication to one site
Репликация на несколько площадок и базовые планы восстановленияРеплікація на кілька майданчиків і базові плани відновленняReplication to several sites and basic recovery plans
Снапшоты в объектное хранилищеСнапшоти в об’єктне сховищеSnapshots to object storage
Репликация с коротким интервалом (NearSync)Реплікація з коротким інтервалом (NearSync)Short-interval replication (NearSync)
Синхронная репликация и метрокластерСинхронна реплікація і метрокластерSynchronous replication and metro clustering
Расширенная оркестрация и тестовое переключениеРозширена оркестрація і тестове перемиканняAdvanced orchestration and test failover
Живая миграция между кластерамиЖива міграція між кластерамиLive migration between clusters
МикросегментацияМікросегментаціяMicrosegmentation

входитвходитьincluded не входитне входитьnot included

Рис.Рис.Fig. 3 Лицензия и дополнение считаются по ядрам кластера целиком: если короткий интервал нужен трём машинам, дополнение всё равно покупается на все ядра кластера, где они живут.Ліцензія і доповнення рахуються за ядрами кластера цілком: якщо короткий інтервал потрібен трьом машинам, доповнення однаково купується на всі ядра кластера, де вони живуть.The licence and the add-on are counted across the whole cluster’s cores: if three machines need the short interval, the add-on is still bought for every core of the cluster they live on.

Ступеней три. В NCI Pro входят асинхронная репликация с точкой восстановления от 1 часа, восстановление на несколько площадок, базовые планы восстановления и снапшоты в объектное хранилище. Дополнение Advanced Replication (в прайсе — Advanced Disaster Recovery) к Pro открывает метрокластер, синхронную репликацию, короткий интервал, расширенную оркестрацию и живую миграцию между кластерами. В NCI Ultimate всё это уже включено, плюс микросегментация. Ниже Pro есть ещё Starter с асинхронной репликацией на одну площадку, но это редакция для небольших гибридных кластеров.

Щаблів три. У NCI Pro входять асинхронна реплікація з точкою відновлення від 1 години, відновлення на кілька майданчиків, базові плани відновлення і снапшоти в об’єктне сховище. Доповнення Advanced Replication (у прайсі — Advanced Disaster Recovery) до Pro відкриває метрокластер, синхронну реплікацію, короткий інтервал, розширену оркестрацію і живу міграцію між кластерами. У NCI Ultimate усе це вже включено, плюс мікросегментація. Нижче Pro є ще Starter з асинхронною реплікацією на один майданчик, але це редакція для невеликих гібридних кластерів.

There are three rungs. NCI Pro includes asynchronous replication from a one-hour recovery point, recovery across several sites, basic recovery plans, and snapshots to object storage. The Advanced Replication add-on to Pro (listed in the price book as Advanced Disaster Recovery) unlocks metro clustering, synchronous replication, the short interval, advanced orchestration and live migration between clusters. NCI Ultimate includes all of that already, plus microsegmentation. Below Pro there is Starter, with asynchronous replication to a single site, but that edition is for small hybrid clusters.

Что из этого следует на практике. Если системе нужна точка восстановления меньше часа или ноль, это сразу дополнение, на Pro такой схемы не построить. Тестовое переключение, запуск по этапам со скриптами и сменой адресов относятся к расширенной оркестрации, и об этом стоит помнить, когда дойдёт до аудита. А вот снапшоты в объектное хранилище и изолированная среда восстановления на их основе доступны уже в Pro.

Що з цього випливає на практиці. Якщо системі потрібна точка відновлення менша за годину або нуль, це одразу доповнення, на Pro такої схеми не побудувати. Тестове перемикання, запуск за етапами зі скриптами і зміною адрес належать до розширеної оркестрації, і про це варто пам’ятати, коли дійде до аудиту. А ось снапшоти в об’єктне сховище та ізольоване середовище відновлення на їхній основі доступні вже в Pro.

What that means in practice. If a system needs a recovery point of less than an hour, or zero, that is the add-on immediately; such a design cannot be built on Pro. Test failover, staged start-up with scripts and address changes belong to advanced orchestration — worth remembering when the audit comes round. Snapshots to object storage and the isolated recovery environment built on them, though, are available in Pro already.

Ошибка, которую вижу регулярно, — выбирать редакцию по названию, а не по сценарию.

Помилка, яку бачу регулярно, — обирати редакцію за назвою, а не за сценарієм.

A mistake I see regularly is choosing an edition by its name rather than by the scenario.

Отдельно про метрику. Лицензия и дополнение считаются по ядрам кластера целиком: если короткий интервал нужен трём машинам, дополнение всё равно покупается на все ядра кластера, где они живут. Площадки восстановления лицензируются отдельно, по ядрам своих кластеров. Поэтому критичные системы выгоднее держать в отдельном кластере, а не размазывать по общему. Про то, как лицензионный периметр незаметно расползается, писал в выпуске 08 «Строки и ядра».

Окремо про метрику. Ліцензія і доповнення рахуються за ядрами кластера цілком: якщо короткий інтервал потрібен трьом машинам, доповнення однаково купується на всі ядра кластера, де вони живуть. Майданчики відновлення ліцензуються окремо, за ядрами своїх кластерів. Тому критичні системи вигідніше тримати в окремому кластері, а не розмазувати по спільному. Про те, як ліцензійний периметр непомітно розповзається, писав у випуску 08 «Рядки і ядра».

A separate word on the metric. The licence and the add-on are counted across the whole cluster’s cores: if three machines need the short interval, the add-on is still bought for every core of the cluster they live on. Recovery sites are licensed separately, against their own clusters’ cores. Which makes it cheaper to keep critical systems in a cluster of their own rather than spread across a shared one. On how a licensing perimeter quietly creeps outward, see issue 08, “Line items and cores”.

Состав редакций дан по официальным материалам Nutanix на начало октября 2026 года. Он меняется чаще, чем цикл закупки, поэтому на дату конкурса его стоит перепроверить.

Склад редакцій подано за офіційними матеріалами Nutanix на початок жовтня 2026 року. Він змінюється частіше, ніж цикл закупівлі, тому на дату конкурсу його варто перевірити.

The edition contents are taken from official Nutanix materials as of early October 2026. They change more often than a procurement cycle does, so they are worth rechecking on the date of the tender.

Аварийное восстановление под аудитАварійне відновлення під аудитDisaster recovery under audit

Что видно на резервной площадке

Що видно на резервному майданчику

What is visible on the standby site

Штатное поведение платформы, которое на аудите выглядит как проблема.

Штатна поведінка платформи, яка на аудиті виглядає як проблема.

Normal platform behaviour that looks like a defect during an audit.

Один из самых частых вопросов по аварийному восстановлению задают не инженеры, а аудиторы. И он звучит просто: «покажите».

Одне з найчастіших питань щодо аварійного відновлення ставлять не інженери, а аудитори. І воно звучить просто: «покажіть».

One of the commonest questions about disaster recovery comes not from engineers but from auditors. And it is a simple one: “show me”.

Недавний случай. У заказчика две площадки с асинхронной репликацией через планы восстановления. Архитектор заказчика открыл список виртуальных машин на резервной площадке, не нашёл там защищённых машин и всерьёз забеспокоился: как это объяснить аудиту. Моё участие здесь было консультационным — разобрать поведение платформы и подготовить доказательную базу, настройку делала команда заказчика.

Нещодавній випадок. У замовника два майданчики з асинхронною реплікацією через плани відновлення. Архітектор замовника відкрив список віртуальних машин на резервному майданчику, не знайшов там захищених машин і серйозно занепокоївся: як це пояснити аудиту. Моя участь тут була консультаційною — розібрати поведінку платформи і підготувати доказову базу, налаштування робила команда замовника.

A recent case. A customer has two sites with asynchronous replication through recovery plans. Their architect opened the VM list on the standby site, found none of the protected machines there and became seriously worried about how to explain it to the auditors. My involvement was advisory — to explain the platform’s behaviour and prepare the evidence; the configuration was done by the customer’s own team.

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

Поведінка насправді штатна. На резервному майданчику лежать не машини, а точки відновлення. Машина з’являється у списку лише при перемиканні або тестовому перемиканні. Це не дефект, а принцип: поки майданчик резервний, у його інвентарі нічому займати ресурси.

The behaviour is in fact normal. What sits on the standby site is not machines but recovery points. A machine appears in the list only at a failover or a test failover. This is not a defect but a principle: while the site is standby, there is nothing in its inventory to consume resources.

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

Але аудитору від цього не легше. Йому потрібні не принципи, а артефакти. Що має сенс показувати: список точок відновлення за кожною системою, що захищається, з їхнім віком, звіт про дотримання точки відновлення за період, план відновлення з порядком запуску і, головне, протокол регулярного тестового перемикання з фактичним часом підйому.

That is no comfort to the auditor, though. What they need is artefacts, not principles. What is worth showing: a list of recovery points for each protected system with their ages, a report on recovery-point compliance over a period, the recovery plan with its start-up order and, above all, the record of a regular test failover with the actual time it took to come up.

Отдельная деталь, которую стоит проверить на своей версии и своей лицензии: в описании дополнения Advanced Replication тестовое переключение указано в составе расширенной оркестрации. Если аудит требует регулярных тестов, это аргумент в пользу грейда выше базового.

Окрема деталь, яку варто перевірити на своїй версії та своїй ліцензії: в описі доповнення Advanced Replication тестове перемикання вказане у складі розширеної оркестрації. Якщо аудит вимагає регулярних тестів, це аргумент на користь рівня вище базового.

One detail worth checking against your own version and licence: in the description of the Advanced Replication add-on, test failover is listed as part of advanced orchestration. If the audit demands regular tests, that is an argument for a tier above the base one.

Хранение и проверкаЗберігання і перевіркаStorage and verification

Архивный кластер без пуска

Архівний кластер без пуску

An archive cluster with nothing running

Копии вне основного кластера без постоянных вычислительных узлов: дёшево, но с оговорками.

Копії поза основним кластером без постійних обчислювальних вузлів: дешево, але із застереженнями.

Copies outside the main cluster with no permanent compute nodes: cheap, with caveats.

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

Не кожній системі потрібен другий майданчик, готовий прийняти навантаження. Для багатьох достатньо, щоб копії лежали поза основним кластером, їх можна було перевірити і за потреби підняти — хай не за хвилини.

Not every system needs a second site ready to take the load. For many it is enough that the copies sit outside the main cluster, can be verified and, if needed, brought up — if not in minutes.

У Nutanix для этого есть Multicloud Snapshot Technology, она входит в Pro и Ultimate без доплаты. Снапшоты хранятся в объектном хранилище, совместимом с S3, в том числе в Nutanix Objects, а восстановить их можно на любом кластере платформы. В схеме без постоянных вычислительных узлов второй кластер не нужен: целевой поднимается по требованию, в том числе в облаке.

У Nutanix для цього є Multicloud Snapshot Technology, вона входить у Pro та Ultimate без доплати. Снапшоти зберігаються в об’єктному сховищі, сумісному з S3, зокрема в Nutanix Objects, а відновити їх можна на будь-якому кластері платформи. У схемі без постійних обчислювальних вузлів другий кластер не потрібен: цільовий піднімається на вимогу, зокрема в хмарі.

Nutanix has Multicloud Snapshot Technology for this, included in Pro and Ultimate at no extra cost. Snapshots are kept in S3-compatible object storage, including Nutanix Objects, and can be restored onto any cluster of the platform. In the zero-compute arrangement no permanent second cluster is needed: the target is brought up on demand, including in a cloud.

Долгое время слабым местом был подъём: данные сначала вытягивались из объектного хранилища на кластер, и для крупных машин это были часы. В NCI 7.5.1 вышел Instant Restore: машина включается, как только на кластер загружены метаданные снапшота, а данные догружаются в фоне.

Довгий час слабким місцем був підйом: дані спочатку витягувалися з об’єктного сховища на кластер, і для великих машин це були години. У NCI 7.5.1 вийшов Instant Restore: машина вмикається, щойно на кластер завантажено метадані снапшота, а дані довантажуються у фоні.

For a long time the weak point was starting up: the data was first pulled from object storage onto the cluster, and for large machines that meant hours. NCI 7.5.1 introduced Instant Restore: the machine powers on as soon as the snapshot metadata is loaded onto the cluster, with the data fetched in the background.

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

Але в цього щабля є застереження, яке легко пропустити: незмінність. Офіційного підтвердження, що технологія працює з об’єктним блокуванням на бакеті, у вендора немає, а один із сертифікованих провайдерів сховища прямо забороняє його вмикати. Поки не доведено протилежне, це дешевий і зручний шар, але не незмінний. На цій самій технології будується ізольоване середовище відновлення, яке піднімається на вимогу.

But this rung has a caveat that is easy to miss: immutability. The vendor has no official confirmation that the technology works with object lock on the bucket, and one certified storage provider expressly forbids enabling it. Until proven otherwise, this is a cheap and convenient tier, but not an immutable one. The same technology underpins the isolated recovery environment brought up on demand.

Второй вариант — недорогой гибридный кластер, хотя бы на младшей редакции с NVMe или SSD плюс HDD. Он может быть и целью асинхронной репликации, и хранилищем, куда пишет система резервного копирования. Для роли точки восстановления этого достаточно, а вот запускать на нём всю продуктивную нагрузку после аварии я бы не стал. И для любого варианта: хранение без регулярной проверки восстановления — не защита, а надежда.

Другий варіант — недорогий гібридний кластер, хоча б на молодшій редакції з NVMe або SSD плюс HDD. Він може бути і ціллю асинхронної реплікації, і сховищем, куди пише система резервного копіювання. Для ролі точки відновлення цього достатньо, а ось запускати на ньому все продуктивне навантаження після аварії я б не став. І для будь-якого варіанта: зберігання без регулярної перевірки відновлення — не захист, а надія.

The second option is an inexpensive hybrid cluster, even on a lower edition, with NVMe or SSD plus HDD. It can serve both as the target of asynchronous replication and as the repository the backup system writes to. For the role of a recovery point that is sufficient; running the entire production load on it after an outage is another matter, and I would not. And for either option: storage without regular restore testing is not protection but hope.

Резервное копированиеРезервне копіюванняBackup

Горячий и тёплый слой

Гарячий і теплий шар

The hot tier and the warm tier

Хранилище копий оценивают по тому, как быстро из него поднимаются, а не по тому, сколько в него помещается.

Сховище копій оцінюють за тим, як швидко з нього піднімаються, а не за тим, скільки в нього вміщується.

Backup storage is judged by how fast you come back up from it, not by how much fits into it.

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

Тут закінчується територія платформи віртуалізації і починається резервне копіювання у звичному сенсі: окремий софт, окреме сховище, окремі облікові записи. Логіка однакова для будь-якого зрілого продукту резервного копіювання, приклади наводжу на Commvault.

This is where the virtualisation platform’s territory ends and backup in the usual sense begins: separate software, separate storage, separate accounts. The logic is the same for any mature backup product; my examples use Commvault.

Слои хранения резервных копий: скорость, стоимость, изоляцияШари зберігання резервних копій: швидкість, вартість, ізоляціяBackup storage tiers: speed, cost, isolation

Главный параметр хранилища копий — не ёмкость, а скорость восстановления. Ёмкость считают все, скорость почти никто.Головний параметр сховища копій — не ємність, а швидкість відновлення. Ємність рахують усі, швидкість майже ніхто.The main parameter of backup storage is not capacity but restore speed. Everyone counts capacity; almost nobody counts speed.

Горячий слой на NVMeГарячий шар на NVMeHot tier on NVMe

Нужен там, где восстанавливать приходится много и быстроПотрібен там, де відновлювати доводиться багато і швидкоNeeded where restores are large and urgent
Требование в сотни терабайт в час считается именно здесьВимога в сотні терабайтів на годину рахується саме тутA hundreds-of-terabytes-per-hour target is met here
На больших объёмах дедупликация уже не выручает: данные приходят сжатымиНа великих обсягах дедуплікація вже не рятує: дані приходять стиснутимиAt scale deduplication no longer saves you: the data arrives compressed
Считать по физической ёмкости, а не по логическойРахувати за фізичною ємністю, а не за логічноюSize it by physical capacity, not logical

Тёплый слой на HDDТеплий шар на HDDWarm tier on HDD

Дешевле за терабайтДешевше за терабайтCheaper per terabyte
Точки восстановления старше нескольких дней, которые поднимают редкоТочки відновлення, старші за кілька днів, які піднімають рідкоRecovery points older than a few days, restored rarely
Переезд со свежего слоя по политике, а не вручнуюПереїзд зі свіжого шару за політикою, а не вручнуAged off the fast tier by policy, not by hand

Холодный слой: лентаХолодний шар: стрічкаCold tier: tape

Картридж на полке физически недоступен по сетиКартридж на полиці фізично недоступний мережеюA cartridge on a shelf is physically unreachable over the network
Дешёвое хранение петабайта на десять летДешеве зберігання петабайта на десять роківCheap storage of a petabyte for ten years
Цена изоляции — время: часы и дни, и всё упирается в число приводовЦіна ізоляції — час: години і дні, і все впирається в кількість приводівIsolation costs time: hours and days, bounded by the number of drives

Слой для долгого хранения и для сценария «всё остальное уже скомпрометировано», а не для оперативного восстановления.Шар для довгого зберігання і для сценарію «усе інше вже скомпрометоване», а не для оперативного відновлення.A tier for long retention and for the “everything else is already compromised” scenario, not for operational restores.

Рис.Рис.Fig. 4 Нормальная схема — не выбор между слоями, а их сочетание: свежие копии на быстром слое, старые переезжают на медленный по политике.Нормальна схема — не вибір між шарами, а їх поєднання: свіжі копії на швидкому шарі, старі переїжджають на повільний за політикою.The sound design is not a choice between tiers but a combination of them: recent copies on the fast tier, older ones aged onto the slow one by policy.

Главный параметр хранилища резервных копий — не ёмкость, а скорость восстановления. Ёмкость считают все, скорость восстановления почти никто. А в день инцидента руководство спрашивает не «сколько у нас копий», а «когда заработает».

Головний параметр сховища резервних копій — не ємність, а швидкість відновлення. Ємність рахують усі, швидкість відновлення майже ніхто. А в день інциденту керівництво питає не «скільки в нас копій», а «коли запрацює».

The main parameter of backup storage is not capacity but restore speed. Everyone counts capacity; almost nobody counts restore speed. And on the day of an incident, management does not ask “how many copies do we have” but “when will it work again”.

В день инцидента руководство спрашивает не «сколько у нас копий», а «когда заработает».

У день інциденту керівництво питає не «скільки в нас копій», а «коли запрацює».

On the day of an incident, management does not ask “how many copies do we have” but “when will it work again”.

Горячий слой на NVMe нужен там, где восстанавливать приходится много и быстро. Недавно считал цель резервного копирования на несколько петабайт физической ёмкости на площадку, с требованием к восстановлению в сотни терабайт в час. На таком масштабе дедупликация уже не выручает: данные приходят сжатыми, и хранилище приходится считать по физической ёмкости. Про то, как коэффициент сокращения тает на сжатых и шифрованных данных, подробно писал в выпуске 05 «Три подмены».

Гарячий шар на NVMe потрібен там, де відновлювати доводиться багато і швидко. Нещодавно рахував ціль резервного копіювання на кілька петабайтів фізичної ємності на майданчик, із вимогою до відновлення в сотні терабайтів на годину. На такому масштабі дедуплікація вже не рятує: дані приходять стиснутими, і сховище доводиться рахувати за фізичною ємністю. Про те, як коефіцієнт скорочення тане на стиснутих і шифрованих даних, докладно писав у випуску 05 «Три підміни».

The hot NVMe tier is needed where restores are both large and urgent. I recently sized a backup target at several petabytes of physical capacity per site, with a restore requirement in the hundreds of terabytes per hour. At that scale deduplication no longer helps: the data arrives compressed and the storage has to be sized by physical capacity. On how the reduction ratio melts away on compressed and encrypted data, see issue 05, “Three substitutions”.

Тёплый слой на HDD дешевле за терабайт и отлично подходит для точек восстановления старше нескольких дней, которые поднимают редко. Нормальная схема — не выбор между слоями, а их сочетание: свежие копии на быстром слое, старые переезжают на медленный по политике.

Теплий шар на HDD дешевший за терабайт і чудово підходить для точок відновлення, старших за кілька днів, які піднімають рідко. Нормальна схема — не вибір між шарами, а їх поєднання: свіжі копії на швидкому шарі, старі переїжджають на повільний за політикою.

The warm HDD tier is cheaper per terabyte and suits recovery points older than a few days that are rarely restored. The sound design is not a choice between tiers but a combination: recent copies on the fast tier, older ones aged onto the slow one by policy.

Физический разрывФізичний розривThe physical gap

Лента: холодный слой

Стрічка: холодний шар

Tape: the cold tier

Архаизм, который до сих пор даёт то, чего нет у онлайн-носителей.

Архаїзм, який досі дає те, чого немає в онлайн-носіїв.

An archaism that still provides something no online medium does.

Лента выглядит архаизмом до тех пор, пока не посчитаешь стоимость хранения петабайта на десять лет и не вспомнишь, что картридж на полке физически недоступен по сети. Такой изоляции не даёт ни один онлайн-носитель.

Стрічка виглядає архаїзмом доти, доки не порахуєш вартість зберігання петабайта на десять років і не згадаєш, що картридж на полиці фізично недоступний мережею. Такої ізоляції не дає жоден онлайн-носій.

Tape looks like an archaism right up until you cost the storage of a petabyte for ten years and remember that a cartridge on a shelf is physically unreachable over the network. No online medium offers that isolation.

Цена этой изоляции — время. Восстановление с ленты — это часы и дни, а не минуты, и оно упирается в количество приводов. Поэтому лента — слой для долгого хранения и для сценария «всё остальное уже скомпрометировано», а не для оперативного восстановления.

Ціна цієї ізоляції — час. Відновлення зі стрічки — це години і дні, а не хвилини, і воно впирається в кількість приводів. Тому стрічка — шар для довгого зберігання і для сценарію «усе інше вже скомпрометоване», а не для оперативного відновлення.

That isolation costs time. Restoring from tape is hours and days, not minutes, and it is bounded by the number of drives. So tape is a tier for long retention and for the “everything else is already compromised” scenario, not for operational restores.

Сейчас на столе у меня задача обратного направления: крупная библиотека на два десятка приводов и несколько сотен картриджей, заказчик хочет полностью уйти на флеш. Аргументы понятны: скорость, плотность, отказ от механики. Но первым задаю вопрос: что в новой схеме заменит физический разрыв. Если ответа нет, ленту стоит оставить хотя бы для самого долгого хранения.

Зараз на столі в мене задача зворотного напряму: велика бібліотека на два десятки приводів і кілька сотень картриджів, замовник хоче повністю піти на флеш. Аргументи зрозумілі: швидкість, щільність, відмова від механіки. Але першим ставлю питання: що в новій схемі замінить фізичний розрив. Якщо відповіді немає, стрічку варто залишити хоча б для найдовшого зберігання.

I currently have a task pointing the other way: a large library with a couple of dozen drives and several hundred cartridges, and a customer who wants to move entirely to flash. The arguments are clear: speed, density, no more mechanics. But the first question I ask is what will replace the physical gap in the new design. If there is no answer, the tape is worth keeping at least for the longest retention.

Защита от шифровальщикаЗахист від шифрувальникаRansomware protection

Неизменяемость и готовые решения

Незмінність і готові рішення

Immutability and purpose-built appliances

Копию, которую может удалить администратор, может удалить и тот, кто украл его учётную запись.

Копію, яку може видалити адміністратор, може видалити й той, хто вкрав його обліковий запис.

A copy an administrator can delete can also be deleted by whoever stole that administrator’s account.

Современный шифровальщик сначала ищет резервные копии и только потом шифрует основные данные. Поэтому неизменяемость копий — уже не опция, а базовое требование.

Сучасний шифрувальник спочатку шукає резервні копії і лише потім шифрує основні дані. Тому незмінність копій — уже не опція, а базова вимога.

Modern ransomware looks for the backups first and only then encrypts the primary data. Which makes immutable copies no longer an option but a basic requirement.

Механизмов три. Защищённый Linux-репозиторий, где у сервиса резервного копирования нет прав на удаление. Объектная блокировка, которая запрещает удаление до истечения срока хранения. Блокировка хранилища на стороне самого продукта резервного копирования. У всех один принцип: срок хранения задаётся при записи, и до его истечения копию не может удалить никто, включая администратора резервного копирования.

Механізмів три. Захищений Linux-репозиторій, де в сервісу резервного копіювання немає прав на видалення. Об’єктне блокування, яке забороняє видалення до спливу строку зберігання. Блокування сховища на боці самого продукту резервного копіювання. У всіх один принцип: строк зберігання задається при записі, і до його спливу копію не може видалити ніхто, включно з адміністратором резервного копіювання.

There are three mechanisms. A hardened Linux repository where the backup service has no delete rights. Object lock, which forbids deletion until the retention period expires. And storage lock on the side of the backup product itself. All three work on one principle: the retention period is set at write time, and until it expires nobody can delete the copy — the backup administrator included.

Неизменяемость не отменяет разделения учётных записей. Если хранилище копий, консоль резервного копирования и основная инфраструктура сидят в одном домене с одними администраторами, злоумышленнику достаточно одной учётной записи.

Незмінність не скасовує розділення облікових записів. Якщо сховище копій, консоль резервного копіювання та основна інфраструктура сидять в одному домені з одними адміністраторами, зловмиснику достатньо одного облікового запису.

Immutability does not remove the need to separate accounts. If the backup repository, the backup console and the main infrastructure all sit in one domain with the same administrators, one stolen account is all an attacker needs.

Про готовые решения. Апплайнсы вроде HyperScale X у Commvault хороши тем, что поставляются уже защищёнными и не требуют собирать и укреплять репозиторий вручную.

Про готові рішення. Аплайнси на кшталт HyperScale X у Commvault хороші тим, що постачаються вже захищеними і не вимагають збирати та зміцнювати репозиторій вручну.

On purpose-built appliances. Products like Commvault’s HyperScale X are useful in that they ship already hardened and spare you from building and locking down a repository by hand.

Копия вне площадкиКопія поза майданчикомA copy off site

Резервная копия в локальное облако

Резервна копія в локальну хмару

A backup into a local cloud

Закон о локализации в редакции 2026 года, модель размещения и арифметика канала.

Закон про локалізацію в редакції 2026 року, модель розміщення та арифметика каналу.

The 2026 wording of the localisation law, the hosting model, and the arithmetic of the link.

Вишенка на торте — копия за пределами собственной инфраструктуры. Для Средней Азии это почти всегда локальное облако, и причина не только техническая.

Вишенька на торті — копія за межами власної інфраструктури. Для Середньої Азії це майже завжди локальна хмара, і причина не лише технічна.

The cherry on top is a copy outside your own infrastructure. For Central Asia that is almost always a local cloud, and the reason is not only technical.

С 2021 года статья 27-1 Закона о персональных данных требовала хранить персональные данные граждан на технических средствах внутри страны. В марте 2026 года закон смягчили: обязательной локализация осталась для биометрических и генетических данных и для данных абонентов телеком-операторов. Остальные можно хранить за рубежом при адекватной защите в стране хранения, утверждённых договорных условиях или международных стандартах. Для банков к этому добавляются требования отраслевого регулятора, их стоит проверять отдельно.

З 2021 року стаття 27-1 Закону про персональні дані вимагала зберігати персональні дані громадян на технічних засобах усередині країни. У березні 2026 року закон пом’якшили: обов’язковою локалізація залишилася для біометричних і генетичних даних та для даних абонентів телеком-операторів. Решту можна зберігати за кордоном за адекватного захисту в країні зберігання, затверджених договірних умов або міжнародних стандартів. Для банків до цього додаються вимоги галузевого регулятора, їх варто перевіряти окремо.

Since 2021, article 27-1 of the Personal Data Act required citizens’ personal data to be stored on technical facilities inside the country. In March 2026 the law was relaxed: mandatory localisation remained for biometric and genetic data and for telecom subscribers’ data. The rest may be stored abroad given adequate protection in the storing country, approved contractual terms, or international standards. For banks the sector regulator’s requirements apply on top, and those are worth checking separately.

Так что зарубежное облако перестало быть запретом по умолчанию, но для телекома и биометрии вопрос по-прежнему закрыт.

Тож закордонна хмара перестала бути забороною за замовчуванням, але для телекому і біометрії питання, як і раніше, закрите.

So a foreign cloud has stopped being a default prohibition — but for telecoms and biometrics the question remains closed.

Варианты копии за пределами собственной площадкиВаріанти копії за межами власного майданчикаOptions for a copy outside your own site

После смягчения закона о локализации в марте 2026 года выбор стал шире, но не для всех категорий данных.Після пом’якшення закону про локалізацію в березні 2026 року вибір став ширшим, але не для всіх категорій даних.After the localisation law was relaxed in March 2026 the choice widened — but not for every category of data.

Своё объектное хранилище в арендованной стойкеСвоє об’єктне сховище в орендованій стійціYour own object storage in a rented rack

Железо и софт свои, площадка чужаяЗалізо і софт свої, майданчик чужийYour hardware and software, somebody else’s site
Больше контроля: настройки, учётные записи, сроки храненияБільше контролю: налаштування, облікові записи, строки зберіганняMore control: settings, accounts, retention periods
Запускается дольше и требует своих рукЗапускається довше і вимагає своїх рукTakes longer to stand up and needs your own hands

S3 как услуга у оператора ЦОДS3 як послуга в оператора ЦОДS3 as a service from a data-centre operator

Запускается быстрее всегоЗапускається найшвидшеThe fastest to start
Юрисдикция внутри страныЮрисдикція всередині країниJurisdiction inside the country
Проверять объектную блокировку, админдоступ и условия выходаПеревіряти об’єктне блокування, адміндоступ і умови виходуCheck the object lock, the administrative access and the exit terms

Зарубежное облакоЗакордонна хмараA foreign cloud

С марта 2026 года допустимо для большинства персональных данных при выполнении условий законаЗ березня 2026 року допустимо для більшості персональних даних за виконання умов законуPermitted for most personal data since March 2026, if the statutory conditions are met
Закрыто для биометрии, генетических данных и абонентов операторов связиЗакрито для біометрії, генетичних даних і абонентів операторів зв’язкуClosed for biometrics, genetic data and telecom subscribers
Для банков дополнительно проверяются требования отраслевого регулятораДля банків додатково перевіряються вимоги галузевого регулятораFor banks, the sector regulator’s requirements apply on top

Рис.Рис.Fig. 5 Что проверять в любом случае: поддерживается ли объектная блокировка, где физически лежат данные, кто имеет административный доступ и на каких условиях данные можно забрать при выходе из договора.Що перевіряти в будь-якому разі: чи підтримується об’єктне блокування, де фізично лежать дані, хто має адміністративний доступ і на яких умовах дані можна забрати при виході з договору.What to check in every case: whether object lock is supported, where the data physically sits, who holds administrative access, and on what terms you can take the data back when the contract ends.

Для локальной копии остаются два варианта. Первый — собственное объектное хранилище в арендованной стойке у оператора ЦОД: железо и софт свои, площадка чужая. Второй — хранилище как услуга от самого оператора. Второй быстрее запускается, первый даёт больше контроля.

Для локальної копії залишаються два варіанти. Перший — власне об’єктне сховище в орендованій стійці в оператора ЦОД: залізо і софт свої, майданчик чужий. Другий — сховище як послуга від самого оператора. Другий швидше запускається, перший дає більше контролю.

For a local copy there are two options. The first is your own object storage in a rack rented from a data-centre operator: your hardware and software, somebody else’s site. The second is storage as a service from the operator itself. The second starts faster; the first gives more control.

Время первой полной копии по каналу при реальной загрузке 70%Час першої повної копії каналом за реального завантаження 70%Time for the first full copy over the link at a realistic 70% utilisation

Арифметика канала, которую почему-то делают последней.Арифметика каналу, яку чомусь роблять останньою.The link arithmetic that somehow always gets done last.

100 TB первой полной копии100 TB першої повної копії100 TB as a first full copy

Канал 1 Гбит/с, идеальные 100%Канал 1 Гбіт/с, ідеальні 100%1 Gbit/s link, a perfect 100%

больше 9 сутокбільше 9 дібover 9 days

Канал 1 Гбит/с, реальные 70%Канал 1 Гбіт/с, реальні 70%1 Gbit/s link, a realistic 70%

около двух недельблизько двох тижнівabout two weeksв день инцидента столько ждать никто не будету день інциденту стільки чекати ніхто не будеnobody will wait that long on the day of an incident

Канал 10 Гбит/с, идеальные 100%Канал 10 Гбіт/с, ідеальні 100%10 Gbit/s link, a perfect 100%

≈ 22 часа≈ 22 години≈ 22 hours

Канал 10 Гбит/с, реальные 70%Канал 10 Гбіт/с, реальні 70%10 Gbit/s link, a realistic 70%

около полутора сутокблизько півтори добиabout a day and a half

Рис.Рис.Fig. 6 Восстановление из облака подчиняется той же арифметике. Поэтому облачная копия — последняя ступень лестницы, а не первая линия восстановления.Відновлення з хмари підпорядковується тій самій арифметиці. Тому хмарна копія — останній щабель драбини, а не перша лінія відновлення.Restoring from the cloud obeys the same arithmetic. Which makes a cloud copy the last rung of the ladder, not the first line of recovery.

И арифметика канала, которую почему-то делают последней. Первая полная копия на 100 TB по каналу 1 Гбит/с при полной загрузке идёт больше 9 суток, при реальных 70% — около двух недель. На 10 Гбит/с — от 22 часов до полутора суток. Восстановление из облака подчиняется той же арифметике, только в день инцидента ждать две недели уже никто не будет. Поэтому облачная копия — это последняя ступень лестницы, а не первая линия восстановления.

І арифметика каналу, яку чомусь роблять останньою. Перша повна копія на 100 TB каналом 1 Гбіт/с за повного завантаження йде більше 9 діб, за реальних 70% — близько двох тижнів. На 10 Гбіт/с — від 22 годин до півтори доби. Відновлення з хмари підпорядковується тій самій арифметиці, тільки в день інциденту чекати два тижні вже ніхто не буде. Тому хмарна копія — це останній щабель драбини, а не перша лінія відновлення.

And the arithmetic of the link, which somehow always gets done last. A first full copy of 100 TB over a 1 Gbit/s link takes more than 9 days at full utilisation and about two weeks at a realistic 70%. On 10 Gbit/s it is 22 hours to a day and a half. Restoring from the cloud obeys the same arithmetic, except that on the day of an incident nobody is going to wait two weeks. Which makes a cloud copy the last rung of the ladder, not the first line of recovery.

Чек-листЧек-листChecklist

Что проверить до выбора схемы

Що перевірити до вибору схеми

What to check before choosing a design

Двенадцать вопросов, которые стоит задать до выбора продуктов и редакций.

Дванадцять питань, які варто поставити до вибору продуктів і редакцій.

Twelve questions worth asking before you choose products and editions.

Выписана ли матрица угроз и какими двумя-тремя ступенями закрыта каждая её строка.
Есть ли у каждого ручного снапшота срок жизни в регламенте.
Какие системы действительно требуют точки восстановления меньше часа, а какие — только по привычке.
Проходит ли синхронная схема по задержке между площадками и есть ли место для свидетеля.
Какие функции восстановления входят в выбранную редакцию, а какие требуют дополнения, — по сценарию, а не по названию редакции.
По каким ядрам считается дополнение и не попадают ли под него ядра, где защищать нечего.
Что будет показано аудитору и когда последний раз делалось тестовое переключение.
Какой слой копий неизменяемый и может ли его удалить администратор резервного копирования.
Посчитана ли скорость восстановления, а не только ёмкость хранилища копий.
Что в схеме даёт физический разрыв с основной инфраструктурой.
Разделены ли учётные записи резервного копирования и основной инфраструктуры.
Сколько идёт первая полная копия и полное восстановление из облака по реальному каналу.

Чи виписана матриця загроз і якими двома-трьома щаблями закритий кожен її рядок.
Чи є в кожного ручного снапшота строк життя в регламенті.
Які системи справді потребують точки відновлення менше години, а які — лише за звичкою.
Чи проходить синхронна схема за затримкою між майданчиками і чи є місце для свідка.
Які функції відновлення входять в обрану редакцію, а які потребують доповнення, — за сценарієм, а не за назвою редакції.
За якими ядрами рахується доповнення і чи не потрапляють під нього ядра, де захищати нічого.
Що буде показано аудитору і коли востаннє робилося тестове перемикання.
Який шар копій незмінний і чи може його видалити адміністратор резервного копіювання.
Чи порахована швидкість відновлення, а не лише ємність сховища копій.
Що в схемі дає фізичний розрив з основною інфраструктурою.
Чи розділені облікові записи резервного копіювання та основної інфраструктури.
Скільки йде перша повна копія і повне відновлення з хмари реальним каналом.

Has the threat matrix been written out, and which two or three rungs cover each of its rows?
Does every manual snapshot have a lifetime defined in the procedure?
Which systems genuinely need a recovery point under an hour, and which only have one out of habit?
Does a synchronous design fit the latency between the sites, and is there somewhere to put the witness?
Which recovery features are in the chosen edition and which need the add-on — judged by scenario, not by the edition’s name?
Which cores is the add-on counted against, and does it sweep in cores with nothing to protect?
What will be shown to the auditor, and when was the last test failover?
Which tier of copies is immutable, and can the backup administrator delete it?
Has restore speed been calculated, not just the capacity of the backup storage?
What in the design provides a physical gap from the main infrastructure?
Are the backup accounts separated from those of the main infrastructure?
How long do the first full copy and a full restore from the cloud take over the real link?

ИтогПідсумокWrap-up

Вместо вывода

Замість висновку

In place of a conclusion

Переключателя «Autosave mode=ON» для ЦОД не существует. Есть лестница от клона до облака, и каждая ступень закрывает свою часть рисков за свою цену.

Перемикача «Autosave mode=ON» для ЦОД не існує. Є драбина від клона до хмари, і кожен щабель закриває свою частину ризиків за свою ціну.

There is no “Autosave mode=ON” switch for a data centre. There is a ladder running from a clone to a cloud, and each rung covers its own share of the risks at its own price.

Ошибка, которую вижу чаще всего, — купить самую дорогую ступень и считать вопрос закрытым. Метрокластер без неизменяемой копии рядом защищает от пожара, но не от шифровальщика и не от своего администратора.

Помилка, яку бачу найчастіше, — купити найдорожчий щабель і вважати питання закритим. Метрокластер без незмінної копії поруч захищає від пожежі, але не від шифрувальника і не від свого адміністратора.

The mistake I see most often is buying the most expensive rung and considering the matter closed. A metro cluster without an immutable copy alongside it protects against fire, but not against ransomware and not against your own administrator.