Лицензии для резервного копирования: выбор под рост данных

В чем проблема с лицензиями, когда данные растут

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

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

Как только инфраструктура расширяется, возникают практичные вопросы:

• За что считается оплата: сервер, сокет, виртуальная машина или объем данных?
• Что изменится, если появится еще один хост виртуализации или вторая площадка?
• Сколько стоит увеличение ретеншна и частоты копий?
• Как учитываются тестовые среды и временные проекты?

Самая рискованная ситуация - купить лицензии «впритык», без прогноза на 1-3 года. Через несколько месяцев вы докупаете по менее выгодной цене, получаете смешанный набор лицензий или внезапно упираетесь в ограничения по учету. Бюджет становится непредсказуемым, а обсуждения с поставщиком превращаются в постоянные пересчеты.

Ниже - три модели лицензирования и четыре критерия, по которым их удобно сравнивать: деньги (стоимость сейчас и при росте), гибкость (насколько легко добавлять системы), риски учета (что именно считается и как это проверяется) и управляемость (насколько просто объяснить и контролировать лицензирование).

Три модели лицензирования: кратко и по делу

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

Per workload - платите за защищаемую единицу: виртуальную машину, физический сервер или приложение (например, базу данных). Сколько объектов бэкапите, за столько и платите.

Per socket - платите за процессорные сокеты на хостах, где крутятся рабочие нагрузки. В виртуализации это часто значит: лицензируется не каждая ВМ, а хост(ы) по числу CPU.

Per TB - платите за объем данных. Ключевой момент - какой именно: исходный объем, объем после дедупликации/сжатия или занятое место в репозитории.

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

Частая ловушка - что входит в лицензию, а что докупается отдельно. У некоторых вендоров отдельными опциями могут быть расширенный ретеншн, копия в облако, шифрование, поддержка определенных гипервизоров, ленты, репликация между площадками или 24/7 поддержка.

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

Простой пример: 20 ВМ на двух хостах. В per workload вы платите за 20 объектов, в per socket - условно за 4 сокета, а в per TB все упрется в скорость роста данных и срок хранения копий.

Модель per workload: плюсы и где она подводит

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

Сильная сторона модели - предсказуемость на уровне «сколько единиц защищаем». Если у вас 80 небольших ВМ и вы понимаете, что будет 90, бюджетировать проще, чем гадать по сокетам или терабайтам.

Слабое место - стоимость быстро растет вместе с количеством ВМ и сервисов. Объем данных может почти не меняться, но вы запускаете еще 20 небольших ВМ под новые задачи, и лицензии становятся заметной статьей расходов.

Перед покупкой важно уточнить, что именно считается отдельной нагрузкой. Обычно вопросы возникают вокруг баз данных и приложений (считаются отдельно или внутри ВМ), контейнеров и Kubernetes, файловых ресурсов и NAS (по серверу, шару или объему), а также клонов, шаблонов и временных сред.

Сюрпризы чаще всего появляются в трех местах: тестовые контуры, кластеры и DR. Тестовый стенд легко разрастается, и если он попал в политику бэкапа «по умолчанию», счет растет без пользы. В кластерах важно понять, не превращает ли миграция ВМ на другой хост учет в «новую» единицу. В DR-сценариях заранее выясните, нужна ли отдельная лицензия на резервную площадку и как считается временный failover.

Пример: вы начали с 40 ВМ, а через год добавили витрину данных, несколько сервисов и тестовый контур - стало 75 ВМ. Данные выросли умеренно, а стоимость per workload - почти вдвое. В этой модели выигрывают те, кто контролирует «зоопарк» ВМ и четко отделяет прод от теста.

Модель per socket: как она работает в виртуализации

Per socket означает, что вы платите за сокеты (CPU) на хостах гипервизора, где размещаются защищаемые ВМ. Сколько виртуальных машин на этих хостах, обычно не так важно. Поэтому при виртуализации эта модель часто выглядит выгодно: мало физических серверов, но десятки или сотни ВМ.

Пример: 2 хоста в кластере, по 2 сокета на каждом. Если лицензия считается по сокетам, оплачиваются 4 сокета, а добавление новых ВМ не увеличивает стоимость лицензий.

Слабое место - обновление железа и изменение архитектуры. Сегодня у вас два 2-сокетных хоста, завтра вы меняете парк на более мощные серверы и добавляете хосты или сокеты. Цена растет не из-за данных и не из-за количества ВМ, а из-за топологии.

Есть и скрытый риск: иногда требуется покрыть лицензией все хосты, на которые ВМ могут мигрировать (HA/DRS, live migration), включая резервные узлы. Даже если хост «стоит в запасе», он может попасть в расчет.

Перед закупкой стоит зафиксировать правила:

• Нужно ли лицензировать все хосты кластера или только те, где реально размещены защищаемые ВМ.
• Считаются ли резервные и DR-хосты, а также отдельная площадка для аварийного восстановления.
• Есть ли лимиты по ядрам на сокет или доплаты за высокую плотность CPU.
• Можно ли переносить лицензии при замене серверов и как часто это допускается.

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

Модель per TB: понятная, но чувствительная к ретеншну

Per TB проще всего объяснить закупкам: вы платите за объем данных, а не за сокеты или «ворклоады». Для бюджета это выглядит прозрачно, но только если заранее договориться, что именно считается «TB».

Одни вендоры считают исходные данные (front-end) на продакшене, другие - фактический объем в репозитории после сжатия и дедупликации. Это две разные цифры, и вторая сильно зависит от типов данных.

Что раздувает TB быстрее, чем кажется

В этой модели рост идет не только из-за новых файлов. Часто «виноваты» политика хранения и частота копий: чем дольше храните точки восстановления и чем чаще делаете бэкап, тем быстрее растет общий объем. Ситуацию усиливают типы данных, которые плохо сжимаются (видео, архивы), а также дополнительные контуры - например, вторая площадка или изолированная копия.

Где чаще всего начинаются споры

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

Практический пример: у организации 50 TB рабочих данных. При ретеншне 30 дней и ежечасовых инкрементах объем в репозитории может вырасти до 120-180 TB, если данные активно меняются и дедупликация работает слабо. Поэтому при выборе per TB заранее фиксируйте метод расчета и отдельно оценивайте влияние ретеншна и дополнительных копий, особенно если планируется репликация в другой ЦОД.

Как оценить рост данных без сложной математики

Чтобы не промахнуться с лицензиями, важно понять не только «сколько терабайт сейчас», а за счет чего и как быстро меняется объем.

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

Дальше отделите «естественный рост» от «новых источников». Новые системы почти всегда добавляют данные рывком: новый филиал, видеонаблюдение, внедрение или расширение 1С, медицинские изображения (PACS), новые файловые шары, почта, VDI.

Затем прикиньте, как ретеншн умножает объем. Чем дольше храните точки восстановления, тем сильнее per TB реагирует на изменения политики. Переход с 7 дней на 30 даст заметный рост даже без увеличения «живых» данных.

Удобная быстрая схема:

• Зафиксируйте, сколько данных реально попадает в бэкап.
• Посмотрите средний и худший месяц прироста.
• Отдельно запишите крупные будущие добавления (проекты, филиалы, новые сервисы).
• Проверьте ретеншн: 7, 30, 180 дней, плюс архивные точки (если они нужны).
• Отметьте события, которые ускоряют рост: миграции, слияния, требования регулятора.

Пример: у организации 80 TB, прирост 2 TB в месяц, но через 3 месяца подключают 40 камер и добавляют еще 30 TB. Если одновременно ретеншн увеличивают с 14 до 90 дней, «сюрприз» будет не в приросте 2 TB, а в изменении политики хранения.

Пошаговый выбор модели лицензии под реальный рост

Выбор начинается не с прайса, а с того, что именно будет расти. Лицензирование почти всегда «ломается» на деталях учета: что считается защищаемым объектом, где меряется объем и что происходит при расширении инфраструктуры.

Соберите вводные: какие системы защищаете (ВМ, физические серверы, базы), где они расположены (одна площадка или несколько) и какой тип восстановления нужен чаще всего (файлы, целые ВМ, отдельные базы).

Дальше помогает простая последовательность:

1. Зафиксируйте состав защиты на сегодня: количество ВМ, физических хостов, критичных баз, объем данных и скорость ежедневных изменений.
2. Выберите горизонт планирования: разумный минимум 12-24 месяца, чтобы не докупать «в пожарном режиме».
3. Опишите 2-3 сценария роста: базовый, умеренный и стрессовый (резкий рост штата, запуск видео, переезд в новый сервис).
4. Сопоставьте сценарии с драйвером лицензии:
   • если растет число систем, чаще выигрывает per workload;
   • если растут хосты и сокеты виртуализации, смотрите per socket;
   • если прогноз проще в терабайтах и объектов немного, сравнивайте per TB.
5. Проверьте правила учета и ограничения: что считается workload, как считаются сокеты, какой объем берется для per TB и как влияет ретеншн.

Пример: у вас 40 ВМ на двух хостах, а через год станет 80 ВМ, но общий объем вырастет всего на 20%. Тогда per socket может выглядеть выгодно, пока не меняется число хостов и сокетов, а per workload будет расти вместе с количеством ВМ. Если при этом бизнес требует хранить копии дольше, per TB может подорожать именно из-за ретеншна.

Если параллельно ожидается обновление серверов или расширение СХД, полезно привязать прогноз к плану закупок. Тогда рост будет не абстрактным, а привязанным к реальным проектам.

Частые ошибки при выборе лицензий на бэкап

Самая дорогая ошибка - считать, что «все будет как сейчас». Бэкап растет не только из-за новых файлов, но и из-за политики хранения, копий для тестов и требований к отказоустойчивости.

Ошибка 1: считать только текущий объем и забыть про ретеншн

Команда видит: «у нас 60 TB данных» и от этого строит бюджет. Через полгода включают хранение на 90 дней вместо 30, добавляют ежемесячные архивные точки - и расчет перестает сходиться. Данные почти те же, а точек восстановления стало больше.

Ошибка 2: не учесть тестовые и резервные площадки

Лицензируют только основную площадку, а потом вспоминают про DR-сайт, песочницу для тестов восстановления или отдельный стенд для обновлений. В зависимости от вендора, лицензия может требоваться и на реплику, и на вторичный сервер, и на ворклоады, которые туда восстанавливают.

Правило простое: если площадка участвует в защите или восстановлении, проверьте, как она учитывается в лицензии.

Ошибка 3: путать «сырой» объем и «эффективный» после сжатия

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

Один раз зафиксируйте: метрика - это защищаемые данные, объем на диске или что-то еще. И откуда берется цифра: из отчета бэкап-системы, из SAN/NAS, из гипервизора.

Ошибка 4: закладывать рост только по данным и игнорировать рост числа систем

Если вы растете «вширь» (больше ВМ, баз, сервисов, филиалов), модели per workload и per socket могут стать дороже даже при умеренном росте TB. Это особенно заметно, когда появляются новые приложения, которые тоже нужно защищать.

Ошибка 5: не закрепить в документах, как ведется учет

Без простого регламента начинается спор: закупка считает по одному отчету, техподдержка - по другому, вендор - по третьему. Риск двойной: переплата или внезапный «недолиценз» на проверке.

Минимум, который стоит зафиксировать:

• какая модель и метрика используются (workload, socket, TB)
• какой источник цифр считается «истиной» (конкретный отчет/выгрузка)
• как учитываются тестовые и резервные площадки, а также временные восстановления

Короткий чеклист перед закупкой

Перед покупкой договоритесь внутри команды, что именно вы считаете и кто за это отвечает. Тогда модель может быть не только «правильной на бумаге», но и удобной в эксплуатации.

Оцените, что растет быстрее: TB или количество workloads. Если постоянно добавляются новые ВМ, базы и сервисы, чаще «взрывается» число объектов. Если сервисов немного, но быстро увеличиваются объемы (логи, видео, аналитика), главным драйвером почти всегда становится TB.

Проверьте инфраструктуру на горизонте 12-24 месяцев. Для per socket критично понимать, сколько физических хостов будет в кластере и сколько сокетов на каждом. Ловушка бывает такой: «хостов будет столько же», но меняется железо, и лицензия пересчитывается.

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

И не забудьте про DR: второй ЦОД, резервная площадка, копия в облако или в другой город иногда удваивают объемы хранения или добавляют новые объекты в лицензирование.

Контрольные вопросы:

• Что у нас растет быстрее: TB или количество workloads?
• Сколько хостов и сокетов будет через 1-2 года?
• Какой ретеншн обязателен и кто его утверждает?
• Будет ли DR: второй ЦОД или дополнительная копия?
• Кто ежемесячно снимает метрики и проверяет лимиты по лицензии?

Если вы параллельно закупаете серверы под бэкап или модернизируете площадку, удобно привязать этот чеклист к плану обновления железа. При расширении парка серверов (в том числе локального производства, как у GSE.kz) проще заранее понять, как изменение числа сокетов и объемов хранения повлияет на будущие платежи.

Пример на практике: как решение меняется от сценария роста

Стартовая картина: 60 TB данных под защитой, прирост в среднем 3 TB в месяц, ретеншн 30 дней. Бэкап работает в виртуальной среде и хранит копии на дисковом хранилище. Задача - выбрать модель лицензирования так, чтобы рост не превратился в постоянные доплаты.

Сценарий 1: добавили 20 ВМ и новый филиал (per workload)

В per workload расходы растут вместе с количеством защищаемых единиц. Данные могут увеличиваться умеренно, но резкий рост парка ВМ и появление филиала быстро поднимают счетчик лицензий.

Сценарий 2: расширили кластер и добавили сокеты (per socket)

Per socket удобен, когда много ВМ размещены на небольшом числе мощных хостов. Но он чувствителен к апгрейдам: добавили сокеты, расширили кластер под нагрузку - и лицензия подорожала, даже если объем бэкапа вырос незначительно.

Сценарий 3: увеличили ретеншн до 180 дней (per TB)

Per TB кажется самым очевидным, пока ретеншн не меняется. Переход с 30 до 180 дней увеличивает окно хранения в 6 раз. Даже при дедупликации рост может быть заметным: больше точек восстановления, длиннее цепочки, больше места под инкременты.

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

• Per workload - риск в росте числа ВМ, сервисов и филиалов.
• Per socket - риск в апгрейдах и расширении кластера.
• Per TB - риск в увеличении ретеншна и требований к истории восстановления.

Следующие шаги: как закрепить выбор и не переплачивать

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

Сформулируйте требования простыми словами: что именно бэкапите (ВМ, базы, файловые серверы, рабочие станции), какие RPO и RTO нужны, сколько храните копии и где они лежат (одна площадка или две, есть ли облако, есть ли отдельное хранилище для долгого хранения). Эти параметры напрямую влияют на итоговую стоимость, даже если прайс выглядит похожим.

Попросите у вендора короткое описание правил учета: что считается объектом, что считается TB, как учитывается рост, что происходит при добавлении узлов, сокетов или репозиториев. Хороший признак - 2-3 примера расчета по сценариям, похожим на ваш.

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

Минимальный план закрепления:

• Зафиксировать допущения: текущий объем, ожидаемый рост, ретеншн, число объектов.
• Проверить правила учета на одном тестовом и одном боевом сценарии.
• Записать триггеры пересмотра (например, +20% к данным или запуск новой системы).
• Назначить ответственных за ежемесячный мониторинг и квартальный пересмотр.

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