ZFS как основа системы хранения: пулы, датасеты и снапшоты на практике

ZFS объединяет файловую систему и менеджер томов в одном слое. Пул (zpool) собирается из дисков, внутри пула создаются датасеты, а состояние датасета на конкретный момент фиксирует снапшот. Целостность данных держится на контрольных суммах для каждого блока и записи по принципу copy-on-write. На Linux ZFS работает как OpenZFS, в TrueNAS она встроена и настраивается из веб-интерфейса.

Минимальный набор команд, с которого начинают почти все:

zpool create mypool mirror /dev/disk/by-id/ata-DISK1 /dev/disk/by-id/ata-DISK2
zfs create mypool/data
zfs set compression=lz4 mypool/data
zfs snapshot mypool/data@first

Четыре строки закрывают базовый сценарий, но ошибку в первой из них исправить на месте не получится: тип vdev задаётся один раз, а пересоздание пула означает потерю данных. Поэтому решения о количестве дисков, их типе, размере и параметре ashift принимают до ввода команды. Ниже разобраны компоненты ZFS, правила планирования пула, установка на Linux, работа с датасетами и снапшотами, обслуживание массива.

Что такое ZFS и почему её выбирают для систем хранения

ZFS появилась в Solaris, сейчас развивается как OpenZFS и работает на Linux, FreeBSD и illumos. В TrueNAS SCALE и CORE она лежит в основе подсистемы хранения. Ключевое отличие от ext4 и XFS в том, что файловая система и управление томами объединены: отдельный слой вроде LVM не нужен. Пул сам распределяет блоки по дискам, следит за состоянием устройств и отвечает за избыточность.

За эти возможности платят оперативной памятью и аккуратностью при планировании. Практический ориентир: 1 ГБ ОЗУ на 1 ТБ сырой ёмкости пула плюс запас под систему и приложения. Офисные и домашние конфигурации на 8 дисков обычно укладываются в 16-32 ГБ. Отдельная история - дедупликация: её таблица живёт в памяти, на больших объёмах требует десятков гигабайт и редко окупается вне узких сценариев с реальным дублированием данных.

ECC-память снижает риск искажения данных в кэше, но обязательным условием для OpenZFS не является: контрольные суммы проверяют данные на дисках, а не в ОЗУ.

Ключевые компоненты ZFS: пулы, vdev, датасеты, снапшоты

Иерархия выстраивается сверху вниз: пул, затем vdev, затем датасет, затем снапшот.

• Пул (zpool) - верхний уровень, который объединяет ёмкость всех устройств и хранит метаданные о состоянии массива. Пул может быть один или несколько, но чаще один на всю дисковидную ёмкость сервера.
• vdev - группа дисков внутри пула, которая отвечает за избыточность. Бывает одиночным диском (stripe), зеркалом (mirror) или массивом RAIDZ1, RAIDZ2, RAIDZ3. В одном пуле можно смешивать типы vdev, например зеркало под базы данных и RAIDZ2 под архив.
• датасет - аналог файловой системы внутри пула. Создаётся одной командой, монтируется как обычный каталог, имеет собственные свойства: сжатие, размер записи (recordsize), квоту, резервирование, отключение atime.
• zvol - блочное устройство внутри пула, которое отдают по iSCSI, в Proxmox или в виртуальные машины. Свойства похожи на датасеты, базовая единица вместо recordsize - volblocksize.
• снапшот - копия датасета только для чтения, зафиксированная в конкретный момент. Снапшоты накладываются друг на друга в цепочку и занимают место только под изменённые блоки.

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

Целостность данных: контрольные суммы и copy-on-write

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

Copy-on-write меняет порядок записи. Новые данные всегда пишутся в свободные блоки, и только после успешной записи атомарно обновляется указатель на этот блок. Сбой питания в середине операции оставляет пул в предыдущем согласованном состоянии, а не в виде полузаписанных структур. Отсюда же берётся и механика снапшотов: снимок просто удерживает указатели на старые блоки, которые после изменения данных уже не перезаписываются.

Проверка всех блоков на дисках выполняется командой scrub. Возможности и ограничения ZFS, включая работу с checksums, scrubs, сжатием и типовые ошибки проектирования, разобраны в материале про ZFS и OpenZFS в системах хранения.

Планирование пула: выбор дисков и типа vdev

Тип vdev определяет, сколько дисков может отказать без потери пула и какую часть ёмкости съест избыточность.

Правила, которые экономят время и данные:

• Диски в одном vdev должны быть одинакового размера. В RAIDZ из дисков 8 ТБ и 4 ТБ ёмкость считается по меньшему, остаток не используется.
• Берите CMR-диски. SMR-модели при записи большого объёма и при resilver проваливаются по скорости, вплоть до выпадения из массива.
• Задавайте ashift=12 для любых современных дисков. Значение 9 оправдано только для старых накопителей с физическим сектором 512 байт, а ошибка приводит к невыравненному вводу-выводу и потере производительности.
• Оставляйте 20 процентов свободного места. При заполнении свыше 80 процентов пул начинает работать медленнее из-за фрагментации, а при 95-96 процентах запись может перейти в режим с низкой скоростью выбора свободных блоков.
• Расширяйте пул только добавлением новых vdev. В OpenZFS 2.3 появилась raidz expansion, но она меняет раскладку и требует свежей версии на всех этапах, поэтому резервный путь один: новый vdev плюс балансировка данных.
• Планируйте резерв по слотам и питанию. 8 дисков в корпусе на 8 слотов означают, что диск из зеркала заменяют только после отключения. Один свободный слот и SATA-порты с запасом снимают эту проблему.

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

• Пул из одного страйпа. Соблазн объединить 4 диска без избыточности ради полной ёмкости заканчивается потерей всего пула при отказе одного накопителя. Для продакшена такой вариант не подходит.
• Попытка расширить существующий vdev добавлением диска. Классический путь такой: добавляют новый vdev целиком. Путаница здесь приводит к неудачным командам и лишним дискам, которые не увеличивают ёмкость.
• Игнорирование ashift. Пул, созданный с ashift=9 на дисках 4Kn, теряет производительность на мелких операциях. Исправляют это только пересозданием пула.
• SMR-диски в RAIDZ. Resilver затягивается на дни, а сам массив может быть помечен как faulted.
• Разнобой по размерам и моделям. Смесь дисков 4 ТБ и 8 ТБ в одном vdev обрезает полезную ёмкость, а разные прошивки и кэш добавляют непредсказуемость.
• Расчёт ёмкости без вычета избыточности и резерва. RAIDZ2 из 6 дисков по 8 ТБ даёт не 48 ТБ, а 32 ТБ сырой полезной ёмкости, то есть около 25 ТБ с учётом заполнения до 80 процентов.
• Ставка на ZFS вместо резервных копий. Избыточность защищает от отказа железа, но не от ошибок оператора, шифровальщиков и сбоев файловой системы. Снапшоты лежат в том же пуле и исчезают вместе с ним.
• Малая память на большом пуле. Пул на 100 ТБ при 8 ГБ ОЗУ работает, но кэш метаданных постоянно вытесняется, и время отклика предсказуемо растёт.

Установка ZFS на Linux и создание пула

В Debian и Ubuntu пакет ставится из штатного репозитория: apt install zfsutils-linux. На RHEL, Rocky Linux и AlmaLinux пакет zfs подключают из репозитория OpenZFS, который добавляют заранее. После установки проверяют, что модуль ядра загружается: modprobe zfs и zpool status без аргументов.

apt update
apt install -y zfsutils-linux

zpool create mypool mirror /dev/disk/by-id/ata-WDC_WD80EFAX_1A2B3C /dev/disk/by-id/ata-WDC_WD80EFAX_4D5E6F

zpool status mypool
zpool list

Команда zpool status показывает состояние дисков, число ошибок чтения, записи и контрольных сумм, а zpool list выводит ёмкость, долю занятого места и состояние здоровья пула. Для одного vdev из четырёх дисков в RAIDZ1 команда выглядит как zpool create tank raidz1 /dev/disk/by-id/ata-DISK1 /dev/disk/by-id/ata-DISK2 /dev/disk/by-id/ata-DISK3 /dev/disk/by-id/ata-DISK4.

Три вещи перед созданием пула. Диски подключают целиком, а не разделами. Пути берут через /dev/disk/by-id, потому что имена вида /dev/sda меняются после перезагрузки и перестановки шлейфов, и пул может собраться не из тех устройств. Данные на дисках будут уничтожены: таблицы разделов и старые файловые системы стирают заранее командой wipefs. Перенос пула на другой сервер выполняется штатно: zpool export mypool на источнике и zpool import mypool на приёмнике.

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

Особенности настройки ZFS в TrueNAS

В TrueNAS устанавливать ZFS не нужно, она уже встроена. Пул создают в веб-интерфейсе: Storage, затем Pools, затем Add. Мастер предлагает доступные диски, тип vdev и сам подставляет рекомендуемые параметры, включая ashift. Пул из дисков с существующими данными интерфейс не создаст, их придётся очистить.

Дальше почти вся работа идёт мышью: датасеты создаются в разделе Datasets с настройкой сжатия, квот и размера записи, снапшоты планируются в Periodic Snapshot Tasks, репликация на второй сервер настраивается в Replication Tasks, а scrub и SMART-тесты включаются отдельными задачами. Пошаговый разбор установки и первичной настройки есть в руководстве по настройке TrueNAS от установки до SMB и NFS.

Датасеты и снапшоты: управление данными

Датасет создаётся одной командой и сразу монтируется в точку, совпадающую с именем: пул mypool и датасет mypool/data дают каталог /mypool/data. Дальше свойства выставляют под задачу.

zfs create mypool/data
zfs set compression=lz4 mypool/data
zfs set atime=off mypool/data
zfs set quota=500G mypool/data
zfs set recordsize=1M mypool/data
zfs list -o name,used,avail,quota,mountpoint

Ориентиры по параметрам. Сжатие lz4 включают почти всегда: накладные расходы по CPU минимальны, а текстовые и логовые данные сжимаются в разы. atime=off убирает лишние записи при чтении. recordsize=1M подходит для больших последовательных файлов: образов, медиа, бэкапов. Для баз данных берут 8-16 КБ, для zvol под виртуальные машины выставляют volblocksize 16 КБ. Квота ограничивает объём данных, refquota считает только сами данные без снапшотов, reservation резервирует место в пуле под датасет.

zfs snapshot mypool/data@2026-09-14
zfs list -t snapshot
zfs rollback mypool/data@2026-09-14
zfs destroy mypool/data@2026-09-14

Снапшот создаётся мгновенно и не копирует данные: он удерживает блоки, которые ещё актуальны на момент снимка. Место расходуется только на изменения. Побочный эффект: удаление файла внутри датасета не освободит место, пока существует снапшот с этим файлом, а команда zfs list -o space покажет, сколько именно занимает каждый снимок. Откат через zfs rollback возвращает датасет к состоянию снапшота и уничтожает все более поздние снимки, поэтому перед откатом стоит сделать свежий снимок текущего состояния.

Автоматизация на Linux строится на cron или на утилитах вроде zfs-auto-snapshot и sanoid, которые умеют держать расписание вида 15-минутных, часовых, дневных и недельных снимков с разным сроком хранения. В TrueNAS то же самое настраивается задачей Periodic Snapshot Tasks без внешних пакетов.

Чтобы отдать датасеты клиентам по сети, настраивают SMB для Windows или NFS для Linux, включая права на уровне файловой системы. Практические конфигурации и разбор ошибок доступа собраны в руководстве по сетевому доступу к файлам в TrueNAS Core и SCALE.

Использование zfs send и zfs receive для резервного копирования

Снапшоты живут в том же пуле, поэтому для настоящей защиты данные увозят на другой сервер потоком zfs send.

zfs send mypool/data@2026-09-14 | ssh backup@10.0.0.5 zfs receive backup/data
zfs send -i mypool/data@2026-09-13 mypool/data@2026-09-14 | ssh backup@10.0.0.5 zfs receive backup/data
zfs send -w mypool/data@2026-09-14 | ssh backup@10.0.0.5 zfs receive backup/data

Первая команда передаёт полный снимок, вторая только изменения между двумя снимками, третья работает с шифрованным датасетом и переносит данные вместе с шифрованием (-w, raw-поток). Для шифрованных датасетов без ключа на источнике применяют -w или -c, а обычный поток без ключа не собрать. Версии ZFS на источнике и приёмнике должны поддерживать одинаковый набор feature flags, иначе приём завершится ошибкой: перед первой репликацией это проверяют на небольшом тестовом датасете. В TrueNAS такие задачи настраиваются в Replication Tasks с расписанием и уведомлениями о результате.

Обслуживание и защита данных: scrub и мониторинг

Scrub читает все блоки пула и сверяет их с контрольными суммами. При обнаружении расхождения ZFS исправляет блок из избыточной копии и фиксирует событие. Запускается вручную командой zpool scrub mypool, прерывается через zpool scrub -s mypool. Разумное расписание: раз в месяц, в TrueNAS по умолчанию задача выполняется примерно раз в 35 дней. Во время scrub скорость доступа снижается, поэтому его ставят на ночные часы.

zpool status -v mypool
zpool events -v
zpool list -v mypool

Смотреть нужно на колонки READ, WRITE и CKSUM в выводе zpool status. Ненулевой CKSUM означает, что контрольная сумма не совпала и данные были восстановлены из другой копии. Единичные ошибки после сбоя питания или плохого кабеля случаются; повторяющиеся на одном и том же диске указывают на накопитель или шлейф, и диск меняют. Проверяют также SMART-атрибуты, температуру и число переназначенных секторов. Для алертов подходят штатные уведомления TrueNAS по почте, zed на Linux, а также сборщики метрик ZFS в Zabbix или Prometheus с экспортером node_exporter.

Замена диска запускает resilver: ZFS пересобирает данные vdev по контрольным суммам. На RAIDZ2 массив переживает второй отказ во время этой операции, на RAIDZ1 нет, поэтому в крупных массивах от него отказываются. Профилактические процедуры, расписание scrub и порядок замены дисков подробно описаны в статье про проактивное обслуживание ZFS в TrueNAS.

Разбор длинных логов zpool events и написание парсеров для алертов ускоряет ИИ-ассистент: агрегатор AiTunnel даёт доступ к моделям GPT, Gemini и Claude через единый интерфейс с оплатой в рублях.

Заключение: когда ZFS оправдана и что делать дальше

ZFS выигрывает там, где нужны контроль целостности, снапшоты и репликация: файловые хранилища для офиса, диски под виртуальные машины, архивы, сборка артефактов и бэкапов. Для зеркала из двух дисков в домашнем NAS она тоже уместна, если в системе 8 ГБ ОЗУ и больше.

Случаи, когда ZFS избыточна или неудобна: одиночный диск без планов на избыточность, машина с 2-4 ГБ памяти, требование расширять массив по одному диску на старых версиях OpenZFS, необходимость выжать максимум ёмкости без потерь на чётность. В последнем случае выгоднее ext4 или XFS с LVM, а защиту данных строить на внешних резервных копиях.

Порядок действий для запуска в продакшене: собрать тестовый пул на свободных дисках, проверить параметры ashift и тип vdev, создать датасеты с нужным сжатием и размером записи, включить снапшоты по расписанию, настроить scrub и репликацию на второй сервер, а затем переносить реальные данные. Резервная копия по схеме 3-2-1 остаётся обязательной даже при наличии RAIDZ и снапшотов. Пример практической сборки хранилища под инструменты и артефакты сборки с датасетами, правами для CI и автоматическими снапшотами приведён в материале про хранилище инструментов и артефактов на TrueNAS.