TrueNAS SCALE это быстрый способ собрать надёжное хранилище на ZFS с понятной веб-панелью: ставим систему на выделенный сервер, создаём пул, нарезаем датасеты, включаем SMB и NFS для файлов, при необходимости поднимаем iSCSI под виртуализацию, настраиваем снапшоты и репликацию, а приложения разворачиваем через Apps. По времени это реально сделать за вечер, но есть два места, где люди чаще всего ломают себе жизнь: неправильный выбор дисков под ZFS и небезопасная схема доступа к данным. Ниже даю пошаговый, проверяемый план, с командами диагностики и быстрыми исправлениями.

Когда TrueNAS SCALE ставят на VPS, а когда нужен выделенный сервер

TrueNAS SCALE технически можно запустить в VM, но для настоящего ZFS-хранилища вам нужны “настоящие” диски, а не виртуальные образы. Поэтому типичный продакшн-вариант это выделенный сервер с нормальными SATA/SAS/NVMe и возможностью расширения. VPS уместен как управляющий узел (мониторинг, бэкапы, прокси-доступ), либо как вспомогательный сервер для репликации, если у вас второй узел в другом датацентре.

Если вы выбираете железо, ориентируйтесь хотя бы на базовые требования: 2-core x86_64, от 8 ГБ RAM минимум, загрузочный SSD от 16 ГБ, и два одинаковых диска минимум под один пул. На практике комфорт начинается с 16–32 ГБ и ECC, особенно если планируются iSCSI, много клиентов или Apps. 

Если нужно “включил и работает” без плясок, логика простая: арендовать выделенный сервер под TrueNAS SCALE в NL/DE/UK и сразу заложить запас по дискам и памяти. В HSTQ обычно так и делают: честные vCPU/NVMe там, где это уместно, а под хранилище берут dedicated, плюс администрирование 24/7 под Linux и Windows, чтобы не зависеть от одного человека “который знает как было настроено”.

Подготовка перед установкой: чтобы потом не переделывать

Сначала решите три вещи, иначе вы почти гарантированно будете мигрировать через месяц.

Первое: как вы грузитесь. Лучший вариант это отдельный маленький SSD под систему, а данные живут отдельно. Для спокойствия в продакшне загрузочный диск зеркалят (boot mirror).

Второе: схема ZFS. Если дисков два, это mirror. Если 4–6 дисков, чаще всего RAIDZ1/RAIDZ2 (и почти всегда RAIDZ2, если данные важные). Смешивать разные по размеру диски плохая идея, вы упрётесь в меньший.

Третье: сеть и доступ. Файловые шары (SMB/NFS) не должны торчать в интернет. Для удалённого доступа делайте VPN, либо ограничивайте firewall по вашим IP, либо выносите доступ через bastion.

Установка TrueNAS SCALE с ISO

Установка делается с ISO на флешку, дальше обычный инсталлер.

1. В BIOS включите UEFI boot, а если сервер будет с passthrough дисков в VM (Proxmox), заранее включите VT-d/AMD-Vi (IOMMU).

2. Выберите загрузочный SSD и поставьте систему туда. Не ставьте TrueNAS на тот же пул, где данные.

3. После установки задайте пароль admin/root, перезагрузитесь, на консоли получите IP веб-интерфейса и зайдите с браузера.

После первого входа сразу обновитесь на актуальный train и сделайте базовую сетевую настройку (статический IP, DNS, шлюз). С версией важно не гадать: в ветке 24.10 (Electric Eel) кардинально менялся механизм Apps, и это влияет на то, как вы будете разворачивать приложения. 

Создаём ZFS-пул и правильную структуру датасетов

В TrueNAS главное правило простое: делите данные датасетами, а не “шарьте весь пул”. Это сильно упрощает права, квоты, снапшоты и дальнейшую жизнь. Документация прямо рекомендует создавать датасет под шару и не делиться корнем пула. 

Типовая структура для малого офиса или команды:

• pool0/backup

• pool0/media

• pool0/projects

• pool0/vmstore (если будет iSCSI или NFS под гипервизор)

На каждую шару делайте отдельный датасет, задавайте Share Type (SMB или NFS), включайте компрессию (обычно lz4), а для “много мелких файлов” полезно сразу подумать про recordsize (это уже настройка под вашу нагрузку).

Проверка на стороне shell (в веб-панели есть Shell):

zpool status
zfs list
zfs get compression,recordsize,atime pool0

Если zpool status показывает DEGRADED или ошибки чтения, не “ждите пока само пройдёт”. Сразу смотрите какой диск и что с ним, иначе вы пропустите момент, когда зеркало перестанет быть зеркалом.

Настройка SMB: общие папки для Windows и macOS

SMB это самый популярный сценарий. Рабочая схема такая: создаёте датасет с SMB preset, потом создаёте шару, потом включаете сервис SMB и автозапуск.

Важный момент: “шару создал, но не открывается” почти всегда потому, что SMB service не запущен. В TrueNAS это отдельный переключатель в Services, и его надо включить. 

Проверка с сервера:

systemctl status smbd --no-pager
testparm -s 2>/dev/null | head
smbstatus 2>/dev/null | head

Быстрые ошибки и починка:

• Ошибка “Access denied” или постоянный запрос пароля: проверьте права датасета и пользователя, и не пытайтесь работать под root.

• Не видит шару в сети: проверьте, что SMB service включён и firewall не режет 445/TCP внутри вашей LAN/VPN.

• Очень медленно по SMB: проверьте, что клиент не ходит через Wi-Fi, что нет 100M линка, и что диски не в ошибках. Затем уже включайте тюнинг.

NFS для Linux и гипервизоров

NFS удобен для Linux-клиентов и некоторых сценариев виртуализации. Логика та же: отдельный датасет, отдельная export-настройка, и только нужные сети в allowed hosts.

Проверка:

systemctl status nfs-server --no-pager
showmount -e 127.0.0.1

Если NFS не монтируется, первое что проверяется это сеть и ACL на export, второе это что сервис реально запущен.

iSCSI под виртуальные машины: когда нужно и как не убить производительность

iSCSI даёт блочный доступ, его любят гипервизоры. Но это самый требовательный сценарий к сети и дискам. Здесь почти всегда имеет смысл 10G сеть, адекватное количество RAM и правильный ZVOL.

Рекомендация простая: если вы делаете iSCSI для продакшн VM, не экономьте на памяти и не ставьте это на “первый попавшийся” сервер. На минималках оно заведётся, но под нагрузкой станет источником рандомных лагов и нервов.

Проверка ZFS и латентности начинается с базового:

zpool iostat -v 1
zpool status

Если видите постоянные “busy” и очередь на дисках, проблема не в TrueNAS, а в железе или в слишком агрессивной нагрузке на один vdev.

Apps в TrueNAS SCALE: что изменилось и как ставить свои приложения

Если вы привыкли к старой схеме “всё на Kubernetes”, важно знать: в TrueNAS SCALE 24.10 backend Apps переехал с Kubernetes на Docker. Это влияет на миграции и на то, как вы деплоите кастомные вещи. 

В 24.10+ есть два нормальных пути поставить стороннее приложение:

• Custom App (мастер установки Docker image)

• Install via YAML, где вы задаёте Docker Compose YAML прямо в UI 

Практичная стратегия такая: всё критичное (VPN, мониторинг, backup agent) держите максимально просто и воспроизводимо через YAML/Compose, без экзотических каталогов, которые потом не мигрируют. Это особенно важно, если вы раньше использовали сторонние каталоги: часть из них не мигрирует автоматически при переходе на 24.10. 

Снапшоты, scrub и SMART: три вещи, которые делают TrueNAS “настоящим хранилищем”

ZFS даёт вам силу, если вы ею пользуетесь.

Снапшоты: на датасеты с рабочими файлами поставьте расписание, например каждый час хранить сутки, ежедневно хранить месяц. Тогда “удалили папку” перестаёт быть катастрофой.

Scrub: регулярная проверка пула. Это не бэкап, но это раннее обнаружение проблем на дисках.

SMART: тесты дисков и алерты. Диск редко умирает “внезапно”, обычно он долго предупреждает.

Проверка в shell:

zpool status
smartctl -a /dev/sda | head -n 40
smartctl -a /dev/sdb | head -n 40

Если smartctl не видит диски, у вас может быть HBA/RAID-контроллер в неправильном режиме. Для ZFS нужен HBA/JBOD/IT-mode, а не аппаратный RAID, иначе вы теряете смысл ZFS.

Как проверить, что всё работает

Вот минимальный чек, который ловит 80 процентов проблем до того, как они станут аварией.

1. Пул здоров:

zpool status

Должно быть ONLINE без ошибок.

2. Датасеты на месте:

zfs list

3. Сервис шар запущен:

systemctl status smbd --no-pager
systemctl status nfs-server --no-pager

4. С клиента проверка доступа:

• Windows: \\IP_TrueNAS\share

• Linux NFS: mount -t nfs IP:/mnt/pool0/projects /mnt/test

Если всё это проходит, можно считать, что базовая часть сделана правильно.

Быстрые поломки и их исправление за 2 минуты

Не монтируется SMB, хотя пароль верный. Почти всегда это права на датасете или выключенный SMB сервис. Проверьте Services и права на датасете, и убедитесь, что вы подключаетесь обычным пользователем, а не root. 

Пул стал DEGRADED. Смотрите zpool status, меняйте конкретный диск и делайте resilver. Не откладывайте, DEGRADED это не “когда-нибудь потом”.

Apps пропали после обновления на 24.10. Причина часто в миграции с Kubernetes на Docker и в использовании сторонних каталогов. Планируйте апгрейд, проверяйте совместимость приложений и готовьтесь переустановить часть кастомных деплоев через YAML/Compose. 

Траектория роста: от одного узла до отказоустойчивости и когда пора “в железо”

Стартовый уровень это один сервер TrueNAS SCALE и регулярные снапшоты. Следующий шаг это второй узел для репликации ZFS: вы получаете “почти HA” по данным, когда основной сервер умер, вы поднимаете доступ со второго. Для бизнеса это обычно самый рациональный апгрейд за свои деньги.

Дальше варианты:

• Если нужны минимальные простои и автоматический failover, это уже территория enterprise-решений и специализированных HA-схем. В DIY вы либо платите сложностью, либо деньгами.

• Если выросли объёмы, IOPS и нагрузка, пора переходить на выделенный сервер с ECC, HBA в IT-mode и нормальной сетью.

• Если вы строите storage-платформу для клиентов (много арендаторов, объектное хранение, сервисы вокруг), может понадобиться отдельная адресация, подсети IPv4, а иногда и LIR/ASN, чтобы управлять маршрутизацией и репутацией. Тут уже важно, чтобы провайдер мог помочь с IPv4, PTR/WHOIS и сетевыми вещами не “по праздникам”, а по-человечески.

Если вам нужно быстро развернуть TrueNAS SCALE на выделенном сервере и сразу сделать всё правильно (диски, ZFS, шары, снапшоты, репликация, Apps), практичнее заказать сервер с нужной локацией (NL/DE/UK/USA/RU/SG) и администрированием 24/7, чем потом неделю разгребать последствия случайных настроек.