Как рассчитать размеры систем хранения под бэкапы и архивы: формулы, примеры и чек-лист

Введение: почему расчёт СХД не сводится к умножению объёма на количество копий

Компания с 10 ТБ рабочих данных и ежедневными бэкапами занимает под копии 50-100 ТБ за год. Разрыв в два раза объясняется не ошибкой арифметики: на результат влияют политика хранения, глубина архива, тип копий, сжатие и дедупликация.

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

Расчёт ломают три вещи. Рост данных считают линейным, хотя за год массив прирастает на 20-40% из-за логов, снапшотов и новых сервисов. Служебные расходы RAID, файловой системы и снапшотов съедают 20-30% сырой ёмкости. Дедупликация, включённая без запаса оперативной памяти, роняет скорость записи в разы.

Дальше по шагам: сбор исходных данных, формула ёмкости, выбор носителя и массива, подсчёт отсеков, масштабирование и два готовых расчёта для малого и среднего бизнеса. Базовая методика планирования полезной ёмкости разобрана в отдельном руководстве по расчёту объёма хранилища с учётом RAID, ZFS, ext4 и снапшотов.

Шаг 1: Сбор исходных данных для расчёта

Семь параметров задают весь дальнейший расчёт. Без них оценка «на глаз» расходится с реальностью в полтора-два раза.

• Объём защищаемых данных. Файловые ресурсы, базы и виртуальные машины считают отдельно: у них разный коэффициент сжатия.
• Скорость роста. 10-20% в год для файловых хранилищ, 20-40% для сред с виртуализацией и активной разработкой.
• Глубина хранения. Сколько дней держатся ежедневные копии, месяцев - недельные и месячные, лет - годовые архивы.
• Расписание копий. Схема GFS («дед, отец, сын») с полными и инкрементными заданиями.
• RPO и RTO. Допустимая потеря данных и время восстановления задают частоту копий и число потоков записи.
• Защита от изменения. Неизменяемые копии (WORM), офлайн-копия или лента против шифровальщиков.
• Внешние требования. Сроки хранения по отраслевым нормам и внутренним регламентам.

Пример сбора данных для компании, которая защищает 5 ТБ файлов и виртуальных машин:

Если объём данных неизвестен, его снимают с файловой системы (zfs list, df -h) и с системы резервного копирования, после чего берут большее из двух значений. Разница между ними обычно показывает, что часть данных не защищена или что в индексе бэкапов лежит мусор.

Шаг 2: Расчёт требуемой ёмкости с учётом политики хранения

Методика укладывается в пять действий.

1. Посчитать объём одной полной копии (V).
2. Умножить его на количество полных копий за период хранения (Kf).
3. Добавить суммарный объём инкрементов (Vi), обычно 10-20% от объёма полных копий.
4. Разделить результат на коэффициенты сжатия и дедупликации (Kc и Kd).
5. Умножить на запас 1,2-1,3 под служебные расходы и рост.

Требуемая ёмкость = (V × Kf + Vi) / (Kc × Kd) × 1,25

Расчёт на данных из шага 1. Полных копий за период: 4 недельных и 12 месячных, итого 16. Их объём: 16 × 5 ТБ = 80 ТБ. Ежедневные инкременты по 50 ГБ за 30 дней дают 1,5 ТБ. Сумма до сжатия: 81,5 ТБ. Запас 25% добавляет ещё 20 ТБ.

Итог без сжатия: около 102 ТБ сырой ёмкости. Сжатие LZ4 или ZSTD на уровне пула (Kc = 2) снижает расчёт до 51 ТБ. Дедупликация блоков между однотипными месячными копиями добавляет ещё 1,5-2x, и требуемый объём опускается к 30 ТБ. Верхнюю границу экономии берут из замеров, а не из паспортных обещаний.

Учёт инкрементальных и дифференциальных бэкапов

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

Ежедневный инкремент в 5% от полного объёма за 30 дней накапливает 1,5 полных копии. Тот же месяц с инкрементом 10% даёт уже 3 копии, и на массиве в 5 ТБ данных разница составляет 7,5 ТБ. Цепочки без синтетических полных копий растягиваются, а вместе с ними растёт и объём: повреждение одной дельты обнуляет всю цепочку, поэтому недельные полные копии остаются обязательными.

Практическое правило: в расчёт закладывают инкременты как 10-20% от объёма полных копий, а не как 5%, если нет статистики по реальным дельтам за прошлый период.

Как сжатие и дедупликация меняют расчёт

Коэффициенты зависят от типа данных. Логи, текст, JSON, исходный код и базы с повторяющимися записями ужимаются в 1,5-2,5x. Фото, видео, уже сжатые архивы и сжатые бэкапы дают 1,0-1,1x, то есть почти ничего.

В ZFS сжатие включают на уровне датасета, и работает оно почти без затрат ресурсов: LZ4 и ZSTD дают 1,5-2x на офисных данных при падении производительности в пределах 1-3%. Уровень ZSTD 3 ужимает сильнее, но заметнее нагружает процессор.

Дедупликация в ZFS сравнивает блоки по таблице DDT. На каждый терабайт дедуплицируемых данных планируют от 1 до 5 ГБ RAM: при нехватке памяти таблица выталкивается на диск, и запись в пул замедляется в разы. Парк одинаковых виртуальных машин даёт 5-10x, архивы уникальных документов - 1,1-1,3x. В OpenZFS 2.3 и новее появилась быстрая дедупликация (fast dedup), которая снижает нагрузку на память, но замеры перед включением остаются обязательными.

Порядок проверки: создать тестовый датасет, скопировать 100-200 ГБ реальных данных, снять zfs get compressratio и dedupratio, и только после этого строить расчёт. Включение дедупликации на готовом пуле без замера - прямой путь к просадке скорости.

Шаг 3: Выбор типа носителей и архитектуры СХД

Для бэкапов и архивов носитель выбирают по стоимости терабайта и сроку службы, а не по скорости.

Диски одного размера в массиве упрощают замену: горячий резерв и подменный диск нужны одной модели. Разнобой по ёмкости в одном vdev ZFS съедает полезное место до размера самого маленького диска.

Ленточные библиотеки: когда они оправданы

Картридж LTO-9 держит 18 ТБ без сжатия и до 45 ТБ при сжатии 2,5:1. Архив в 100 ТБ закрывают 6 картриджей. Экономика ленты простая: картридж стоит $100-150, то есть $6-8 за терабайт, тогда как HDD обходится в $15-20 за терабайт.

Библиотека на 8 слотов начинается от $5000, картриджи докупаются по мере роста архива. Потребление такой библиотеки 50-100 Вт против 300-500 Вт у стойки с дисками: для холодного архива экономия электричества за 5 лет покрывает часть стоимости оборудования.

Ограничения тоже конкретные. Доступ к файлу занимает минуты, потому что робот ищет картридж и позиционирует головку. Каждые 6-12 месяцев нужна проверка: чтение контрольных сумм и перезапись деградировавших картриджей. Заявленный срок службы 15-30 лет выполняется в климате 18-25 °C и влажности 40-60%, в сыром подвале лента деградирует за пару лет. Для доступа к архиву как к файловой системе используют LTFS, для защиты от шифровальщиков - режим WORM.

Лента выигрывает при глубине архива от 3-5 лет и объёме от 20-30 ТБ. Для меньших архивов массив HDD дешевле с учётом трудозатрат на работу с роботом и каталогом.

JBOD vs RAID: что выбрать для бэкапов

JBOD объединяет диски в пул без защиты данных. Десять дисков по 10 ТБ дают 100 ТБ полезной ёмкости, но отказ одного диска разрушает весь vdev. RAIDZ2 на тех же десяти дисках даёт 80 ТБ и переживает отказ двух дисков одновременно. RAIDZ1 на 8 дисках по 10 ТБ даёт 70 ТБ и держит один отказ.

Для целевого массива бэкапов выбирают RAIDZ2 или RAID6: восстановление важнее, чем 20-30% ёмкости. JBOD уместен как второй уровень за лентой, при репликации в облако или когда данные на нём можно пересобрать из другого источника. Единственная копия на JBOD недопустима.

Пул ZFS держат заполненным не более чем на 80%. Дальше растёт фрагментация, страдает производительность записи, а восстановление после отказа занимает часы. Уровни хранения hot, warm, cold и archive помогают развести задачи по разным носителям и не платить за быстрые диски там, где нужен только объём: проектирование информационной системы хранения данных с расчётом IOPS, ёмкости и уровней хранения.

Шаг 4: Расчёт количества отсеков и форм-фактора

Количество отсеков считают от числа дискомест, а не от полезной ёмкости. Формула: отсеки = число дисков + запас 25-30% на расширение. Полезная ёмкость RAIDZ2 считается как (N - 2) × объём диска.

Пример: нужно 100 ТБ полезной ёмкости, диски по 16 ТБ, уровень RAIDZ2. (9 - 2) × 16 = 112 ТБ. Значит, 9 дисков плюс 3 свободных отсека на рост, итого сервер на 12 отсеков форм-фактора 3.5".

Форм-фактор 3.5" (LFF) подходит для HDD ёмкостью от 16 ТБ, формат 2.5" (SFF) - для SSD и быстрых кэшей. В один и тот же 2U корпус помещается либо 12 дисков 3.5", либо 24 диска 2.5": выбор зависит от того, что нужнее, объём или IOPS. Подробнее о плотности и физических размерах: габариты СХД и плотность хранения в ТБ на юнит стойки и классификация форм-факторов 1U, 2U, 4U и напольных корпусов.

Физику тоже считают заранее. 12 дисков по 16 ТБ выделяют 150-200 Вт тепла и требуют 6-8 корпусных вентиляторов. Полка 4U с 36 дисками даёт до 500 Вт тепла, и без приточной вентиляции или кондиционера в серверной она перегреется: диски выше 45 °C служат заметно меньше заявленных 5 лет.

Шаг 5: Масштабирование без замены оборудования

Запас на старте дешевле переезда. Разница между корпусом на 8 и на 12 отсеков составляет $200-400, а перенос 80 ТБ данных на новый массив занимает выходные и требует окна простоя.

• Корпус с запасом отсеков. 12 отсеков на старте вместо 8 закрывают рост на 2-3 года.
• Backplane с поддержкой SAS-экспандера. Одна HBA на 8 портов плюс экспандер обслуживают 24 диска; без экспандера каждый новый диск требует свободного порта.
• Расширение пула ZFS новыми vdev. Пул на одном RAIDZ из 6 дисков расширяют вторым vdev, а не заменой дисков по одному. Добавление vdev идёт онлайн, данные не переливаются.
• Внешние полки JBOD по SAS. 12-24 диска на полку, до 4-8 полок на один HBA: ёмкость растёт без замены сервера.
• Ленточная библиотека. Расширяется добавлением слотов и драйвов, простаивающие слоты не мешают работе.
• Облако как второй уровень. Копию за пределами площадки удобно держать в объектном хранилище: Timeweb Cloud даёт S3-совместимое хранилище и серверы, которые масштабируются по ресурсам без закупки железа.

Пример из практики: сервер 2U на 12 отсеков, занято 9 дисков в RAIDZ2 (112 ТБ полезной ёмкости). Через год добавляют полку JBOD по SAS и создают новый vdev из 6 дисков: пул растёт без простоя и без переноса данных. Если бы корпус был заполнен полностью, пришлось бы строить второй массив и копировать на него 80 ТБ, а это сутки на гигабитной сети.

Копии стоит раскладывать по правилу 3-2-1: три экземпляра данных, два типа носителей, один экземпляр вне основной площадки. Проверка восстановления раз в квартал показывает, что бэкап живой, а не просто занимает место. Практические схемы сбора массива и проверки восстановления собраны в руководстве по сборке и настройке дискового массива на TrueNAS, OpenMediaVault или готовом NAS.

Типичные ошибки при планировании ёмкости

1. Недооценка роста данных. Расчёт под текущие 5 ТБ без коэффициента роста даёт дефицит уже через 8-12 месяцев. Базовый ориентир: 15-20% в год для файлов и 30-40% для виртуализации.
2. Игнорирование служебных расходов. RAID, метаданные ZFS, снапшоты и порог заполнения 80% вместе съедают до трети сырой ёмкости. Массив из 10 дисков по 16 ТБ даёт не 160 ТБ, а около 90 ТБ под бэкапы.
3. Неверный расчёт RAID. В RAIDZ1 на 8 дисках полезно 7 дискомест, в RAIDZ2 на 10 дисках - 8. Ошибка на один диск при планировании оборачивается нехваткой 16 ТБ.
4. Отсутствие проверки восстановления. Копия без тестового восстановления не подтверждает ничего. Раз в квартал восстанавливают один сервер или базу целиком.
5. Дедупликация без RAM. Таблица DDT требует 1-5 ГБ памяти на терабайт данных. Включение дедупликации на 50 ТБ при 64 ГБ RAM роняет запись в разы.
6. Диски без запаса и резерва. Покупка дисков ровно под расчёт не оставляет места под горячий резерв и расширение. Один подменный диск нужен всегда.
7. Неучёт срока службы носителей. HDD живёт 3-5 лет, лента 15-30. Пятилетний архив на дисках требует плановой замены парка, и это закладывают в бюджет заранее.
8. Один пул под всё. Бэкапы, архив и рабочие снапшоты в одном пуле конкурируют за производительность. Разные уровни данных лучше разводить по пулам и носителям.

История, которая повторяется в малом бизнесе: купили массив на 10 ТБ, через год данные выросли до 15 ТБ, докупали диски в спешке по завышенной цене и перестраивали пул в рабочее время. Запас 25-30% на старте стоит дешевле такой операции.

Практические примеры расчётов для малого и среднего бизнеса

Пример 1: малый бизнес, 2 ТБ данных

Файловый сервер и одна база, 15 сотрудников. Хранение: ежедневные инкременты 30 дней, месячные полные копии 12 месяцев, годовых архивов нет.

Решение: 4 диска по 10 ТБ в RAIDZ1 дают 30 ТБ полезной ёмкости, из которых с учётом порога 80% доступно около 24 ТБ. Затраты: около $600 за диски плюс $800-1200 за корпус или мини-сервер и $150-300 за одну HBA. Годовая месячная копия дополнительно уезжает в облако или на внешний диск, который хранится не рядом с сервером.

Пример 2: средний бизнес, 20 ТБ данных

Парк из 40 виртуальных машин, базы данных, файловое хранилище. Хранение: ежедневные инкременты 90 дней, недельные полные 26 недель, годовые архивы 5 лет.

Прямой расчёт без дедупликации: 26 × 20 = 520 ТБ недельных копий, 5 × 20 = 100 ТБ годовых, 90 × 0,6 = 54 ТБ инкрементов. Итого около 674 ТБ, и такая политика нереализуема на разумном бюджете. Рабочий вариант: инкрементальные цепочки с синтетическими полными копиями и дедупликацией на уровне образов виртуальных машин.

Решение по дискам: 12 дискомест по 16 ТБ в RAIDZ2 дают 160 ТБ полезной ёмкости и около 128 ТБ доступных при заполнении 80%. Годовые архивы уезжают на ленту: 5 копий по 20 ТБ закрывают 6 картриджей LTO-9 в библиотеке на 8 слотов. Бюджет: HDD 12 × $300 = $3600, корпус или сервер на 12 отсеков $3000-5000, HBA $200-400, ленточная библиотека от $5000, картриджи $600-900. Итого $12-15 тыс. без облачной копии.

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

Чек-лист для расчёта СХД

1. Собрать исходные данные: объём, скорость роста, глубину хранения, расписание копий, RPO и RTO, требования к неизменяемости.
2. Посчитать объём полных копий за весь период хранения и добавить 10-20% на инкременты.
3. Разделить объём на коэффициенты сжатия и дедупликации, подтверждённые замером, а не паспортом.
4. Добавить запас 25-30% на служебные расходы, порог заполнения 80% и рост данных.
5. Выбрать носитель: HDD для основного массива, ленту для архива от 3-5 лет и объёма от 20-30 ТБ, облако для копии вне площадки.
6. Определить уровень RAID: RAIDZ2 или RAID6 для целевого массива бэкапов, JBOD только как второй уровень.
7. Посчитать отсеки как число дисков плюс запас 25-30% и выбрать форм-фактор 3.5" или 2.5".
8. Заложить масштабирование: свободные отсеки, SAS-экспандер, возможность добавить vdev и полку.
9. Проверить память под дедупликацию: 1-5 ГБ RAM на терабайт данных.
10. Запланировать тестовое восстановление раз в квартал и обновление носителей по сроку службы.

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