Что такое ZFS-пул и датасет в TrueNAS SCALE
Пул ZFS создаётся в разделе Storage → Create Pool за несколько минут, а датасеты нарезаются поверх него и получают собственные параметры: recordsize, compression, atime, квоту и расписание снапшотов. Физический уровень собирается из дисков в vdev, логический уровень делится на отдельные файловые системы.
Разница видна на примере: пул RAIDZ2 из шести дисков по 8 ТБ вмещает около 32 ТБ данных, и внутри него живут датасет tank/db с recordsize 16K и sync=standard, датасет tank/files с recordsize 1M и квотой 2 ТБ, датасет tank/backup со своим расписанием снапшотов. Один пул, разные правила для каждого типа данных.
Дальше разобраны оба уровня, выбор топологии под сценарий, пошаговое создание пула, тонкая настройка датасетов, снапшоты по расписанию, типичные ошибки и проверка результата командами zpool status и zfs list.
Чем пул отличается от датасета
Пул (zpool) отвечает за физику и надёжность: объединяет vdev, считает контрольные суммы, восстанавливает повреждённые блоки по чётности, распределяет нагрузку между дисками. Датасет это файловая система внутри пула, которая оперирует логическими сущностями: квотами, сжатием, снапшотами, правами доступа и точкой монтирования.
Иерархия выглядит так: диски → vdev → пул → датасеты. Уровни выше датасета после создания не меняются без пересборки. Добавить диск в существующий RAIDZ vdev нельзя: расширение пула идёт только добавлением нового vdev, например второй пары зеркал в тот же пул.
Простая аналогия: пул это фундамент и несущие стены, датасеты это комнаты. В одной комнате база данных с мелкими блоками, в другой видеоархив с крупными, и у каждой свои правила.
Датасеты наследуют параметры родителя. Создали tank/files с compression=zstd, дочерний tank/files/archive получит zstd автоматически, а переопределить сможет одним переключателем. Наследование экономит время: базовые настройки задаются один раз на верхнем уровне, исключения прописываются точечно.
Отдельный датасет даёт три практические выгоды. Свои снапшоты, которые не задевают соседей. Свою квоту, защищающую пул от переполнения одним процессом. Свои права и ACL, не смешивающиеся с чужой политикой доступа.
Почему TrueNAS SCALE, а не CORE
SCALE построена на Debian Linux, CORE на FreeBSD. Ключевое отличие для практики: SCALE запускает Docker-контейнеры и виртуальные машины KVM из коробки, получает обновления чаще и поддерживает более широкий список сетевых карт и HBA-контроллеров. CORE остаётся стабильной и минималистичной платформой для чистого файлового хранилища.
Для новых проектов берите SCALE: OpenZFS в обеих версиях один и тот же, а гибкость по контейнерам и виртуализации выше. Если парк уже работает на CORE и задач кроме файловых шар нет, миграция не обязательна. Каждый шаг установки обоих вариантов разобран в руководстве по развёртыванию TrueNAS SCALE от установки до базовой настройки.
Выбор топологии пула: зеркало, RAIDZ1/2/3 или одиночный диск
Топология определяет, сколько дисков может отказать без потери данных и какую долю ёмкости съест избыточность. Доступны пять схем.
- Stripe - диски складываются без защиты. Отказ любого диска уничтожает весь пул.
- Mirror - пары дисков с полной копией. Быстрые случайные операции, теряется 50% ёмкости.
- RAIDZ1 - одна полоса чётности, минимум 3 диска, переживает отказ одного.
- RAIDZ2 - две полосы чётности, минимум 4 диска, переживает отказ двух.
- RAIDZ3 - три полосы чётности, минимум 5 дисков, переживает отказ трёх.
Пример на четырёх дисках по 4 ТБ: зеркало даст 8 ТБ, RAIDZ1 около 12 ТБ, RAIDZ2 около 8 ТБ. Разница в скорости случайных операций заметнее: зеркало обслуживает IOPS всех дисков параллельно, RAIDZ считает чётность и на мелких блоках уступает. Для виртуальных машин и PostgreSQL зеркало обычно выигрывает, для медиатеки и бэкапов RAIDZ2 даёт больше ёмкости за те же деньги.
| Сценарий | Топология | Минимум дисков | Потеря ёмкости |
|---|---|---|---|
| Домашний NAS, 2 диска | Mirror | 2 | 50% |
| Файловое хранилище малого офиса | RAIDZ1 | 3 | 1 диск |
| Продакшн, высокая надёжность | RAIDZ2 | 4 | 2 диска |
| Крупный архив, длинный ребилд | RAIDZ3 | 5 | 3 диска |
| Базы данных и виртуалки | Mirror (пары) | 2 | 50% |
| Тестовый стенд, кэш сборки | Stripe | 1 | 0% |
Когда зеркало лучше RAIDZ
Зеркало предпочтительно при нагрузке random read/write, когда важна скорость ребилда и планируется расширять пул парами дисков. Восстановление зеркала копирует данные одного диска, тогда как RAIDZ при ребилде пересчитывает чётность по всему vdev, и на дисках 8-12 ТБ это занимает сутки и дольше. Второй отказ во время ребилда RAIDZ1 приводит к потере пула, поэтому RAIDZ1 уместен на дисках до 4 ТБ и при наличии актуальных бэкапов.
Совместимость железа влияет на выбор не меньше топологии: HBA в IT-режиме без RAID-кэша, CMR-модели вместо SMR, расчёт ёмкости с запасом. Как подбирать контроллер, диски и кэш L2ARC, разобрано в руководстве по сборке и настройке массива хранения TrueNAS.
Одиночный диск: когда это допустимо
Stripe без избыточности годится для временных данных: кэш сборки, промежуточные выгрузки, тестовые стенды. Отказ диска здесь означает потерю всего пула. Для значимых данных минимум зеркало, а лучше RAIDZ2 плюс отдельная копия на другом носителе. Правило простое: если датасет нельзя восстановить из бэкапа за сутки, один диск не подходит.
Расширить stripe в зеркало на месте нельзя, потребуется пересоздание пула и перенос данных. Поэтому одиночный диск разумно держать как осознанное временное решение, а не как основу для рабочих сервисов.
Пошаговое создание пула в TrueNAS SCALE
Путь в интерфейсе: Storage → Create Pool. В мастере заполните Name, например tank, выберите Layout (Stripe, Mirror, RAIDZ1, RAIDZ2, RAIDZ3), отметьте диски и раскройте расширенные настройки. Галочка Force включает пул на дисках с существующими данными, её ставят только на тестовом стенде: содержимое дисков будет уничтожено.
После создания проверьте результат. Storage → Pools покажет статус Online, а команда zpool status в шелле перечислит vdev, устройства и число ошибок. Пул сразу получает точку монтирования /mnt/tank, поверх которой создаются датасеты.
Настройка Ashift и почему это важно
Ashift задаёт размер сектора в степени двойки: значение 12 соответствует 4 КиБ, 9 соответствует 512 байт. Для современных дисков 512e и 4Kn правильно ashift=12. Ошибка в сторону 9 приводит к операции чтения-изменения-записи на каждый блок, падению скорости и ускоренному износу SSD. TrueNAS обычно определяет значение автоматически, но перед созданием пула стоит открыть расширенные настройки и убедиться, что стоит 12.
Изменить ashift после создания пула нельзя, только пересоздать его. Проверить текущее значение позволяет команда zpool get ashift tank.
Шифрование пула: за и против
Шифрование защищает данные при краже дисков или сервера целиком: без ключа массив читается как случайный шум. Цена этой защиты в обязательном хранении ключа вне сервера и внимании к процедуре загрузки. Потеря ключа или passphrase означает безвозвратную потерю данных, восстановить их не сможет никто.
Включайте шифрование, если диски покидают защищённый периметр или этого требует политика безопасности. Ключ сохраните в менеджере секретов и проверьте восстановление на тестовом пуле до того, как залить боевые данные.
Создание и настройка датасетов
Датасет добавляется через Storage → Pools → нужный пул → Add Dataset. Укажите имя, например db или files, и раскройте Advanced Options для параметров. Обязателен только Name, остальные поля имеют разумные значения по умолчанию.
recordsize: как выбрать под нагрузку
recordsize задаёт максимальный размер блока. Слишком крупный блок для мелких случайных операций вызывает чтение-изменение-запись: диск читает весь блок, меняет часть и пишет целиком. Слишком мелкий блок для последовательного потока увеличивает накладные расходы.
| Тип данных | recordsize | Почему |
|---|---|---|
| PostgreSQL, MySQL | 16K | совпадает с размером страницы, убирает чтение-изменение-запись |
| Виртуальные машины | 16K или 32K | мелкие случайные записи гостевых ОС |
| Файловые шары общего назначения | 128K | значение по умолчанию, разумный баланс |
| Медиа, бэкапы, архивы | 1M | последовательные потоки, минимум накладных расходов |
recordsize задаёт максимум, а не минимум: мелкие файлы пишутся блоками своего размера и место не теряют. Для БД параметр меняют до заливки данных, потому что уже записанные блоки не переупаковываются. Новый размер подхватят только свежие записи, полный эффект даст перезапись данных.
compression и atime: влияние на производительность и объём
compression=lz4 включён по умолчанию и сжимает данные прозрачно, почти не нагружая CPU. zstd даёт более высокий коэффициент при небольшой потере скорости. Отключать сжатие смысла нет: на плохо сжимаемых данных накладные расходы близки к нулю, а текстовые логи, JSON и исходный код ужимаются в 2-3 раза.
atime=off отключает запись времени последнего доступа к файлу. При atime=on каждое чтение порождает операцию записи, это лишняя нагрузка на диски и лишние изменения в снапшотах. Для файловых шар, баз данных и артефактов сборки держите off.
Параметр sync управляет подтверждением записи. standard гарантирует, что данные легли на диск до ответа приложению, disabled даёт кратный прирост скорости на временных данных с риском потери последних секунд при сбое питания. Для PostgreSQL и любых транзакционных систем оставляйте standard.
Квоты и резервирование места
quota ограничивает максимальный объём датасета, reservation гарантирует ему место в пуле. Квота защищает от сценария, когда один процесс забивает весь пул логами. Резервирование пригодится для критичных датасетов, но съедает свободное место пула целиком, поэтому применяйте его точечно.
Пример: quota=500G для датасета бэкапов, quota=200G для кэша CI, quota=2T для медиатеки. Следите за суммой квот: она может превышать ёмкость пула, ZFS такое распределение не блокирует.
Права доступа настраиваются через ACL прямо в свойствах датасета или через шары SMB и NFS. Разграничение по датасетам проще, чем по папкам внутри одного: политики наследуются и не смешиваются. Пример организации хранилища с отдельными датасетами под артефакты, кэш и права для CI приведён в статье про хранилище инструментов и артефактов на TrueNAS.
Настройка снапшотов по расписанию
Снапшот фиксирует состояние датасета на момент времени и не копирует данные: ZFS хранит только изменения, поэтому место расходуется экономно. Задача создаётся в Data Protection → Periodic Snapshot Tasks → Add, где выбираются датасет, расписание и срок хранения.
Расписание и retention policy
Ориентиры по частоте: для БД каждый час с хранением 24 часовых копий плюс ежедневные на 7 дней; для файловых шар ежедневно с хранением 30 дней; для кода и конфигов ежечасно с хранением 2 суток. Галочка Recursive включает снапшоты для всех дочерних датасетов, что удобно для дерева tank/files с вложенными уровнями.
Срок хранения задавайте в часах, днях, неделях и месяцах одновременно: интерфейс позволяет оставить, например, 24 часовых, 7 ежедневных и 4 недельных снапшота. Naming Schema по умолчанию содержит дату и время, что упрощает поиск нужной точки восстановления.
Автоматические снапшоты защищают от случайного удаления файлов и ошибок в приложениях. От отказа пула или сервера они не спасают: копии лежат на тех же дисках. Дополняйте их отправкой на второй узел через Replication Task. Как строить схему с репликацией, разобрано в материале про проектирование отказоустойчивого NAS на TrueNAS.
Восстановление из снапшота
Данные возвращают тремя способами. Rollback откатывает весь датасет к состоянию снапшота и уничтожает более новые изменения, поэтому подходит для полного отката. Clone создаёт независимую копию датасета с данными снапшота: её монтируют рядом и копируют нужные файлы. Третий способ - открыть каталог снапшота только для чтения и забрать отдельные файлы.
Служебный каталог снапшотов лежит в корне датасета, в .zfs/snapshot, и доступен из шелла и по сети при включённом параметре. Проверку восстановления проведите заранее: снапшот, который ни разу не открывали, гарантий не даёт.
Типичные ошибки при создании пулов и датасетов
SMR-диски и почему они ломают RAIDZ
SMR-диски с черепичной записью перезаписывают дорожки последовательно и при плотной нагрузке уходят в длительные таймауты. При ребилде RAIDZ поток записи непрерывный, и такой накопитель выпадает из массива, что может обрушить пул. Берите CMR-модели. Перед покупкой проверяйте спецификацию: производители часто не указывают тип записи крупным шрифтом, а внутри одной серии он меняется без смены артикула.
Почему нельзя заполнять пул более чем на 80%
ZFS пишет новые блоки в свободное место, и при заполнении выше 80% растёт фрагментация, поиск свободных блоков замедляется, скорость записи падает в разы. Держите 20% запаса, ограничивайте датасеты квотами и следите за свободным местом в Storage → Pools.
Остальные ошибки встречаются не реже и лечатся до создания пула, а не после.
- Неправильный ashift. Значение 9 на дисках 4Kn даёт чтение-изменение-запись на каждом блоке. Решение: проверять ashift перед созданием пула, при ошибке пересоздать пул сразу, пока данных нет.
- recordsize по умолчанию для БД. Блок 128K против страницы 16K ведёт к лишним операциям на каждом коммите. Решение: ставить 16K до заливки данных.
- atime включён. Лишние записи при каждом чтении и рост снапшотов. Решение: atime=off на всех датасетах с файлами и базами.
- Пул на одном диске с боевыми данными. Отказ диска уничтожает всё сразу. Решение: минимум зеркало, бэкап на отдельном носителе вне сервера.
- Экономия на ECC RAM. ZFS полагается на контрольные суммы, но ошибки памяти искажают данные до записи, и пул сохранит уже испорченный блок. Решение: ECC-память для пулов с боевыми данными.
- Отсутствие мониторинга SMART. Деградация диска проходит незаметно до отказа. Решение: включить уведомления и проверять атрибуты раз в месяц.
- Ожидание, что снапшоты заменяют бэкап. Копия на том же пуле не спасает от его потери. Решение: реплицировать снапшоты на второй узел.
Проверка и мониторинг после настройки
Базовый набор команд в шелле. zpool status показывает состояние пула, список vdev, число ошибок чтения и записи, результат последнего scrub. zfs list выводит датасеты, занятое место, квоты и точки монтирования. zpool list даёт общий объём и процент заполнения. zpool get ashift tank подтверждает размер сектора.
Scrub проверяет контрольные суммы всех блоков и восстанавливает повреждения по чётности. Запускается вручную командой zpool scrub tank или по расписанию: TrueNAS ставит его по умолчанию каждые 35 дней. На пуле с крупными дисками scrub идёт часами и заметно нагружает накопители, поэтому планируйте его на ночь.
SMART контролируйте в Storage → Disks → SMART: рост Reallocated Sector Count, Pending Sector Count и ошибок интерфейса говорит о скором отказе. Настройте email-уведомления в System → Alert Settings, чтобы получать предупреждения о деградации пула, переполнении датасетов и ошибках scrub.
Локальных снапшотов и scrub недостаточно: они не защищают от пожара, кражи сервера и ошибки оператора. Держите вторую копию вне площадки. Подойдёт облачная инфраструктура с дисковым хранилищем, например Timeweb Cloud: ZFS отправляет снапшоты по SSH на удалённую машину, а восстановление занимает минуты.
Минимальный рабочий чек-лист после настройки: пул в статусе Online, ashift=12, на датасетах включены compression и atime=off, квоты выставлены, Periodic Snapshot Task создан с разумным сроком хранения, scrub запланирован, уведомления по email проверены тестовым письмом.