Как рассчитать и спланировать объём хранилища: практическое руководство

Четыре диска по 8 ТБ в RAID 5 дают 24 ТБ после parity, но в лучшем случае вы получите 21-22 ТБ полезной ёмкости после файловой системы. Снапшоты, резервные копии и запас под рост сократят и эту цифру. Планирование по сырой ёмкости - главная причина, по которой хранилища заканчиваются за месяцы до ожидаемого срока.

Реальный объём считают по слоям: parity RAID, накладные расходы файловой системы, снапшоты, бэкапы, headroom. Ниже формулы, числовые примеры и порядок действий для NAS на TrueNAS, сервера приложений и базы данных. Все расчёты опираются на usable capacity, а не на цифры из спецификации дисков. Материал построен как практическое руководство по capacity planning: от инвентаризации данных до подбора дисков.

Почему сырая ёмкость дисков не равна доступной: ключевые факторы потерь

Производители указывают ёмкость в десятичных единицах: 8 ТБ = 8 000 000 000 000 байт. Операционная система считает в двоичных: тот же диск отображается как 7,28 ТиБ. Расхождение в 9% редко учитывают при планировании. Дальше ёмкость уменьшают parity RAID, метаданные файловой системы, снапшоты и служебные резервы.

Чтобы понять, где теряется ёмкость, разберитесь в архитектуре программного хранилища: как связаны диски, RAID, пул, файловая система, кэш и сеть. Уровни и компоненты разобраны в статье Как устроено программное хранилище: архитектура, уровни и основные компоненты.

Для типовой конфигурации из четырёх дисков по 8 ТБ потери выглядят так: raw capacity 32 ТБ, после RAID 5 остаётся 24 ТБ, после файловой системы 21-22 ТБ, после снапшотов и запаса 18-20 ТБ usable. Половина купленной ёмкости исчезает до записи первого файла.

RAID 5 потеря ёмкости: сколько реально остаётся

RAID 5 резервирует ёмкость одного диска под parity. Формула: usable = (N - 1) × disk_size, где N - число дисков. RAID 6 резервирует два диска: usable = (N - 2) × disk_size. RAID 10 отдаёт половину: usable = N / 2 × disk_size.

RAID 5 на дисках от 4 ТБ несёт риск. Rebuild массива занимает сутки и больше, а вероятность невосстановимой ошибки чтения растёт с объёмом. Второй отказ во время перестройки приводит к потере данных. Для массивов на HDD ёмкостью 8 ТБ и выше выбирайте RAID 6 или RAIDZ2.

Команды для сборки массивов через mdadm, ZFS и LVM собраны в статье Программные RAID-массивы на Linux в 2026: практическое руководство по mdadm, ZFS и LVM.

Накладные расходы файловых систем: ZFS, ext4, XFS

Файловая система тратит ёмкость на метаданные, журналы и служебные резервы. Порядок цифр для планирования:

• ext4: 1-5%. По умолчанию 5% reserved blocks зарезервировано для root, чтобы система оставалась работоспособной при заполнении диска. Резерв уменьшают командой tune2fs -m 1, но для системных разделов оставляйте 1-2%.
• XFS: 0,5-2%. Метаданные и журнал занимают меньше места, файловая система хорошо держит большие файлы и параллельную запись.
• ZFS: до 10-12%. Пул резервирует slop space (1/32 ёмкости, около 3%), хранит метаданные и checksums, добавляет padding. ZFS требует свободного места для copy-on-write (CoW): заполнение выше 80% снижает производительность.

Пример: пул ZFS на 24 ТБ после RAIDZ2 отдаёт 21-22 ТБ usable до снапшотов. Из них около 3% занимает slop space, остальное уходит на метаданные и служебные структуры. Подробное сравнение ZFS, XFS и Btrfs с рекомендациями по сценариям есть в статье Файловые системы для СХД: ZFS, XFS, Btrfs - что выбрать в 2026.

Снапшоты и резервные копии: сколько ёмкости закладывать

Снапшоты в ZFS и Btrfs работают по принципу copy-on-write. В момент создания снапшот не копирует данные и почти не занимает места. Ёмкость расходуется, когда исходные блоки меняются: старые версии остаются в снапшоте, новые записываются в свободные блоки. Чем активнее меняются данные и чем дольше живут снапшоты, тем больше места они занимают.

Формула оценки: объём снапшотов ≈ скорость изменения данных × retention × коэффициент. Коэффициент учитывает фрагментацию и перезапись одних и тех же блоков. Для баз данных берите 1,0-1,5, для файловых хранилищ с документами 0,3-0,7.

Пример: сервер ежедневно меняет 1 ТБ данных, retention снапшотов 7 дней. Объём: 1 ТБ × 7 × 1,0 = 7 ТБ. При retention 30 дней снапшоты займут до 30 ТБ. Для пула на 24 ТБ это больше, чем сами данные.

Резервные копии на том же пуле удваивают требования к ёмкости и не защищают от отказа массива. Правило 3-2-1: три копии данных, два разных носителя, одна копия вне основной площадки. Бэкапы не должны конкурировать с рабочей нагрузкой: выбирайте backup window в часы низкой активности. Если второй пул разворачивать негде, часть копий храните в облаке. Для бэкапов и холодных данных подойдут диски и объектное хранилище Timeweb Cloud с оплатой по факту использования.

Как retention policy влияет на объём снапшотов

Retention policy определяет, сколько версий данных вы храните. Схема с ежедневными, еженедельными и ежемесячными снапшотами растягивает хранение версий на год и больше.

Расчёт для датасета с изменениями 200 ГБ в день:

• retention 7 дней: до 1,4 ТБ;
• retention 30 дней: до 6 ТБ;
• retention 90 дней: до 18 ТБ.

Настраивайте разные политики для разных датасетов. Для базы данных с интенсивной записью держите retention 3-7 дней, для архивов документов 90-365 дней. Фактический расход покажет команда zfs list -t snapshot -o name,used.

Дедупликация и сжатие: когда они экономят, а когда вредят

Дедупликация ZFS хранит таблицу DDT в оперативной памяти. На каждый терабайт данных нужно 1-5 ГБ RAM в зависимости от размера блоков. Без запаса памяти дедупликация замедляет пул. Включайте её после тестов на реальных данных и только там, где много одинаковых блоков: клоны виртуальных машин, повторяющиеся резервные копии.

Сжатие работает предсказуемее. LZ4 в ZFS даёт 1,2-2x на текстах, логах и исходном коде, но почти ничего не экономит на медиафайлах, архивах и зашифрованных данных. ZSTD сжимает сильнее, но требует больше CPU. Планировать ёмкость в расчёте на дедупликацию или сжатие без замеров нельзя: коэффициент может оказаться равен 1,0.

Запас под рост данных и пиковые нагрузки: формула headroom

Хранилище, заполненное под завязку, деградирует. ZFS при заполнении выше 80% тратит больше времени на поиск свободных блоков для copy-on-write. RAID-массивы на HDD теряют производительность из-за фрагментации. Проектируйте хранилище так, чтобы рабочие данные занимали не более 70-80% usable capacity.

Формула расчёта с запасом:

required_usable = current_data × (1 + growth_rate)^years / 0,8

Пример: сейчас 10 ТБ данных, рост 30% в год, горизонт 3 года. Считаем: 10 × 1,3^3 = 22 ТБ. Делим на 0,8: 27,5 ТБ usable. Округляем до 28 ТБ. Столько должна давать конфигурация после RAID, файловой системы и снапшотов.

Как оценить скорость роста данных

Прогноз (forecast) строят на метриках. Собирайте данные о занятой ёмкости 3-6 месяцев: ежедневные замеры df или zpool list. Линейный тренд подходит для стабильных файловых хранилищ, экспоненциальный для сервисов, где объём растёт вместе с числом пользователей.

Ориентир: рост 5% в месяц удваивает объём примерно за 14 месяцев (72 / 5 ≈ 14). Рост 10% в месяц даёт удвоение за 7 месяцев. Учитывайте сезонность и планы: миграцию, запуск нового сервиса, изменение политики хранения логов.

Автоматизировать анализ трендов можно с помощью ИИ-моделей. Выгрузки метрик и логи удобно передавать через единый API: агрегатор AiTunnel открывает доступ к GPT, Gemini и Claude без VPN и с оплатой в рублях.

Пиковые нагрузки: логи, временные файлы, миграции

Средний рост не описывает пики. Логи веб-сервера при инциденте вырастают с 5 ГБ до 50 ГБ в сутки. Миграция базы данных создаёт временную копию до размера исходной базы. CI-задачи и сборка контейнеров оставляют кэш, который никто не чистит.

Расчёт: логи с суточным объёмом 20 ГБ и retention 30 дней требуют минимум 600 ГБ. Временные файлы базы на 500 ГБ удваивают требования на время миграции. Отдельный датасет или пул под временные данные упрощает контроль: его можно быстро расширить или очистить без риска для основных данных.

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

Пошаговая методика расчёта: от требований до конфигурации дисков

Порядок расчёта:

1. Определите текущий объём данных по типам нагрузки: файлы, базы, виртуальные машины, логи.
2. Спрогнозируйте рост на 2-3 года по метрикам и планам развития.
3. Выберите retention снапшотов и политику бэкапов, посчитайте их объём.
4. Сформулируйте требования к производительности и надёжности для выбора RAID и файловой системы.
5. Переведите требования в raw capacity: разделите нужный usable объём на коэффициент эффективности конфигурации.
6. Проверьте запас: рабочие данные занимают не более 80% итоговой ёмкости.

Пример расчёта для NAS на TrueNAS с ZFS

Исходные данные: 10 ТБ файлов, рост 20% в год, горизонт 3 года, снапшоты с retention 30 дней, ежедневные изменения 50 ГБ, бэкапы на отдельном пуле.

Шаг 1. Данные через 3 года: 10 × 1,2^3 = 17,3 ТБ.

Шаг 2. Снапшоты: 50 ГБ × 30 = 1,5 ТБ.

Шаг 3. Итого с запасом 20%: (17,3 + 1,5) / 0,8 = 23,5 ТБ usable.

Шаг 4. Конфигурация: 6 дисков по 8 ТБ в RAIDZ2. Сырая ёмкость 48 ТБ, после parity 32 ТБ, после накладных расходов ZFS около 28,8 ТБ. Рабочие данные со снапшотами (18,8 ТБ) займут 65% пула. Правило 80% выполняется. Вариант из 4 дисков по 8 ТБ в RAIDZ2 даёт всего 14,4 ТБ usable и не подходит.

Практическая сборка такого массива на TrueNAS описана в руководстве Сборка и настройка дискового массива для бизнеса и лаборатории: TrueNAS, OMV или готовый NAS.

Пример расчёта для сервера базы данных

PostgreSQL хранит данные, WAL-журнал, временные файлы сортировок и старые версии строк до VACUUM. Формула грубой оценки: объём диска = размер данных × 1,5 + WAL.

Пример: база 500 ГБ, WAL 20 ГБ в час при пиковой нагрузке. Расчёт: 500 × 1,5 = 750 ГБ под данные и временные файлы. WAL на отдельном быстром пуле: 3-4 часа журнала, то есть 60-80 ГБ. Итого около 850 ГБ. С запасом 20% нужно 1 ТБ usable. Для NVMe это два диска по 1 ТБ в mirror.

MySQL с InnoDB хранит данные в ibdata и табличных пространствах, а изменения пишет в redo log. Расчёт похож: размер данных × 1,3-1,5 плюс журналы. Учитывайте binlog, если настроена репликация: он может занимать десятки гигабайт.

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

Сравнение RAID и ФС по эффективности ёмкости

Таблица показывает, какую долю сырой ёмкости отдают разные конфигурации и какие компромиссы предлагают.

RAIDZ2 и RAID 6 близки по эффективности, но ZFS добавляет checksums и self-healing: система находит повреждённые блоки и восстанавливает их по копиям на других дисках. Аппаратные RAID-контроллеры так не умеют.

ext4 проще в обслуживании и предсказуемее по метаданным. XFS лучше держит большие файлы и параллельную запись, поэтому подходит для медиахранилищ и бэкапов. Btrfs даёт снапшоты и сжатие на уровне файловой системы, но уступает ZFS по зрелости инструментов восстановления. Для новых проектов под NAS и базы данных выбирайте ZFS, для простых файловых серверов достаточно ext4 или XFS.

Накладные расходы (overhead) файловой системы и RAID складываются. Считайте итоговую эффективность как произведение: например, RAIDZ2 даёт 0,67, ZFS оставляет 0,9, итог 0,6 от сырой ёмкости.

Когда mirror выгоднее RAIDZ

Mirror отдаёт только 50% полезной ёмкости, и на первый взгляд это дорого. Выгода проявляется при высокой нагрузке на запись: базы данных, виртуальные машины, контейнеры. Зеркала дают высокий IOPS, быстрый rebuild (копируется один диск, а не пересчитывается parity всего массива) и предсказуемую задержку.

RAIDZ2 выигрывает по ёмкости: 6 дисков по 8 ТБ дают 32 ТБ после parity против 24 ТБ у трёх зеркал. Для файлового архива или хранилища бэкапов это решающий аргумент. Для базы данных с тысячами транзакций в секунду mirror окупается производительностью и временем восстановления.

Типичные ошибки при планировании хранилища

• Планирование по raw capacity. Покупка дисков по принципу «32 ТБ хватит» без учёта RAID и файловой системы. Результат: usable ёмкость на 30-40% меньше ожидаемой.
• Отсутствие запаса. Пулы, заполненные под 95-100%, теряют производительность и не оставляют места для служебных операций.
• Игнорирование снапшотов. Снапшоты с длинным retention на активно меняющихся данных занимают больше места, чем сами данные.
• Дедупликация без тестов. Включение dedup без достаточного объёма RAM и проверки на реальных данных снижает производительность пула.
• Бэкапы на том же пуле. Копии занимают ёмкость и не защищают от отказа массива. Размещайте их на отдельном пуле или в облаке.
• Недооценка метаданных ZFS. Расчёт по формуле (N-2) × disk_size без учёта slop space и метаданных завышает ожидания на 10-12%.

Чем опасно 100% заполнение ZFS

ZFS использует copy-on-write: новые данные записываются в свободные блоки, старые освобождаются после фиксации транзакции. Когда свободного места почти нет, системе негде размещать новые блоки и метаданные. Производительность падает задолго до 100%: при заполнении 90% пул работает заметно медленнее. При полном заполнении пул переходит в режим только для чтения, и запись останавливается.

Держите заполнение пула ZFS в пределах 80%. Планируйте ёмкость с запасом 20-30% и настройте алерты на порог 75-80%. Деградация производительности (performance degradation) при заполнении выше 80% касается и RAID-массивов на HDD.

Игнорирование снапшотов при расчёте

Снапшоты незаметно занимают ёмкость. Пример: пул на 20 ТБ с базой данных, где ежедневно меняется 500 ГБ. Снапшоты с retention 30 дней займут до 15 ТБ, то есть 75% пула. Без мониторинга ситуация обнаруживается, когда пул заполнен.

Контроль: команда zfs list -t snapshot -o name,used,creation показывает расход по каждому снапшоту. Настройте автоматическое удаление по расписанию и проверяйте топ-10 снапшотов по объёму раз в месяц.

Проверка фактического расхода: команды и инструменты

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

• df -h показывает занятое и доступное место по смонтированным файловым системам;
• du -sh /path считает объём каталога, ncdu даёт интерактивный обзор и помогает найти крупные файлы;
• zpool list выводит сырую ёмкость (SIZE), распределённый объём (ALLOC), свободное место (FREE) и процент заполнения (CAP);
• zfs list показывает USED, AVAIL и REFER по датасетам;
• smartctl -a /dev/sdX читает SMART-атрибуты и помогает заметить деградацию диска до отказа.

Как читать zfs list и zpool list

zpool list показывает физический уровень, zfs list - логический. В zpool list колонка SIZE содержит сырую ёмкость всех дисков, включая parity. В zfs list колонка AVAIL показывает, сколько места доступно датасетам с учётом резервов, снапшотов и квот.

Пример: массив из шести дисков по 8 ТБ. zpool list показывает SIZE 48 ТБ и CAP 65%. zfs list показывает AVAIL 11 ТБ: с учётом parity, снапшотов и служебных резервов датасетам доступно меньше, чем FREE из zpool list. Если AVAIL опускается ниже 15-20% полезной ёмкости, планируйте расширение или чистку снапшотов.

Чек-лист планирования хранилища

1. Соберите текущий объём данных по категориям: файлы, базы, виртуальные машины, логи, архивы.
2. Постройте прогноз роста на 3 года по метрикам за 3-6 месяцев.
3. Определите retention снапшотов и посчитайте их объём по формуле «изменения × срок хранения».
4. Выберите политику бэкапов: 3-2-1, отдельный пул или облако.
5. Подберите RAID и файловую систему под нагрузку: IOPS, объём, надёжность.
6. Посчитайте raw capacity: разделите требуемый usable объём на эффективность конфигурации.
7. Проверьте запас: заполнение не выше 80% для ZFS, 85-90% для ext4 и XFS.
8. Настройте мониторинг и алерты на пороги заполнения.

Итоговая формула: raw_capacity = (current_data × (1 + growth)^years + snapshots + backups) / (efficiency × 0,8), где efficiency - доля полезной ёмкости после RAID и файловой системы.

Частые вопросы

Сколько ёмкости теряется на RAID 5?

RAID 5 резервирует ёмкость одного диска под parity. Для 4 дисков по 8 ТБ: 24 ТБ после parity, 21-22 ТБ после файловой системы. Для 6 дисков по 8 ТБ: 40 ТБ после parity, 36-37 ТБ с файловой системой. Учитывайте риск rebuild на больших HDD: выбирайте RAID 6 или RAIDZ2.

Как рассчитать объём хранилища для ZFS?

Формула: usable = (raw capacity - parity) × 0,9 - снапшоты - запас. Для 6 дисков по 8 ТБ в RAIDZ2: 48 ТБ raw, 32 ТБ после parity, 28,8 ТБ после метаданных и slop space. Вычитаем снапшоты (например, 3 ТБ) и оставляем 20% запаса: около 20 ТБ для рабочих данных.

Нужно ли учитывать снапшоты при планировании?

Да. Снапшоты ZFS и Btrfs занимают реальное место при изменении данных. Объём оценивают как скорость изменений × retention. Для базы данных с 200 ГБ изменений в день и retention 7 дней закладывайте минимум 1,4 ТБ.

Какой запас ёмкости оставлять?

Для ZFS 20-30% свободного места, чтобы copy-on-write и метаданные работали без деградации. Для ext4 и XFS достаточно 10-15%, системные разделы лучше держать с запасом 20%. Пиковые нагрузки, миграции и логи могут временно занять больше.

Можно ли использовать дедупликацию для экономии ёмкости?

Только после тестов. Дедупликация ZFS требует 1-5 ГБ RAM на терабайт данных и эффективна на данных с большим числом одинаковых блоков: клоны виртуальных машин, повторяющиеся резервные копии. На разнородных файлах коэффициент близок к 1,0, а расход памяти остаётся высоким.

Как проверить фактический расход ёмкости?

Используйте df -h для общего обзора, du -sh и ncdu для поиска крупных каталогов, zfs list и zpool list для ZFS, smartctl для состояния дисков. Сверяйте факт с прогнозом раз в месяц и корректируйте план.

Вывод

Реальный объём хранилища определяется usable capacity, а не цифрами на дисках. Считайте по слоям: вычитайте parity RAID, накладные расходы файловой системы, снапшоты и бэкапы, затем оставляйте 20-30% запаса под рост и пики. Для NAS на ZFS с 10 ТБ данных и ростом 20% в год подходит массив из шести дисков по 8 ТБ в RAIDZ2: он даёт около 29 ТБ usable.

Следующий шаг: проверьте текущее хранилище командами zpool list, zfs list и df -h, сравните фактический рост с прогнозом и пересчитайте план. Если часть данных перерастает локальные диски, выносите холодные копии в облако или на отдельные пулы.