01

Природа данныхПрирода данихThe nature of the data

Что вообще сожмётся

Що взагалі стиснеться

What will actually compress

Коэффициент редукции определяется не массивом, а тем, что на него пишут. Дедупликация выигрывает на повторах, а не на содержимом.

Коефіцієнт редукції визначається не масивом, а тим, що на нього пишуть. Дедуплікація виграє на повторах, а не на вмісті.

The reduction ratio is set by what is written to the array, not by the array. Dedup wins on repetition, not on content.

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

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

The first place sizing breaks is the reduction ratio. It comes from the array datasheet, lands in the capacity calculation and lives there until the pool fills one and a half times faster than planned.

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

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

The reason is simple: the effectiveness of dedup and compression is decided by what is written to the array, not by the array itself. Backup software almost always compresses and deduplicates the stream on its own side — on the media server, before sending. What arrives at the array is close to random. It cannot be compressed again, and that is a property of the data, not a defect of the array.

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

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

Look at the top row. Deduplication really does give a multiple — but on repetition, not on content. Twenty full copies of one set compress beautifully because nineteen of them consist of blocks already known. Which is exactly why a ratio measured on a backup dedup pool cannot be carried over to primary storage, nor a primary-storage ratio to a copy repository. They are different numbers with different origins.

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

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

What to do about it. Size from raw terabytes. Count reduction only where the backup system itself is the source of the data, and only from a measurement on a sample of the customer’s real data — a week of test backups shows more than any presentation.

02

Расчёт ёмкостиРозрахунок ємностіSizing the capacity

Сколько это в терабайтах на самом деле

Скільки це в терабайтах насправді

How many terabytes this really is

Логический объём — это не «сколько у нас данных». Это полная копия плюс прирост на глубину плюс каждый уровень длительного хранения.

Логічний обсяг — це не «скільки в нас даних». Це повна копія плюс приріст на глибину плюс кожен рівень тривалого зберігання.

Logical volume is not “how much data we have”. It is a full copy plus change rate times retention plus every long-retention tier.

Вторая развилка — из чего вообще складывается объём. Логический объём хранения — это не «сколько у нас данных». Это полная копия плюс суточный прирост, умноженный на глубину ежедневных точек, плюс каждый уровень длительного хранения отдельным слагаемым.

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

The second fork is what the volume actually consists of. Logical stored volume is not “how much data we have”. It is a full copy plus the daily change rate multiplied by the depth of daily points, plus every long-retention tier as a separate term.

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

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

And the daily change rate cannot be taken as typical. Across the systems I see it ranges from one per cent to fifteen. The difference between three and eight per cent on three hundred terabytes of protected data is one and a half terabytes a day, forty-five a month. At that scale an error in the assumption costs more than an error in the choice of vendor.

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

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

The chart shows what to keep in front of you when reading any commercial proposal. Between an honest calculation and a “let us put three to one” calculation lies a threefold difference in purchased capacity. That benefits the seller exactly once, at signing. After that it benefits someone else.

Ошибка в предположении о суточном приросте обходится дороже, чем ошибка в выборе вендора.

Помилка в припущенні про добовий приріст обходиться дорожче, ніж помилка у виборі вендора.

An error in the daily-change assumption costs more than an error in the choice of vendor.

03

Арифметика восстановленияАрифметика відновленняRecovery arithmetic

Почему восстановление идёт в один поток

Чому відновлення йде в один потік

Why a restore runs in a single stream

Время восстановления равно объёму, делённому на скорость самого узкого последовательного участка тракта. Всё остальное — потолок.

Час відновлення дорівнює обсягу, поділеному на швидкість найвужчої послідовної ділянки тракту. Усе інше — стеля.

Recovery time equals volume divided by the speed of the narrowest sequential link in the chain. Everything else is a ceiling.

Тракт выглядит так: чтение блоков из дедуплицированного хранилища, регидратация, распаковка, передача, запись в целевое хранилище. Ограничителем почти всегда становится первое звено, потому что чтение из дедуп-пула — это не последовательное чтение, а выборка блоков по всему пулу. На дисках это десятки мегабайт в секунду.

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

The chain looks like this: reading blocks from deduplicated storage, rehydration, decompression, transfer, writing to the target. The first link is almost always the limiter, because reading from a dedup pool is not sequential reading but block gathering across the whole pool. On disk that is tens of megabytes per second.

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

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

A misconception lives here that is worth stating plainly. On backup there is parallelism: the software spreads streams across machines and disks, and adding readers really does widen the window. On restore, parallelism is limited by the structure of the object. One virtual disk is not split between streams — one disk, one stream, however many readers you configure. And for certain combinations of hypervisor and agent the limit is harder still: a full restore of one machine runs in a single stream even with several disks, and no setting overrides it.

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

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

The arithmetic is unpleasant. At around thirty megabytes per second, a full restore stops being a usable mechanism at single-digit terabytes — not because it does not work, but because the result arrives later than any sensible target. Ten terabytes is over three days. By then “when will we be back” has stopped being a technical question.

Вывод для проектирования: закладывая норматив, надо знать не сколько потоков поддерживает продукт вообще, а сколько потоков он выделит на восстановление одного конкретного объекта в вашей связке версий. Этот вопрос имеет смысл задавать вендору письменно, а ответ подшивать к проекту.

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

The design conclusion: when you set a target, you need to know not how many streams the product supports in general, but how many streams it will allocate to restoring one specific object in your exact version combination. That question is worth asking the vendor in writing and filing the answer with the project.

04

Уровни восстановленияРівні відновленняRecovery tiers

Одной механики не бывает

Однієї механіки не буває

One mechanism is never enough

Полное восстановление медленное по природе. Ускорять его бессмысленно — его надо не использовать там, где нужен быстрый возврат.

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

A full restore is slow by nature. Speeding it up is pointless — the answer is not to use it where you need a fast return.

Зрелая система — это три-четыре механики с разным временем и разной ценой. Восстановление из аппаратного снимка на массиве вообще не читает репозиторий и для свежих точек даёт минуты. Мгновенный запуск поднимает машину сразу, презентуя диски прямо из копии, а фактический перенос данных идёт фоном. Копия без дедупликации читается линейно и предсказуемо. Полный restore из основного пула остаётся штатным вариантом для всего, что не имеет жёсткого норматива.

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

A mature system has three or four mechanisms with different times and different costs. Recovery from an array hardware snapshot does not read the repository at all and gives minutes for recent points. Instant recovery brings the machine up immediately by presenting disks straight from the copy while the actual data move runs in the background. A copy without dedup reads linearly and predictably. A full restore from the main pool stays the standard option for everything without a hard target.

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

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

The cost of these tiers rises from the bottom up, and here projects usually go to one of two extremes. Either the fast tier is not budgeted at all — and then the four-hour target exists only on paper. Or it is budgeted for the entire estate, and the budget doubles for the sake of machines nobody will ever recover in a panic. The right size of the fast tier is not a share of total volume but the sum of data for those services that genuinely must be back within the working day. In my practice that is usually ten to fifteen per cent of the protected volume, and that figure should be listed by name, not estimated.

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

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

Instant recovery has a catch people step on regularly. The mechanism formally works from any medium, but a machine started from a slow pool starts fast and then runs unusably slowly. Formally the service is up; in practice it cannot be used; and the report is all green. If you are counting on instant recovery to meet a target, the tier under it has to be flash, otherwise it is not a solution but an imitation of one.

Сервис поднят, пользоваться им нельзя, а в отчёте всё зелёное.

Сервіс піднято, користуватися ним не можна, а у звіті все зелене.

The service is up, it cannot be used, and the report is all green.

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

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

And the main thing: the “acceptable downtime” row is not filled in by infrastructure. Infrastructure has no right to tell the business how long it may be down. It can only say honestly what each option costs.

05

Платформенная защитаПлатформний захистPlatform protection

Что умеет сама платформа

Що вміє сама платформа

What the platform itself can do

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

Під словами «у нас усе реплікується» ховаються чотири різні механіки з різною областю застосування і різною ціною.

Behind “everything replicates for us” hide four different mechanisms with different scope and different cost.

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

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

On a hyperconverged platform half the mechanisms from the previous section are already built in, and that changes the conversation with the customer. Unfortunately not always for the better: “everything replicates for us” regularly hides four completely different things. Here they are in order, from cheap to expensive.

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

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

A local snapshot on the same cluster. Taken instantly, rolls state back in minutes, costs almost nothing in time. And it lives in the same container, on the same disks, under the same management plane. A cluster failure, a site loss or a compromised admin account removes both production and the restore points in one move. This is a rollback mechanism, not a backup — and that is what it should be called in a report to the regulator. The second nuance, remembered late: deep snapshot chains consume the expensive flash of the production cluster, the flash that was bought for the workload.

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

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

Replication to a neighbouring cluster on the same site. A separate hardware failure domain appears, and that is a fundamentally different level. Modern platforms offer three modes here: asynchronous with a point every hour or less often, an intermediate mode on lightweight snapshots at intervals from one to fifteen minutes, and synchronous replication with zero data loss — the last requiring a link with under five milliseconds of latency. It covers a cluster failure. It does not cover the site and it does not cover ransomware: logical corruption is faithfully repeated by the replica one interval later.

Репликация на удалённый кластер. То же самое плюс площадка, и здесь ограничителем становится канал. Первичная синхронизация идёт полными копиями, дальше — только изменения, но режимы с минутными интервалами чувствительны и к полосе, и к скорости изменения данных. Актуальные версии платформ позволяют смешивать в одной политике защиты до четырёх доменов отказа: синхронно на соседнюю площадку, асинхронно или с минутным интервалом в регион, плюс длительное хранение в объектном хранилище. Это уже не «репликация», а полноценная топология, и проектировать её надо соответственно.

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

Replication to a remote cluster. The same plus the site, and here the link becomes the limiter. The initial sync runs as full copies, after which only changes move, but minute-interval modes are sensitive both to bandwidth and to the rate of data change. Current platform versions allow up to four failure domains to be mixed in one protection policy: synchronous to the neighbouring site, asynchronous or minute-interval to the region, plus long retention in object storage. That is no longer “replication” but a full topology, and it should be designed as one.

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

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

Exporting snapshots to object storage. It takes deep chains off the production pool, puts them in any S3-compatible store and allows recovery to any location where the same platform runs. Intervals start at an hour. Recent versions can start a machine from metadata without waiting for all data to be fetched — so instant recovery now works from object storage too, not only from the local tier. Of the platform mechanisms this is the closest to a real backup. A caveat common to all of them: without guest agents the snapshot is only crash-consistent, and that is not enough for a busy database.

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

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

A dedicated backup environment. A separate cluster or a separate site for copies, running actual backup software with its own repository, catalog and immutability. It is needed where you require independence from a compromise of the platform itself, granular recovery of objects inside applications, one catalog across the whole estate — including what lives outside HCI — and multi-year retention for the regulator.

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

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

The practical rule I keep arriving at: platform mechanisms cover failure and error, backup software covers malice and regulation. This is not competition but a division of responsibility, and in a sound design both are working. The design error starts where one zone is covered with the other’s tools: compliance with snapshots, or a fifteen-minute target with a full restore from the repository.

06

Ярусы и протоколыЯруси і протоколиTiers and protocols

Куда это всё класть

Куди це все класти

Where to put all of it

Главный вопрос по протоколам — не «умеет ли массив», а кто в архитектуре их предоставляет.

Головне питання щодо протоколів — не «чи вміє масив», а хто в архітектурі їх надає.

The real protocol question is not “can the array do it” but who in the architecture provides it.

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

Репозиторій рідко буває однорідним. У нормальній архітектурі виділяється до п’яти ролей: приймальний ярус під вікно копіювання, основний пул на оперативну глибину, швидкий ярус під жорсткий норматив, незмінний ярус і архів. Суміщати ролі можна, але свідомо.

A repository is rarely homogeneous. A sound architecture has up to five roles: a landing tier for the backup window, a main pool for operational retention, a fast tier for a hard target, an immutable tier and an archive. Roles can be combined, but deliberately.

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

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

A separate caveat about an HCI cluster in the repository role. A separate cluster is a separate hardware failure domain, but not a separate platform one: the same vendor, the same software stack, the same administration perimeter and often the same management server. Such a repository does not cover the “platform administrator compromised” scenario. And a hybrid disk configuration is not suitable for a fast recovery tier — only for a capacity one.

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

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

A rule common to every option, and probably the most expensive thing in this section: having the object protocol is not the same as being certified. Every storage system has to be checked against the compatibility matrix of the exact backup-software version you are installing.

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

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

I had a project where the target storage, honestly and fully S3-capable, was simply absent from the verified list for the chosen backup product. It came to light after the storage platform had been decided, and the architecture had to be reassembled. And here the story gets the sequel I tell it for: about a year later the software vendor added that storage to the supported list. Today the same choice would have been the right one.

Мораль не в том, что кто-то кого-то не поддерживал. Мораль в том, что список живой и двигается в обе стороны, а значит смотреть его надо на дату проекта и на конкретную версию продукта — не по памяти, не по прошлогоднему опыту и не по строчке «S3-совместимо» в спецификации. Модель тоже уточняйте: поддержка семейства не означает автоматически поддержку каждой линейки внутри него.

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

The moral is not that someone failed to support someone. The moral is that the list is alive and moves in both directions, so it must be read for the date of your project and for the specific product version — not from memory, not from last year’s experience and not from an “S3-compatible” line in a datasheet. Check the model too: support for a family does not automatically mean support for every line inside it.

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

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

Another decision made silently and paid for later is combining roles on one system. A landing tier and the main pool in one box look like savings right up to the first time the backup window overlaps a restore: writing the copy stream and the random reads of rehydration fight for the same disks and the same controller queue. On an ordinary night it goes unnoticed; in an incident — exactly when the system is needed — both operations slow down at once.

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

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

While you are there, keep fill level in mind. A dedup pool filled above eighty-five per cent starts degrading in speed, and garbage collection stops freeing space at the rate new copies arrive. Fifteen to twenty per cent free is not headroom for growth but a working parameter, without which the quoted numbers do not reproduce.

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

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

A word on protocols, because this is the most frequent argument in tenders. The question “must the array support file and object protocols” is almost always framed wrongly. The right framing is who in the architecture provides the protocol. Backup software handles file and object access itself: the repository can sit on a network share, a copy can go to object storage with object lock, and for instant recovery the media server raises a file resource on its own block volume and presents it to the hypervisor.

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

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

Hence the test question for any proposal: show me the point in the architecture where each stated protocol is used. No point — the requirement is redundant and you are paying for it. There is a point — the requirement is justified, and it is a sound engineering decision: presenting a resource directly from the array really does take load off the media servers, and an object tier on the same hardware simplifies operations. It is simply an architectural choice rather than a technical necessity, and it should be presented honestly.

07

НеизменяемостьНезмінністьImmutability

Air gap кончился, чем закрываем

Air gap скінчився, чим закриваємо

The air gap is gone — what replaces it

Физический разрыв исчез вместе с лентой в оперативном контуре. Замена состоит из двух слоёв и работает только при обоих.

Фізичний розрив зник разом зі стрічкою в оперативному контурі. Заміна складається з двох шарів і працює лише за обох.

The physical gap disappeared along with tape in the operational perimeter. Its replacement has two layers and works only with both.

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

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

Protection of copies from deliberate deletion used to rest on physics: a cartridge taken out of the library is beyond the reach of any administrative privilege. Moving to disk and object storage removes that gap, and something has to replace it.

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

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

The replacement has two layers, and it works only with both. The technical layer is immutability at the storage level, with write-once-read-many object lock as the standard. The organisational layer is separation of rights: the account that manages backups must not be able to shorten the retention period, lift a lock or delete the storage. Add to that confirmation of critical operations by a second administrator.

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

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

A detail worth verifying by hand. Object lock has two modes. Governance allows removal by a privileged account — that is, by exactly the party you are worried about. Compliance allows deletion by nobody until the term expires. Only compliance protects against a targeted attack, and different storage systems default to different modes.

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

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

Then the cost. Immutability almost always costs more than the overall ratio suggests, for two reasons. First, isolated sets normally do not share dedup references with the main pool — they are self-contained so that recovery is possible even if the repository is lost entirely, and self-containment means their own full copies. Second, until the retention period expires the space is not released, even if the copy is no longer needed. An overlong retention setting is cured only by waiting.

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

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

So the capacity of the immutable tier is calculated as a separate line, from full volume and retention depth, without the main pool’s ratio. Conservative — yes. But this is the line most often understated.

08

Выбор платформыВибір платформиChoosing the platform

Две философии: чем отличается софт

Дві філософії: чим відрізняється софт

Two philosophies: how the software differs

Формально оба продукта решают одну задачу. Различия растут из разных представлений о том, что происходит с данными на предприятии.

Формально обидва продукти вирішують одну задачу. Відмінності зростають із різних уявлень про те, що відбувається з даними на підприємстві.

Formally both products solve the same problem. The differences grow from different views of what happens to data in an enterprise.

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

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

Two products usually make our shortlist. Formally they solve the same problem, but they start from different views of what actually happens to data in an enterprise — and the differences in capability and in price grow from there. Outside those two lies the niche of platform-native products, which are good where the whole virtual estate lives on one platform and deserve a separate conversation.

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

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

Feature tables rarely decide the choice: both cover the basic scenario. What decides is the answer to four questions. What share of the estate is non-standard sources — if there are legacy systems and enterprise databases with special requirements, breadth of coverage becomes decisive. How deep the integration with your hypervisor is — native agentless operation removes a whole layer of proxy servers. How many people will operate it — a product that requires a dedicated administrator becomes a risk in a team of three rather than protection from one. And how the system will grow: wide in object count or deep in volume — that directly determines which licensing model is cheaper in three years.

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

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

The fifth question stands apart, because projects burn on it. Is the chosen target array certified for the product version you need. Protocol compatibility is not certification: storage that honestly supports object access may be absent from the verified matrix for a specific product. That is discovered during implementation, when the hardware is already in the rack.

09

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

Что спросить до того, как считать спецификацию

Що спитати до того, як рахувати специфікацію

What to ask before you price a specification

Двенадцать вопросов, которые превращают круглое число в расчёт, который можно защищать.

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

Twelve questions that turn a round number into a calculation you can defend.

1. Для каждого класса сервисов зафиксированы допустимое время простоя и допустимая потеря данных — и подписаны владельцами систем, а не инфраструктурой?
2. Объём считался по занятому месту или по выделенному? Исключены ли реплики, служебные и брошенные машины?
3. Откуда взялся коэффициент редукции и к какому именно потоку данных он относится?
4. Суточный прирост измерен или принят типовым?
5. Какой механикой достигается норматив для каждого класса — и чем это подтверждено, кроме суммарной пропускной способности железа?
6. Сколько потоков продукт выделит на восстановление одного объекта в вашей связке версий?
7. Ёмкость неизменяемого яруса посчитана отдельной строкой, без общих ссылок с основным пулом?
8. Для каждого требуемого протокола указана точка его использования в архитектуре?
9. Целевое хранилище присутствует в матрице совместимости нужной версии продукта?
10. Может ли учётная запись, управляющая копированием, сократить срок удержания или удалить репозиторий?
11. Перенос существующих данных выделен в отдельный этап с расчётом по полосе тракта?
12. Есть ли регламент тестового восстановления с замером фактического времени — и когда он исполнялся последний раз?

1. Для кожного класу сервісів зафіксовані припустимий час простою і припустима втрата даних — і підписані власниками систем, а не інфраструктурою?
2. Обсяг рахувався за зайнятим місцем чи за виділеним? Чи виключені репліки, службові та покинуті машини?
3. Звідки взявся коефіцієнт редукції і до якого саме потоку даних він належить?
4. Добовий приріст виміряно чи прийнято типовим?
5. Якою механікою досягається норматив для кожного класу — і чим це підтверджено, крім сумарної пропускної здатності заліза?
6. Скільки потоків продукт виділить на відновлення одного об’єкта у вашій зв’язці версій?
7. Ємність незмінного ярусу порахована окремим рядком, без спільних посилань з основним пулом?
8. Для кожного потрібного протоколу вказано точку його використання в архітектурі?
9. Цільове сховище присутнє в матриці сумісності потрібної версії продукту?
10. Чи може обліковий запис, що керує копіюванням, скоротити строк утримання або видалити репозиторій?
11. Перенесення наявних даних виділено в окремий етап із розрахунком за смугою тракту?
12. Чи є регламент тестового відновлення з виміром фактичного часу — і коли він виконувався востаннє?

1. Are acceptable downtime and acceptable data loss fixed for every service class — and signed by system owners rather than by infrastructure?
2. Was the volume counted as used space or as allocated? Are replicas, utility and abandoned machines excluded?
3. Where did the reduction ratio come from and which data stream exactly does it refer to?
4. Is the daily change rate measured or assumed to be typical?
5. Which mechanism meets the target for each class — and what confirms it beyond the hardware’s aggregate throughput?
6. How many streams will the product allocate to restoring one object in your exact version combination?
7. Is the immutable tier’s capacity costed as a separate line, without shared references to the main pool?
8. For every required protocol, is the point of its use shown in the architecture?
9. Is the target storage present in the compatibility matrix of the required product version?
10. Can the account that manages backups shorten the retention period or delete the repository?
11. Is migration of existing data a separate stage with a calculation based on the path’s bandwidth?
12. Is there a test-restore procedure that measures actual time — and when was it last carried out?

10

ИтогПідсумокBottom line

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

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

Instead of a conclusion

Резервное копирование — единственная инфраструктурная система, ценность которой измеряется в момент отказа всего остального. Всё остальное время она выглядит статьёй расходов, и поэтому её так легко спроектировать формально: ёмкость есть, глубина есть, статусы зелёные.

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

Backup is the only infrastructure system whose value is measured at the moment everything else fails. The rest of the time it looks like a cost line, which is why it is so easy to design it formally: capacity is there, retention is there, the statuses are green.

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

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

The maturity test is simple. If the organisation has a document recording acceptable downtime for every service class, and a test-restore record showing the actual figure, the system has been designed. If there is no such document, discussing ratios, licences and array models is premature: there is nothing to calculate.

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

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

If a specification or a proposal is on your desk right now, run it through the checklist above. Half an hour, and usually by the third question it is clear what to discuss with the contractor.