СХД на базе TrueNAS и ZFS: практическое руководство по развёртыванию для офиса и дома

Что такое СХД на TrueNAS и ZFS и кому это нужно

TrueNAS дает веб-интерфейс и API к набору сервисов хранения, а ZFS внутри нее отвечает за файловую систему и управление томами одновременно. Каждый блок данных получает контрольную сумму, запись идет по схеме copy-on-write, а при наличии избыточности поврежденный блок восстанавливается из копии на другом диске. Итог: молчаливое повреждение данных фиксируется сразу, а не всплывает через годы при попытке прочитать архив.

Короткий ответ по сути вопроса: TrueNAS с ZFS закрывает задачи офиса и дома, если железо собрано под требования ZFS. HBA в IT mode, 16 ГБ RAM и больше, минимум два диска четности в пуле, копия данных вне массива. Нарушьте любой пункт, и надежность упадет до уровня обычного RAID-контроллера. ZFS доверяет железу и не умеет скрывать его ошибки.

Сценарии, где связка TrueNAS и ZFS работает предсказуемо:

• файловый сервер офиса на SMB для Windows и macOS, от 10 до 100 сотрудников;
• NFS-экспорт для Linux и BSD: бэкапы, сборки, домашние каталоги разработчиков;
• iSCSI-хранилище как datastore для ESXi или Proxmox;
• домашний медиасервер и архив фото на 4-8 дисках;
• узел приема репликации zfs send/recv с продакшена.

Ключевые свойства ZFS, на которых строятся все дальнейшие решения: контрольные суммы каждого блока, self-healing при избыточности, мгновенные снапшоты, репликация на уровне блоков, сжатие lz4 и zstd. Цена вопроса: ARC требует RAM, пул не любит заполнение выше 80%, а RAID-контроллеры без IT mode ломают всю схему целостности.

Установку и первичную настройку сервисов разбирает пошаговая инструкция по настройке TrueNAS от установки до SMB и NFS. Здесь фокус на другом: подбор железа, топология vdev и эксплуатация без потери пула.

TrueNAS CORE или SCALE: что выбрать для офиса и дома

CORE построена на FreeBSD, SCALE на Debian Linux. Разница видна на драйверах и наборе сервисов.

• CORE: проверенное ядро FreeBSD, минимальный набор сервисов, jails вместо контейнеров, консервативный подход к обновлениям. Нет поддержки части свежего железа и NVMe-накопителей новых поколений.
• SCALE: Linux 6.x, широкая поддержка CPU, сетевых карт и NVMe, контейнеры Docker (раздел Apps), виртуализация KVM, релизы каждые несколько месяцев. iXsystems развивает SCALE как основное направление, CORE получает поддерживающие обновления.

Дом с медиасервером, Plex или Jellyfin и десятком контейнеров: SCALE. Офисный файловый сервер на SMB и iSCSI на железе свежее 2020 года: тоже SCALE. CORE разумен, когда сборка проверена годами, драйверы FreeBSD полностью закрывают платформу, а из сервисов нужны только SMB, NFS и iSCSI.

Чем TrueNAS+ZFS отличается от OMV и Unraid

Для целостности данных, снапшотов и репликации ZFS выигрывает по возможностям. Unraid удобен при разнокалиберных дисках и домашнем медиасервере, но не дает сквозных контрольных сумм. OMV проще и легче, его берут под слабое железо и минимальный набор задач. Дисциплина по RAM и контроллерам у TrueNAS выше, чем у обоих конкурентов.

Выбор железа: HBA, контроллеры, сеть и RAM

Плохой HBA входит в короткий список главных причин потери пула. ZFS обращается к дискам напрямую, поэтому между накопителем и системой не должно быть посредника с собственным кэшем и логикой RAID.

Проверенные контроллеры: LSI или Broadcom 9300-8i, 9305-16i, 9400-8i, перепрошитые в IT mode. SATA-порты чипсета подходят для 4-6 дисков домашнего массива. Корпус с backplane на 12-24 диска дополняют SAS-экспандером (например, на чипе LSI SAS2x36).

Чего избегать: RAID-контроллеры Dell PERC и MegaRAID в режиме RAID, дешевые SATA-контроллеры на Marvell 9230 и 9215, ASM1166, платы с порт-мультипликаторами без независимого питания. Под нагрузкой такие контроллеры сбрасывают диски из массива, и пул уходит в DEGRADED или FAULTED.

Платформа: Supermicro X10 и X11, платы ASRock Rack. Отдельный IPMI полезен для управления без монитора. Сеть: Intel X520-DA2, X550-T2, Chelsio T520-CR для 10GbE. Блок питания берут с запасом 30-40% по мощности, корпус с продувом на все отсеки. Детальный разбор совместимых комплектующих и порядка сборки есть в материале сборка и настройка массива хранения TrueNAS: от выбора контроллера до конфигурации ZFS-пула.

Почему HBA в IT mode обязателен для ZFS

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

IT mode отключает RAID-функции и передает диски системе как JBOD. Только в этом режиме ZFS видит серийники, управляет очередью команд, собирает статистику ошибок по каждому устройству и восстанавливает поврежденный блок из копии на другом диске. Состояние прошивки проверяют утилитами sas2flash или sas3flash с ключом -list: в выводе должно быть IT, а не IR.

Отдельный случай: контроллер работает, но между ним и дисками стоит экспандер с плохим питанием. Симптом тот же, что у плохого HBA: всплеск ошибок CKSUM сразу на нескольких дисках.

Сколько RAM нужно ZFS и когда ECC действительно важен

ARC занимает свободную память под кэш чтения, поэтому экономия на RAM бьет по производительности, а иногда и по доступности пула.

Практическое правило: 1 ГБ RAM на 1 ТБ емкости для базовых файловых задач, дальше по профилю нагрузки.

ECC-память защищает от битовых ошибок до того, как они превратятся в блок с корректной контрольной суммой. Без ECC ZFS продолжает работать, но ошибка в памяти может быть записана на диск как валидные данные: ZFS проверит сумму, не найдет расхождения и оставит повреждение в пуле навсегда. Для офисных массивов ECC берут обязательно, для домашнего архива фото и видео вопрос прощают, учитывая, что бэкап закрывает риск.

Планирование пулов и vdev: mirror, RAIDZ и ashift

vdev это группа дисков, пул это набор vdev. Отказ любого vdev без избыточности означает потерю всего пула, поэтому топология важнее суммарной емкости.

Mirror дает высокий IOPS и быстрый resilver, плата за это половина емкости. RAIDZ экономит диски, но проигрывает по случайному чтению и записи и увеличивает время восстановления пропорционально числу дисков в vdev. Расширить пул добавлением vdev можно, заменить тип уже созданного vdev нельзя.

Примеры рабочих конфигураций. Дом: 4 диска по 4 ТБ в RAIDZ2, полезная емкость около 7,3 ТБ, архив фото и медиатеки. Офис: 6 дисков по 8 ТБ в RAIDZ2 плюс зеркало из двух NVMe под SLOG и метаданные, полезная емкость около 32 ТБ. Виртуализация: три зеркала по 2 диска или RAID10 на 8 дисках, если нужны тысячи IOPS на datastore.

Mirror vs RAIDZ: что выбрать для дома и офиса

Домашний медиасервер и архив читают последовательно крупными блоками. Здесь RAIDZ2 на 4-6 дисках дает лучшую цену за терабайт и терпимое время resilver. Офисная виртуализация работает с блоками 4-16 КБ в случайном порядке, поэтому выбирают mirror: восстановление зеркала на 4 ТБ занимает часы, а не сутки, и запас по IOPS остается.

Компромисс для офиса с одной задачей: файловый сервер на RAIDZ2 плюс отдельный пул из двух NVMe в зеркале под базы данных и виртуальные машины. Смешивать тяжелую случайную нагрузку и архив на одном vdev не стоит: АРХ-кэш и очереди начинают работать друг против друга.

ashift и recordsize: как не убить производительность

ashift задается при создании vdev и не меняется никогда. Для современных дисков с физическим сектором 4 КБ нужен ashift=12. Если по ошибке создать vdev с ashift=9, каждая запись меньше 4 КБ вызовет цикл read-modify-write, и скорость записи упадет в 2-5 раз. Проверяют параметр командой zpool get ashift poolname. Исправить это на живом пуле нельзя, помогает только пересоздание пула или vdev.

recordsize меняется на датасете в любой момент, но действует на новые записи. Ориентиры: медиа и крупные архивы 1M, файловые шары общего назначения 128K, базы данных 128K или 16K для OLTP, образы виртуальных машин 16K. Сжатие lz4 включают по умолчанию: оно почти не тратит CPU и часто дает выигрыш на текстовых и лог-файлах.

Как подбирать параметры под конкретную нагрузку и снимать метрики через arcstat и iostat, разобрано в материале настройка производительности TrueNAS: recordsize, compression, Jumbo Frames и SMB Multichannel.

ZFS-специфика: L2ARC, SLOG, дедупликация и снапшоты

Когда L2ARC и SLOG действительно нужны

L2ARC это кэш чтения на SSD поверх ARC. Он помогает, когда рабочий набор данных превышает RAM и нагрузка состоит из случайных чтений. Индексы L2ARC живут в RAM, поэтому включать его на машине с 16 ГБ памяти вредно: кэш отберет память у ARC и замедлит систему. Практический порог: 64 ГБ RAM и больше. Домашнему медиасерверу L2ARC не дает ничего.

SLOG это отдельное устройство под ZIL, журнал синхронных записей. Он нужен там, где приложение требует подтверждения записи на носитель: iSCSI, NFS с sync, СУБД, гипервизор с включенной синхронизацией. Условие одно: SSD с power loss protection (Optane, Samsung PM9A3, Intel S3710). Диск без PLP сделает запись медленнее, чем вариант без SLOG вообще, потому что потеря журнала при сбое питания разрушит пул. Для отказоустойчивости SLOG ставят зеркалом из двух устройств.

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

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

Таблица дедупликации (DDT) хранится в RAM. Расход зависит от размера блока: при 128 КБ это примерно 1,5 ГБ на 1 ТБ данных, при 8 КБ уже 20 ГБ и выше. Как только DDT перестает помещаться в память, ZFS уходит в swap, задержки растут в разы, а в пределе пул становится недоступным для записи.

Реальная экономия места редко оправдывает такие затраты. Сжатие zstd на текстах, логах и части бэкапов дает близкий эффект бесплатно. Дедупликацию включают точечно (VDI, повторяющиеся бэкапы, одинаковые контейнеры) и только после оценки: zdb -S считает коэффициент дедупликации по текущим данным, zpool status показывает таблицу DDT. Если расчетный коэффициент ниже 1,5-2, включать нечего.

Снапшоты и репликация: настройка и типовые ошибки

Снапшот не копирует данные: место занимает только то, что изменилось после его создания. В TrueNAS расписание задают в разделе Data Protection: задача Periodic Snapshot Task с рекурсией по датасетам, срок хранения 7-30 дней. Более длинное хранение на активном файловом сервере съедает пул: за месяц изменений снапшоты могут занять больше места, чем сами данные.

Репликация строится на zfs send и zfs recv. В TrueNAS это Replication Task по SSH: выбирают исходный датасет, целевой сервер, рекурсию и интервал. Правило 3-2-1 требует копии за пределами основного пула. Снапшоты, лежащие только на том же пуле, защищают от ошибки оператора, но не от потери массива.

Если второго физического NAS нет, роль цели для zfs recv выполняет арендованный сервер с дисками, например в Timeweb Cloud: передача идет по SSH поверх шифрованного канала, и копия физически лежит в другой стойке. Требование к цели простое: диска должно быть больше, чем занимают реплики, с запасом на рост и на несколько поколений снапшотов.

Настройка iSCSI, SMB и NFS под разных потребителей

Настройка iSCSI в TrueNAS для гипервизоров

iSCSI дает блочное устройство, которое гипервизор форматирует своей файловой системой. Порядок настройки в TrueNAS: создать zvol с blocksize 16 КБ (64 КБ для больших последовательных объемов), включить службу iSCSI, задать Portal с IP хранилища и портом 3260, создать Target, привязать к нему Extent на zvol, объединить их в Associated Target, добавить Initiator с IQN гипервизора и включить CHAP для аутентификации.

На стороне ESXi добавляют программный iSCSI-адаптер, прописывают адрес портала, включают CHAP и запускают rescan хранилищ. В Proxmox создают LVM поверх появившегося устройства или подключают zvol через ZFS over iSCSI. Для отказоустойчивости настраивают multipath: два портала на разных сетевых картах и два пути к одному extent.

Ключевой момент производительности: zvol отдает синхронные записи, поэтому без SLOG на NVMe с PLP задержка записи виртуальной машины упирается в скорость дисков пула. Проверенная связка для datastore это зеркало NVMe под SLOG плюс RAIDZ2 или зеркала на HDD.

SMB шары TrueNAS: настройка и права доступа

Порядок для Windows-клиентов: создать датасет, включить службу SMB, создать шару с путем к датасету, применить ACL. Гостевой доступ отключают, а права выдают через Windows ACL либо Unix permissions, но не смешивают модели на одном датасете. Пресеты ACL в TrueNAS (например, Windows) выставляют владельца, группу и наследование в один клик.

SMB3 Multichannel агрегирует несколько сетевых интерфейсов и поднимает пропускную способность выше 1 Гбит/с без LACP. Типовая ошибка новичка это сообщение о недостатке прав при верных настройках шары: причина в том, что ACL не унаследовались на вложенные каталоги, UID пользователя в TrueNAS не совпал с SID домена, либо службу не перезапустили после смены настроек.

Разбор ACL, интеграции с Active Directory, Proxmox и Docker с примерами команд есть в руководстве настройка сетевого доступа к файлам в TrueNAS CORE и SCALE: SMB, NFS, FTP.

NFS для Linux и BSD: экспорт и права

NFS-экспорт задают для датасета: указывают подсеть клиентов в CIDR, права rw, режим sync и no_subtree_check. По умолчанию работает root squash, то есть root на клиенте превращается в анонимного пользователя, и задачи с сохранением владельца файлов ломаются. Для служебных экспортов настраивают maproot=root для конкретного хоста, а не для всей сети.

NFSv4 плюс Kerberos добавляет аутентификацию пользователей и шифрование трафика, но требует настроенного KDC и синхронизации времени. Для бэкапов и сборок обычно хватает NFSv3 с ограничением по подсети и корректными правами на уровне ZFS. Сравнение iSCSI, NFSv4 и SMB3 по сценариям с настройкой CHAP, ACL и multipath собрано в статье сетевые протоколы для систем хранения: iSCSI, NFS и SMB.

Мониторинг здоровья дисков, scrubbing и алерты

Как читать SMART и zpool status

В SMART следят за атрибутами 5 (Reallocated_Sector_Ct), 187 (Reported_Uncorrect), 197 (Current_Pending_Sector), 198 (Offline_Uncorrectable) и 199 (UDMA_CRC_Error_Count). Рост любого из них означает деградацию. Атрибут 199 чаще указывает на кабель, экспандер или контроллер, а не на сам диск: проверяют шлейфы и посадочные места.

zpool status показывает состояние устройств: ONLINE, DEGRADED, FAULTED, UNAVAIL, а также счетчики READ, WRITE и CKSUM. Одиночная ошибка CKSUM лечится через zpool clear и повторную проверку скрабом. Всплеск ошибок CKSUM сразу на нескольких дисках указывает на общую причину: RAM без ECC, плохой HBA, питание или перегрев корзины.

Scrub и resilver: расписание и типовые проблемы

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

Resilver запускается при замене диска или после возврата устройства в пул. На 8-16 ТБ дисках процесс занимает от нескольких часов до суток и больше. В это время пул уязвим: при RAIDZ1 любая вторая ошибка чтения приводит к потере данных. Поэтому скраб перед плановой заменой диска и мониторинг zpool status во время resilver это рабочая практика, а не перестраховка.

Замена дисков и восстановление пула

Пошаговая замена диска в mirror и RAIDZ

1. zpool status -v: найти устройство в состоянии FAULTED или DEGRADED и запомнить имя.
2. Определить физический слот: подсветить лоток в интерфейсе корпуса или сверить серийный номер через smartctl -i.
3. Перевести диск в offline: zpool offline poolname device. В зеркале шаг можно пропустить, в RAIDZ он обязателен, иначе контроллер и ZFS потеряют синхронизацию состояния.
4. Заменить диск физически, дождаться появления устройства в системе.
5. Запустить замену: zpool replace poolname olddevice newdevice. Если использован горячий резерв, ZFS подставит его автоматически.
6. Проверить zpool status: должен идти resilver, по завершении состояние вернется в ONLINE.
7. Если новый диск больше остальных, включить autoexpand и вернуть его в пул, чтобы емкость выросла после прохождения по всем дискам vdev.

Замена на диск меньшего размера невозможна, а устройство другого типа секторов (512e против 4Kn) приведет к ошибкам при ashift=9. Диск берут той же модели или с совпадающим физическим сектором.

Восстановление пула после сбоя: zpool import

Если пул не смонтировался, первым делом проверяют видимость дисков на уровне системы. Пул отсутствует в списке, значит проблема в питании, кабелях или контроллере, а не в данных.

• zpool import без параметров: список доступных для импорта пулов, включая те, что были активны на другом узле.
• zpool import poolname: импорт в штатном режиме.
• zpool import -f poolname: принудительный импорт, если пул помечен как активный на другом хосте.
• zpool import -o readonly=on poolname: монтирование только для чтения, чтобы забрать данные без риска.
• zpool import -R /mnt poolname: импорт с альтернативным корнем для разбора содержимого.

Команда zpool destroy удаляет пул мгновенно, и полагаться на асинхронное восстановление метаданных в течение нескольких минут нельзя: пул перестают обновляться на дисках, и надежного отката нет. Перед любой разрушительной командой сначала снимают zfs send в файл или на другой сервер.

Типовые ошибки, ведущие к потере пула

Список собран из сценариев, которые заканчиваются потерей данных, а не временным снижением скорости:

• RAIDZ1 на дисках больше 2 ТБ: во время resilver вторая ошибка чтения оставляет пул недоступным.
• Дедупликация без RAM: DDT уходит в swap, запись деградирует до сотен килобайт в секунду.
• RAID-контроллер или дешевый SATA-контроллер на Marvell 9230: диски отваливаются из пула пачками.
• Отсутствие ECC при активной записи: битовая ошибка памяти фиксируется на диск как валидный блок.
• sync=disabled без SLOG ради тестов производительности: при сбое питания теряются подтвержденные записи.
• Снапшоты только на том же пуле: отказ массива уничтожает и данные, и копии.
• zpool destroy выполненный не на том стенде: восстановления метаданных может не быть.
• Заполнение пула выше 80%: запись фрагментируется, производительность падает ступенькой.
• Игнорирование SMART и ошибок CKSUM: диск с растущими pending-секторами доживает до второго отказа.

RAIDZ1 и большие диски: почему это опасно

Современный HDD за 10-16 ТБ имеет заявленный уровень неисправимых ошибок чтения порядка 1 на 10^14-10^15 бит. При resilver пул читает все оставшиеся диски целиком: для RAIDZ1 из трех дисков по 12 ТБ это десятки терабайт чтения, за время которого вероятность наткнуться на нечитаемый сектор перестает быть теоретической. Вторая ошибка в RAIDZ1 означает потерю пула целиком. Для дисков от 4 ТБ практический минимум это RAIDZ2, для 16 ТБ и критичных данных RAIDZ3 или зеркала.

Дедупликация и нехватка RAM: как убить производительность

Симптомы включенной дедупликации без запаса памяти: время записи растет в разы, zpool status показывает высокий load и растущий объем таблицы DDT, в логах появляются сообщения о невозможности выделить память. Пул может уйти в состояние, когда данные не записываются вовсе. Лечение одно: выключить дедупликацию на датасете, дождаться, пока новые записи пойдут без DDT, и пересоздать датасет через zfs send и zfs recv. Профилактика: оценка zdb -S до включения и коэффициент дедупликации выше 1,5.

Чек-лист развёртывания и итоги

Собранный список проверок перед вводом хранилища в работу:

• HBA в IT mode, RAID-функции отключены, прошивка проверена через sas3flash -list.
• ECC RAM, минимум 16 ГБ для файлового сервера и 32 ГБ для iSCSI.
• ashift=12 для всех современных дисков, проверка через zpool get ashift.
• RAIDZ2 как базовый уровень для офиса, mirror для виртуализации, stripe только для временных данных.
• SLOG на NVMe с PLP, если есть iSCSI, NFS с sync или базы данных.
• Задача Periodic Snapshot Task с хранением 7-30 дней.
• Репликация zfs send/recv на второй узел или в облако, правило 3-2-1.
• SMART: короткий тест ежедневно, длинный раз в неделю, алерты на почту.
• Скраб раз в месяц, окно низкой нагрузки, контроль времени выполнения.
• Датасеты нарезаны по назначению: медиа 1M, общие файлы 128K, ВМ 16K, сжатие lz4.
• Зарезервирован один горячий резерв или сменный диск в серверной.
• Свободное место в пуле не опускается ниже 20%.

TrueNAS с ZFS дает офису и дому то, чего нет у обычных RAID-массивов: контроль целостности, мгновенные копии и восстановление после ошибок носителя. Работает это при соблюдении трех условий: прямой доступ к дискам через IT mode, достаточный объем RAM и топология с двумя дисками четности. Начните с железа и топологии пула, затем настройте снапшоты, репликацию и протоколы доступа. Первый скраб после ввода в работу и настроенные алерты покажут, что массив собран правильно.