ZFS хранит данные в vdev: это группа дисков с единым типом избыточности. Пул (zpool) собирается из одного или нескольких vdev и служит контейнером для датасетов. Отказоустойчивость определяется на уровне vdev, поэтому пул переживает отказ только избыточных групп, а одиночный диск, добавленный в пул, становится точкой отказа всего массива.
Порядок планирования такой: выбрать тип vdev и число дисков в нём, затем решить, сколько таких групп объединить в пул. Mirror и raidz2 в 2026 году остаются основными топологиями, dRAID и special vdev применяют точечно, под конкретную нагрузку.
Ниже: три уровня абстракции ZFS, сравнение mirror и raidz по IOPS и ёмкости, готовые команды zpool create, разбор вывода zpool status, ошибки при добавлении vdev и чек-лист приёмки массива.
Что такое vdev и как ZFS физически раскладывает массив по дискам
Путь данных в ZFS описывается тремя уровнями. ZFS распределяет блоки между vdev пула, а внутри vdev - между дисками по правилам выбранной топологии.
Пул, vdev и диск: три уровня абстракции ZFS
- Диск (leaf): физический носитель, подключённый напрямую, обычно через HBA в режиме IT или JBOD.
- vdev: группа дисков с одним типом избыточности: mirror, raidz1/2/3, dRAID или одиночный диск (stripe).
- zpool: контейнер из одного или нескольких vdev, внутри которого создаются датасеты, zvol и снапшоты.
Числа помогают не путать уровни. Четыре диска, собранные в два зеркала по два диска, дают один пул, два vdev и четыре листовых устройства. Полезная ёмкость равна сумме ёмкостей двух зеркал, то есть примерно половине сырой ёмкости дисков.
Главное правило: потеря одного vdev означает потерю всего пула, если внутри этого vdev не хватило избыточности. Пул из raidz2 и mirror уцелеет при отказе дисков внутри любой из групп, пул из raidz2 и одиночного диска - нет. Слои пулов, датасетов и снапшотов разобраны в материале ZFS как основа системы хранения: пулы, датасеты и снапшоты на практике.
Почему ZFS не любит аппаратный RAID
Аппаратный RAID-контроллер прячет отдельные диски за одним логическим томом. ZFS в такой схеме не видит, какой диск вернул ошибку чтения, и не может ни пересчитать блок по чётности, ни восстановить данные на конкретный носитель.
Механизмы ZFS рассчитаны на прямой доступ к дискам. Контрольные суммы хранятся отдельно от блоков, copy-on-write исключает частичную перезапись, а resilver восстанавливает только занятые блоки. Если массив отдаёт один виртуальный том, эти механизмы теряют смысл, и самовосстановление не работает.
Рабочая практика: HBA в режиме IT или JBOD (например, платы на чипах LSI SAS3008 и новее с прошивкой IT). Кэш и батарея RAID-контроллера в этой схеме не нужны: целостность обеспечивает ZFS, а не железо. В TrueNAS такой режим стал стандартным требованием при сборке пулов.
Mirror vs raidz: чем отличаются типы vdev и что выбрать
Разница между топологиями сводится к трём величинам: полезная ёмкость, число случайных операций в секунду и время восстановления после замены диска.
| Тип vdev | Минимум дисков | Полезная ёмкость | Отказ дисков | IOPS (упрощённо) | Resilver |
|---|---|---|---|---|---|
| mirror | 2 | 50% | все, кроме последнего | сумма IOPS дисков | быстрый |
| raidz1 | 3 | (n-1)/n | 1 | уровень одного диска | средний |
| raidz2 | 4 | (n-2)/n | 2 | уровень одного диска | медленнее |
| raidz3 | 5 | (n-3)/n | 3 | уровень одного диска | самый медленный |
Ёмкость в цифрах: raidz1 из четырёх дисков по 8 ТБ даёт около 24 ТБ до накладных расходов на чётность и метаданные, а mirror из тех же четырёх дисков - около 16 ТБ. Плата за IOPS и скорость восстановления измерима и предсказуема.
Когда mirror лучше raidz
Зеркала выбирают там, где важны случайные операции записи и стабильная задержка: PostgreSQL и MySQL, диски виртуальных машин, iSCSI и NFS под нагрузкой, очереди сообщений. Чтение распределяется между дисками зеркала, поэтому пропускная способность и число операций растут вместе с числом дисков в группе, а не упираются в один носитель.
Расширение тоже гибче: к пулу добавляют новые mirror-vdev, и пул получает и ёмкость, и IOPS. Пример: четыре NVMe в двух зеркалах дадут заметно больше операций записи, чем raidz1 из тех же четырёх накопителей, при вдвое меньшей полезной ёмкости.
Когда raidz2 - разумный компромисс
raidz2 переживает отказ любых двух дисков в группе. Это критично при больших накопителях: восстановление raidz на дисках 16 ТБ и выше идёт долго, и вероятность второго отказа за это время уже нельзя игнорировать.
Типовые сценарии: файловое хранилище, SMB-шары, медиатека, бэкапы, домашняя лаборатория. Схема из шести дисков по 4 ТБ в raidz2 даёт около 16 ТБ полезной ёмкости и защиту от двух отказов. raidz1 на дисках больше 4 ТБ в новых пулах 2026 года выбирать не стоит: второй отказ во время resilver оставляет массив без данных.
dRAID и special vdev: что актуально в 2026 году
dRAID - распределённый вариант RAIDZ, в котором чётность и резервные блоки размазаны по всем дискам. Восстановление идёт быстрее за счёт параллельной записи и зарезервированной ёмкости, поэтому схема интересна на очень больших пулах в десятки дисков. Технология появилась в OpenZFS 2.1.0, а в TrueNAS SCALE её добавили в версии 23.10 (Cobia) (OpenZFS - The Final Word in File Systems). Создание dRAID доступно в Pool Creation Wizard: по умолчанию мастер выделяет минимум 10 дисков под dRAID-vdev, а при меньшем числе дисков документация TrueNAS прямо рекомендует RAIDZ ради лучшей производительности и эффективного использования ёмкости (Pool Creation Wizard | TrueNAS Documentation Hub). Поддержка в графических интерфейсах при этом остаётся ограниченной, поэтому перед проектом проверьте возможности вашей версии TrueNAS.
special vdev хранит метаданные и мелкие блоки на быстрых SSD. Он ускоряет обход каталогов, снапшоты и мелкие операции, но становится обязательной частью пула. Документация OpenZFS требует, чтобы избыточность special vdev соответствовала избыточности остальных обычных устройств пула или превышала её (zpoolconcepts.7 — OpenZFS documentation); на практике это означает зеркало минимум из двух SSD. Прямого утверждения, что потеря special vdev без зеркала гарантированно уничтожает весь пул, в проверенных источниках нет, но при отказе единственного special-устройства метаданные и мелкие блоки становятся недоступны, поэтому закладывать его без зеркала нельзя. Порог для мелких блоков задавайте на датасетах осознанно.
OpenZFS 2.2 принёс block cloning: файлы или их части можно использовать для reflinks и копирования на уровне файлов по принципу copy-on-write, без физического дублирования данных (OpenZFS 2.2 Released With Block Cloning, Linux... - Phoronix). Это ускоряет деплой контейнеров и клонирование виртуальных машин, но меняет картину учёта места в снапшотах. Набор возможностей зависит от версии OpenZFS и сборки TrueNAS, поэтому сверяйтесь с release notes конкретного релиза.
Создаём пул: команды zpool create для mirror и raidz
Создание пула занимает минуты, а ошибки в нём исправляются только пересборкой с потерей данных. Проверьте имена устройств через ls /dev/disk/by-id/ и подставляйте пути by-id, а не /dev/sdX: буквы меняются после перезагрузки и замены дисков.
zpool create tank mirror /dev/disk/by-id/disk-A /dev/disk/by-id/disk-B zpool create tank raidz2 /dev/disk/by-id/disk-A /dev/disk/by-id/disk-B /dev/disk/by-id/disk-C /dev/disk/by-id/disk-D zpool create tank -o ashift=12 -O compression=zstd -O atime=off raidz2 /dev/disk/by-id/disk-A /dev/disk/by-id/disk-B /dev/disk/by-id/disk-C /dev/disk/by-id/disk-D /dev/disk/by-id/disk-E /dev/disk/by-id/disk-F
Пул можно собрать сразу из нескольких vdev одного типа, перечислив группы подряд. Полезные опции: ashift для размера сектора, compression для сжатия, atime для отключения обновления времени доступа, recordsize для размера блока на датасете. Таблицу параметров и разбор типичных ошибок мы приводили в статье TrueNAS SCALE: настройка ZFS-пулов и датасетов на практике.
Опции, которые нельзя поменять потом
Три параметра фиксируются при создании vdev и обратной силы не имеют:
- Тип vdev: mirror, raidz1/2/3 или stripe выбирается один раз.
- Число дисков в vdev: геометрия raidz после создания штатными средствами не меняется.
- ashift: размер сектора. Значение 12 соответствует секторам 4 КБ и подходит современным HDD, SSD и NVMe. Значение 9 имеет смысл только для старых дисков с сектором 512 байт.
Что менять можно: recordsize и compression на уровне датасета, atime, квоты, снапшоты. Для файлового хранилища и медиатеки разумно начать с recordsize=1M, для PostgreSQL и MySQL - с 16K или 8K. Сжатие lz4 даёт минимум накладных расходов, zstd выигрывает на архивах и текстовых данных.
Создание пула в TrueNAS: что делает UI под капотом
Мастер создания пула в TrueNAS SCALE и CORE вызывает тот же zpool create: вы задаёте имя пула, тип vdev, диски, ashift, сжатие и шифрование. Поверх пула система создаёт свои датасеты, настраивает ACL и добавляет точки монтирования для SMB и NFS.
Фактическую команду показывает zpool history: в журнале остаются создание пула, добавление vdev, изменения свойств и снапшоты. Этот журнал выручает при разборе инцидентов и при переносе конфигурации на другой сервер. Готовый набор команд администратора собран в шпаргалке ZFS для системы хранения: команды и практические приёмы администрирования в 2026.
Проверка структуры пула через zpool status
После создания пула выполните zpool status и убедитесь, что все vdev и диски в состоянии ONLINE, а счётчики ошибок равны нулю.
zpool status zpool status -x zpool status -v zpool list zpool iostat -v 5
Как читать вывод zpool status: NAME, STATE, CKSUM
Вывод состоит из секций:
- pool: имя пула и его текущее состояние (ONLINE, DEGRADED, FAULTED).
- state: состояние пула целиком.
- scan: результат последнего scrub или resilver и время завершения.
- config: дерево vdev и дисков с колонками NAME, STATE, READ, WRITE, CKSUM.
- errors: число ошибок, которые ZFS не смог исправить.
Правило чтения: если у всех устройств STATE=ONLINE и CKSUM=0, пул здоров. Рост CKSUM на диске говорит о битых блоках при чтении, рост на уровне vdev - о проблемах с чётностью или о том, что избыточности не хватило для починки. STATE=DEGRADED означает, что пул работает, но избыточность снижена: ищите FAULTED или OFFLINE диск и планируйте замену. Флаг -x показывает только проблемные места, флаг -v перечисляет файлы и датасеты, которых коснулись ошибки. Пошаговая диагностика разобрана в руководстве Проверка и обслуживание ZFS-пула после создания.
Scrub и resilver: как проверить, что пул действительно здоров
Состояние ONLINE подтверждает, что диски отвечают, но не проверяет содержимое. Это делает scrub: он читает все занятые блоки и сверяет контрольные суммы.
zpool scrub tank zpool status tank
Прогресс виден в строке scan, там же указывается число исправленных ошибок. В TrueNAS scrub планируется заданием по расписанию, типовой интервал - раз в месяц, для пулов на больших HDD иногда раз в две недели. Scrub создаёт постоянную нагрузку на диски, поэтому не запускайте его одновременно с полным бэкапом или миграцией виртуальных машин.
Resilver начинается автоматически после замены диска: новый накопитель получает данные по чётности или из зеркала, пул остаётся доступным. Для зеркала из быстрых SSD операция может завершиться за минуты, для raidz2 из восьми HDD большого объёма идти сутки и дольше. Если избыточности в пуле нет, заменить диск без простоя не получится. Схему регулярного обслуживания, мониторинга и замены дисков описывает материал Проактивное обслуживание ZFS в TrueNAS: мониторинг, scrub и замена дисков.
Как добавить vdev в ZFS пул и не сломать его
zpool add присоединяет к пулу новый vdev, а не расширяет уже существующий. Команды выглядят так:
zpool add tank mirror /dev/disk/by-id/disk-G /dev/disk/by-id/disk-H zpool add tank raidz2 /dev/disk/by-id/disk-I /dev/disk/by-id/disk-J /dev/disk/by-id/disk-K /dev/disk/by-id/disk-L
После добавления проверьте zpool status: новый vdev должен быть ONLINE, а счётчики ошибок нулевыми. Затем запустите scrub, чтобы убедиться, что блоки читаются с обеих групп.
Почему нельзя расширить raidz добавлением диска
В raidz чётность распределена по всем дискам группы, и добавление одного носителя меняет геометрию полос. Штатный способ увеличить пул - создать новый vdev. Расширение raidz (raidz expansion) вошло в OpenZFS 2.3.0 (Релиз OpenZFS 2.3.0, реализации ZFS для Linux и FreeBSD), но у него есть ограничения: за одну операцию добавляется один диск, откатить расширение нельзя, а данные остаются на прежней раскладке до перезаписи. Для продакшна проще и безопаснее проектировать raidz сразу на нужное число дисков.
Типичные ошибки при добавлении vdev и их последствия
- Одиночный диск вместо зеркала. Команда zpool add tank /dev/disk/by-id/disk-M создаёт stripe-vdev без избыточности. Отказ этого диска уничтожает весь пул, включая данные на других vdev.
- Смешивание raidz1 и raidz2 в одном пуле. Отказоустойчивость становится непредсказуемой: она определяется самым слабым vdev.
- Диски разного размера в одном raidz. Ёмкость выравнивается по самому маленькому диску группы, лишние терабайты не используются.
- Другой ashift на новом vdev. Блоки разного размера снижают эффективность полос и производительность.
- Отсутствие scrub после добавления. Проблемы с новыми дисками обнаруживаются позже, когда под рукой нет свободной избыточности.
- Попытка убрать raidz через zpool remove. Удаление поддерживается для hot spare, cache, log, а также зеркальных и нерезервированных primary top-level vdev, включая dedup и special vdev (zpool-remove.8 — OpenZFS documentation). Для top-level raidz или draid операция не сработает: man-страница zpool-remove прямо оговаривает, что top-level vdev можно удалить, только если primary-хранилище пула не содержит top-level raidz или draid vdev, все top-level vdev имеют одинаковый ashift и доступны ключи всех зашифрованных датасетов.
Чек-лист перед zpool add: сверить пути by-id, выбрать тип vdev, проверить свободные слоты и питание, добавить vdev, проверить zpool status, запустить scrub.
Планирование массива под сценарии: от домашней лаборатории до продакшна
| Сценарий | vdev | Диски | ashift | recordsize | compression |
|---|---|---|---|---|---|
| Домашняя лаборатория | raidz2 или две пары mirror | 4-6 | 12 | 1M | lz4 |
| SMB или NFS шара | raidz2 | 6-8 | 12 | 1M | lz4 |
| VM-хранилище | mirror | 4-8 SSD или NVMe | 12 | 16K | lz4 |
| PostgreSQL и MySQL | mirror | 4+ SSD | 12 | 16K или 8K | lz4 |
| Бэкапы и архив | raidz2 или raidz3 | 8+ | 12 | 1M | zstd |
Домашняя лаборатория: минимум дисков, максимум надёжности
Для 4-6 дисков рабочий вариант - raidz2 или две пары зеркал. raidz2 защищает от двух отказов при меньших потерях ёмкости, зеркала дают больше IOPS и быстрее восстанавливаются. На четырёх дисках по 4 ТБ raidz2 оставляет около 8 ТБ полезной ёмкости, на шести - около 16 ТБ.
SSD под special vdev в лаборатории оправдан, если много мелких файлов и снапшотов, но добавляет точку отказа и требует зеркала. Начинайте без него: добавить группу позже дешевле, чем пересобирать пул.
Продакшн-хранилище: VM, БД и файловые шары
Разносите нагрузки по отдельным пулам. Смешивание базы данных и файлового архива на одном пуле даёт непредсказуемое время отклика: тяжёлая запись бэкапа вытесняет транзакции из очереди.
Рабочая схема: зеркала на NVMe или SSD под виртуальные машины и БД, raidz2 на HDD под файлы и бэкапы. Для синхронных операций по NFS и iSCSI добавляйте SLOG (ZIL) на быстрых SSD с высокой выносливостью по записи, обязательно в зеркале. L2ARC помогает на чтениях, но требует оперативной памяти под индекс и не заменяет ёмкость. Пример: 2 NVMe в зеркале под VM, 8 HDD в raidz2 под бэкапы, отдельный датасет с recordsize=16K под базу.
Закладывайте запас по слотам, портам HBA и питанию: расширение пула новым vdev требует свободных мест и кабелей, а не только дисков.
Чек-лист: проверка массива перед вводом в эксплуатацию
- zpool status: все vdev и диски в состоянии ONLINE.
- Счётчики CKSUM равны нулю на каждом устройстве.
- Значение ashift соответствует секторам дисков (обычно 12).
- compression включён на нужных датасетах, обычно lz4 или zstd.
- atime=off, чтобы не писать лишние обновления метаданных.
- recordsize выставлен под нагрузку: 1M для файлов, 16K или 8K для баз данных.
- zpool list показывает ожидаемый объём после накладных расходов на чётность.
- zpool history содержит ожидаемые команды создания и настройки.
- Scrub выполнен и завершён без исправленных ошибок, задание по расписанию включено.
- Алерты на DEGRADED, FAULTED и рост CKSUM настроены и проверены тестовым событием.
Если хотя бы один пункт не выполняется, не переводите пул в продакшн: пересобрать массив дешевле, чем восстанавливать данные из бэкапа. Расписание регулярных проверок и замены дисков удобно построить по разбору проактивного обслуживания, ссылка на который есть выше.