TrueNAS для хранения изображений: настройка датасетов, ZFS и сетевых шар

Почему TrueNAS подходит для хранения изображений

Хранилище изображений на TrueNAS SCALE собирается за один вечер: пул из пары зеркал, датасет с recordsize=128K и сжатием LZ4, SMB-шара для дизайнеров и NFS-экспорт для рендер-фермы. Всё делается в веб-интерфейсе, руками править конфиги не нужно. Под капотом работает OpenZFS: файловая система с контрольными суммами блоков, копированием при записи, сжатием, снапшотами и потоковой репликацией.

Для каталога, где лежат десятки тысяч JPEG по 200-500 КБ, RAW-файлы по 40 МБ и превью по 15 КБ, критичны три параметра датасета: recordsize, compression и atime. Неверный recordsize заставляет мелкий файл занимать целый блок записи, включённый atime добавляет операцию записи при каждом чтении, а неудачный тип пула превращает случайное чтение в очередь с задержками в десятки миллисекунд. Ниже дана рабочая конфигурация с конкретными значениями и порядком шагов.

TrueNAS SCALE и TrueNAS CORE похожи логикой интерфейса, но ядро разное: SCALE построен на Linux, CORE на FreeBSD. Набор сервисов и названия пунктов меню отличаются, поэтому шаги ниже даны для TrueNAS SCALE 24.04 (Dragonfish) и более новых релизов. В CORE последовательность та же, часть настроек SMB и NFS ищется в других разделах.

Ключевые возможности ZFS для медиаданных

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

• Контрольные суммы каждого блока. ZFS считает SHA-256 для блока данных и отдельно для метаданных. Блок проверяется при каждом чтении: если сумма не сходится, система берёт корректную копию с другого диска и перезаписывает повреждённый блок. Плановый scrub в TrueNAS запускается раз в 35 дней и проверяет весь пул. ext4 и NTFS проверяют только метаданные, поэтому битый сектор в JPEG там обнаружится лишь при открытии файла.
• Копирование при записи. Новые блоки пишутся в свободное место, старые освобождаются после фиксации транзакции. Отсюда два практических следствия: снапшот создаётся моментально и занимает байты метаданных, а после сбоя питания пул монтируется без fsck. Для каталога с сотнями тысяч файлов это экономит часы простоя.
• Прозрачное сжатие. LZ4 и ZSTD работают на уровне блоков и незаметны для приложений. JPEG и PNG уже сжаты, выигрыш по ним близок к нулю, зато метаданные, нулевые хвосты блоков и текстовые описания сжимаются в разы. Распаковка LZ4 идёт со скоростью нескольких гигабайт в секунду на ядро и почти не добавляет задержек.
• Снапшоты и репликация. Передача zfs send включает только изменившиеся блоки, поэтому инкрементальная репликация на второй сервер по расписанию занимает минуты, а не часы.
• Настройка на уровне датасета. recordsize, compression, квоты, ACL и политики снапшотов задаются отдельно для каждого датасета. Каталог превью и архив RAW живут в одном пуле с разными параметрами.

Есть и цена. ZFS требовательна к памяти: ориентир 1 ГБ RAM на 1 ТБ пула плюс место под ARC, практический минимум 8 ГБ. Аппаратные RAID-контроллеры без IT-режима лучше не использовать, а заполнение пула выше 80-90% заметно снижает скорость записи из-за фрагментации свободного пространства.

Сценарии использования: от рабочей группы до S3-хранилища

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

Разделяйте датасеты по протоколу: /mnt/pool/images_smb, /mnt/pool/images_nfs, /mnt/pool/images_s3. Так проще управлять правами, квотами и расписанием снапшотов, а ошибка в ACL одной шары не затронет остальные. Если вы ещё выбираете платформу под медиахранилище, сравнение Synology, QNAP и TrueNAS SCALE поможет оценить компромиссы до покупки железа.

Создание пула и датасетов с оптимальными параметрами ZFS

Пул создаётся в разделе Storage -> Create Pool: мастер предложит выбрать диски, тип layout и уровень избыточности. Параметры, которые влияют на судьбу хранилища на годы вперёд, выбираются именно здесь: расширять пул дешевле, чем пересобирать его с потерей данных.

Выбор типа пула: mirror vs RAIDZ

Зеркала и RAIDZ различаются не только ёмкостью, но и поведением на мелких файлах.

• Mirror. Каждый диск хранит полную копию данных, полезная ёмкость составляет 50%. Случайные операции распределяются по всем дискам, поэтому пул из четырёх HDD даёт примерно 150-200 IOPS на чтении вместо 75-100 у одиночного диска. Восстановление после замены диска идёт быстрым копированием с зеркала, часы, а не сутки. Расширение делается добавлением пары дисков.
• RAIDZ1. Из четырёх дисков по 4 ТБ получается 12 ТБ полезной ёмкости при отказе одного диска. Случайное чтение упирается в производительность одного диска, около 75-100 IOPS, потому что блоки размазаны по всем дискам vdev. Пересборка после замены диска на 8 ТБ идёт от 10 часов и выше, и в это время пул не защищён от второго отказа.
• RAIDZ2. Те же четыре диска по 4 ТБ дают 8 ТБ полезной ёмкости и допускают отказ двух дисков. Разумный выбор для архива изображений и для любых пулов, где диски больше 4 ТБ.

Итог по трём вариантам на четырёх дисках по 4 ТБ: mirror даёт 8 ТБ и максимум IOPS, RAIDZ1 даёт 12 ТБ и производительность одного диска, RAIDZ2 даёт 8 ТБ и двойную защиту. Активная работа с изображениями (поиск, превью, экспорт, синхронизация облачных клиентов) выигрывает от зеркал. Архив, который читают редко, экономичнее держать на RAIDZ2.

RAIDZ1 оправдан только на трёх-четырёх дисках небольшой ёмкости. Начиная с OpenZFS 2.3 (TrueNAS SCALE 25.04 и новее) появилось расширение RAIDZ добавлением диска по одному, но ёмкость растёт без перераспределения старых блоков, а IOPS vdev не меняется.

Для каталогов с миллионами мелких превью полезен special vdev: отдельный зеркальный набор SSD под метаданные. Правило одно: потеря special vdev означает потерю всего пула, поэтому минимум два SSD в зеркале, а для RAIDZ-пулов практичнее три. Дедупликацию для изображений включать не стоит: уникальных блоков почти нет, а таблица дедупликации съест память.

Настройка recordsize, compression и atime

recordsize задаёт максимальный размер блока записи. Файл меньше recordsize хранится одним блоком, поэтому значение подбирают под типичный размер файла.

Сжатие для изображений выбирают по содержимому. Тип compression=on в OpenZFS означает LZ4: он распаковывается быстрее, чем NVMe отдаёт данные, и не бьёт по процессору. ZSTD уровней 1-19 сжимает метаданные и низкоэнтропийные TIFF в 1,5-2 раза плотнее, но на каждый гигабайт записи тратит больше CPU. Для каталога уже сжатых JPEG оба алгоритма дают прирост около нуля, а вот нулевые хвосты блоков и служебные структуры сжимаются всегда, поэтому LZ4 включают без колебаний.

atime=off обязателен. При включённом atime ядро обновляет время доступа при каждом чтении: каталог из 100 000 изображений, который сканируют раз в день, порождает 100 000 лишних операций записи. На HDD это десятки секунд случайных записей, отобранных у полезной нагрузки. Снапшоты при этом растут быстрее, потому что меняются метаданные.

zfs create -o recordsize=128K -o compression=lz4 -o atime=off -o xattr=sa -o acltype=nfsv4 pool/images_smb

Ту же команду можно выполнить через веб-интерфейс: Datasets -> Add Dataset -> Advanced Options. В меню задаются Compression, Record Size, ACL Type и Access Time.

Изменение recordsize не переписывает уже записанные блоки: старые файлы остаются с прежним размером блока, новый параметр применяется к последующим записям. Пока датасет пуст, значение меняется без последствий, поэтому все параметры выставляют до первой загрузки изображений. Пересоздание датасета для смены recordsize на заполненном хранилище означает полную перезапись данных.

Права доступа и владельцы датасета

Права задают сразу после создания датасета, иначе первая же шара придётся перенастраивать на живых пользователях.

• Создайте группу images и добавьте в неё нужных пользователей: Credentials -> Local Users, затем Credentials -> Local Groups.
• Владельцем датасета сделайте администратора (или root), группой - images, права группы - read/write/execute.
• Для SMB-датасета выбирайте acltype=nfsv4: это привычные Windows ACL с наследованием и гранулярными правами. Для чисто Linux-сценария подходит posixacl.
• Смена acltype на датасете с данными требует очистки существующих ACL, TrueNAS предупредит об этом отдельным диалогом. Поэтому тип ACL фиксируют при создании.

В интерфейсе датасета есть готовые пресеты прав: Open, Restricted, Private. Для хранилища изображений подходит Restricted: владелец и группа получают полный доступ, остальные не получают ничего.

Настройка SMB-шары для рабочих групп

SMB - основной протокол, если в команде есть Windows и macOS. В TrueNAS SCALE он включается одним переключателем, но для стабильной работы нужны ещё две настройки: корректный тип ACL и расширения для macOS.

Создание шары и настройка ACL

1. Services -> SMB: включите сервис, оставьте включённой службу WSD, чтобы сервер виделся в сетевом окружении Windows. Для macOS отметьте Enable Apple SMB2/3 protocol extensions, тогда Finder не будет создавать конфликтующие файлы метаданных.
2. Shares -> Windows (SMB) Shares -> Add. Path укажите как /mnt/pool/images_smb, Name как images, Purpose оставьте Default share parameters.
3. В блоке Advanced включите Enable ACL и Asynchronous I/O. Асинхронный ввод-вывод снимает часть накладных расходов при параллельной записи из нескольких рабочих станций.
4. Откройте Edit ACL: владелец root или администратор, группа images, права группы Modify, флаг Apply permissions recursively. Пользователю из группы этого достаточно, остальным доступ не выдавайте.
5. Если нужны теневые копии Windows, включите Enable Shadow Copies: система будет отдавать снапшоты ZFS как предыдущие версии файлов в свойствах папки.

Расширенные примеры настройки прав и разбор ошибок доступа собраны в руководстве по общему доступу TrueNAS для Windows, Linux и macOS.

Подключение из Windows и macOS

• Windows. Проводник -> адресная строка -> \\192.168.1.10\images. Если сервер не виден в разделе Сеть, подключайтесь по IP: поиск по имени зависит от WSD и разрешения имён. Для постоянной работы подключите папку как сетевой диск.
• macOS. Finder -> Переход -> Подключиться к серверу -> smb://192.168.1.10/images. С включёнными расширениями Apple SMB2/3 файлы .DS_Store и расширенные атрибуты не ломают права на общем каталоге.
• Linux (при необходимости). Монтирование через cifs: mount -t cifs //192.168.1.10/images /mnt/images -o username=designer,uid=1000,gid=1000,vers=3.1.1,iocharset=utf8

Диагностика на сервере: smbstatus показывает активные сессии и открытые файлы, testparm проверяет конфигурацию, журналы лежат в /var/log/samba4. Типовая причина отказа - пользователь не входит в группу images или ACL применили без рекурсии.

Настройка NFS-экспорта для Linux-клиентов

Различия SMB и NFS: что выбрать

• SMB удобен в смешанной сети: аутентификация по пользователю, Windows ACL, теневые копии, встроенная поддержка macOS. Цена - больше служебного трафика на операцию.
• NFS предпочтителен для Linux-парка и рендер-ферм: ниже накладные расходы, NFSv4.2 умеет параллельный доступ и блокировки без внешних служб. Взамен требуется синхронизация UID и GID между сервером и клиентами.
• iSCSI даёт блочное устройство для виртуальных машин и баз данных, но не общий каталог с изображениями.
• S3 нужен приложениям и бэкапам, для работы с файлами как в проводнике он не подходит.

Практическое правило: смешанные ОС на рабочих местах означают SMB, только Linux на клиентах означает NFS. Разбор параметров ускорения обоих протоколов есть в материале о сетевых протоколах для систем хранения.

Настройка прав и монтирование на клиенте

1. Services -> NFS: включите сервис, поднимите число серверных потоков (для 20-40 клиентов разумно 32-64), включите поддержку NFSv4 и задайте домен, совпадающий с доменом в idmapd на клиентах.
2. Shares -> Unix (NFS) Shares -> Add: Path = /mnt/pool/images_nfs, Network = 192.168.1.0/24, Maproot User оставьте пустым для обычной работы и укажите root только при необходимости административного доступа. Для доступа от непривилегированных процессов используйте Mapall User и Mapall Group.
3. Права на стороне сервера выставляются владельцем и группой: chown -R designer:images /mnt/pool/images_nfs, затем chmod -R 2775 /mnt/pool/images_nfs. Бит setgid обеспечивает наследование группы в новых файлах.
4. Клиент монтирует экспорт в /etc/fstab строкой вида: 192.168.1.10:/mnt/pool/images_nfs /mnt/images nfs4 rw,hard,noatime,_netdev,rsize=1048576,wsize=1048576,vers=4.2 0 0

Ошибка Permission denied почти всегда означает рассинхрон идентификаторов. Сверьте id пользователя на клиенте и владельца каталога на сервере. Если UID отличаются, приведите их к одному значению либо настройте NFSv4 с idmapd и общим доменом. Пошаговая настройка экспорта с оптимизацией recordsize и ACL описана в отдельном материале про экспорт ZFS dataset через NFS в TrueNAS SCALE.

Публикация хранилища через S3-совместимый шлюз

Когда нужен S3-доступ к изображениям

S3 нужен там, где файлы читает код: загрузка аватарок и фотографий из мобильного приложения, раздача картинок через CDN, хранение бэкапов приложения, генерация ссылок с ограниченным сроком жизни. S3 даёт версионирование объектов, правила жизненного цикла и HTTP API вместо файловых блокировок.

Ограничения существенные: объектное хранилище не поддерживает переименование и частичную запись, листинг отдаёт страницами по 1000 объектов, а монтирование S3 как файловой системы через s3fs даёт посредственную скорость на мелких файлах. Каталог с сотнями тысяч превью лучше держать на SMB или NFS, а в S3 публиковать уже подготовленные изображения приложения.

Настройка S3-сервиса и создание bucket

1. Services -> S3: включите сервис. В TrueNAS SCALE 24.04 и 24.10 он собран на MinIO, занимает порт 9000 для API и 9001 для консоли. В более новых релизах пункт S3 может отсутствовать: тогда MinIO поднимают отдельным контейнером на этом же сервере. Проверьте наличие сервиса в своей версии до планирования работ.
2. Выберите датасет для бакета, например /mnt/pool/images_s3, созданный с recordsize=128K и atime=off.
3. Создайте пару ключей: access key и secret key. Храните секрет в менеджере паролей, он показывается один раз.
4. Ограничьте привязку к нужному IP сервера, если кроме приложений доступ к шлюзу не нужен.

aws --endpoint-url http://truenas:9000 s3 mb s3://images aws --endpoint-url http://truenas:9000 s3 cp photo.jpg s3://images/2026/09/

Из Python работа идёт через boto3 с параметром endpoint_url и подписью AWS Signature V4. Для прямых загрузок из браузера или мобильного клиента используйте presigned URL: приложение получает ссылку с ограниченным временем жизни и грузит файл напрямую в хранилище, минуя ваш бэкенд.

Три предупреждения по эксплуатации. Первое: по умолчанию трафик идёт без TLS, для публикации в интернет ставьте перед шлюзом обратный прокси с сертификатом. Второе: версионирование бакета удерживает все прежние версии объектов, без lifecycle-правила хранилище заполнится неожиданно быстро. Третье: если приложение анализирует изображения (классификация, модерация, генерация alt-текста), удобно вынести эту логику на внешний API. Агрегатор AiTunnel даёт единый интерфейс к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях и управлением ключами, что упрощает обработку медиатеки без отдельной интеграции под каждую модель.

Защита медиаданных: снапшоты и репликация

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

Стратегия снапшотов для изображений

Изображения меняются редко, но каталог переживает массовые импорты и переименования. Рабочее расписание: ежечасные снапшоты с хранением 24 штук, ежедневные с хранением 30, еженедельные с хранением 12, ежемесячные с хранением 6. Такой набор покрывает сутки оперативной работы и год истории.

• Перед массовым импортом или переименованием создавайте снапшот вручную: он станет точкой отката на несколько минут.
• Включайте флаг Recursive для дерева датасетов, иначе дочерние наборы останутся без защиты.
• Помните, что снапшот удерживает удалённые блоки: место расходуется только на изменения, но при активной работе набегает быстро.
• Снапшот на том же сервере не заменяет резервную копию: сбой пула уничтожит и данные, и историю.

zfs snapshot -r pool/images_smb@before-import-2026-09-12 zfs list -t snapshot -o name,used,creation pool/images_smb

Политики создаются в Tasks -> Periodic Snapshot Tasks: выберите датасет, расписание (Hourly, Daily, Weekly) и срок хранения в соответствующих полях Retention.

Настройка репликации на второй сервер

1. Создайте пару SSH-ключей в Credentials -> Backup Credentials -> SSH Keypairs, добавьте публичную часть пользователю на целевом сервере.
2. Проверьте подключение в Credentials -> SSH Connections: TrueNAS сохранит соединение с указанным пользователем и портом.
3. Tasks -> Replication Tasks -> Add: источником выберите существующую задачу периодических снапшотов, целью - второй сервер и датасет на нём.
4. Включите шифрование потока (raw send), если данные уходят за пределы доверенной сети: без него zfs send передаёт содержимое в открытом виде.
5. Задайте расписание, например каждые 6 часов, лимит пропускной способности и политику хранения копий. Разумный вариант - хранить 7 последних снапшотов на цели.
6. Для защиты от отказа пула на том же сервере настройте локальную репликацию в резервный пул: логика задач та же, только цель указывается как локальный набор данных.

Репликация работает поверх zfs send и передаёт только изменившиеся блоки: первая копия занимает столько же места, сколько источник, каждая следующая - доли процента. Свободного места на цели нужно не меньше, чем занято на источнике, плюс запас на удержание снапшотов.

Схема 3-2-1 для медиахранилища выглядит так: рабочая копия на SMB-датасете, локальная реплика в резервный пул, шифрованный поток на площадку вне офиса. Роль внеплощадочного приёмника подходит облачному серверу с ZFS-совместимой системой: Timeweb Cloud предоставляет VDS и хранилище, которые можно использовать как цель для зашифрованных zfs send потоков и как площадку для сервисов, работающих с медиатекой.

Проверка производительности и типичные ошибки

Как измерить скорость хранилища

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

dd if=/dev/zero of=/mnt/pool/images_smb/testfile bs=1M count=10000 conv=fdatasync status=progress

Чтение измеряют после сброса кэша ARC, иначе цифры покажут скорость памяти, а не дисков:

echo 3 > /proc/sys/vm/drop_caches dd if=/mnt/pool/images_smb/testfile of=/dev/null bs=1M status=progress

Для хранилища изображений важнее случайное чтение мелких блоков, его показывает fio:

fio --name=randread --ioengine=libaio --direct=1 --rw=randread --bs=128k --iodepth=16 --numjobs=4 --size=4G --runtime=60 --group_reporting --filename=/mnt/pool/images_smb/fiofile

Ориентиры для четырёхдискового зеркала на HDD: 150-200 IOPS случайного чтения, то есть примерно 150-200 файлов в секунду при попадании в кэш метаданных. При 1 Гбит/с канал упирается в 110 МБ/с, для рендер-фермы нужен 10 Гбит/с. Полезно смотреть Reporting -> ZFS: доля попаданий в ARC выше 90% означает, что горячие превью отдаются из памяти. Не забудьте удалить тестовые файлы после замеров.

Частые ошибки при настройке TrueNAS для изображений

1. recordsize=1M на каталоге превью. Каждый файл на 20 КБ занимает блок в 1 МБ, нулевой хвост сжимается LZ4, но метаданные и ARC расходуются впустую, а случайное чтение замедляется. Исправление: отдельный датасет для превью с recordsize=16K.
2. Включённый atime. Лишние записи на каждое чтение, ускоренный рост снапшотов, падение скорости обхода каталога. Исправление: zfs set atime=off pool/images.
3. RAIDZ1 на дисках 8 ТБ и больше. Пересборка идёт сутками, и второй отказ в это окно приводит к потере пула. Исправление: RAIDZ2 или зеркала для новых пулов, для существующего - усиленный мониторинг состояния дисков.
4. Шара без ACL. При acltype=posixacl права в Windows выглядят непривычно и управляются только через chmod. Исправление: nfsv4 для SMB-датасетов, изменение типа ACL до наполнения хранилища.
5. Снапшоты без retention. Пул, заполненный на 100%, перестаёт принимать записи, а очистка занимает часы. Исправление: сроки хранения в каждой задаче плюс квота на датасет и оповещения о заполнении.
6. Рассинхрон UID на NFS. Клиент видит Permission denied при формально верных правах. Исправление: единые идентификаторы или NFSv4 с idmapd.
7. Один SSD в special vdev. Отказ диска уносит весь пул. Исправление: минимум зеркало из двух SSD, мониторинг их износа.

Заключение: чек-лист внедрения

1. Спланируйте железо: минимум 8 ГБ RAM, HBA в IT-режиме, диски под сценарий.
2. Создайте пул: mirror для активной работы с изображениями, RAIDZ2 для архива.
3. Создайте датасеты под SMB, NFS и S3 отдельно, с recordsize=128K (16K для превью, 1M для RAW), compression=lz4, atime=off, xattr=sa, acltype=nfsv4.
4. Настройте группу и владельца датасета, проверьте права пресетом Restricted.
5. Включите SMB, создайте шару с Enable ACL, проверьте подключение из Windows и macOS.
6. При наличии Linux-клиентов включите NFS, создайте экспорт, синхронизируйте UID и GID, проверьте монтирование.
7. Если файлы читает код, поднимите S3-шлюз на отдельном датасете, выпустите ключи и настройте lifecycle-правила.
8. Создайте задачи периодических снапшотов с retention и репликацию на второй сервер или в резервный пул.
9. Прогоните тесты dd и fio, зафиксируйте базовые цифры, включите оповещения о заполнении пула и состоянии дисков.

Инструкция актуальна для TrueNAS SCALE 24.04 и более новых релизов; в CORE и в будущих версиях названия пунктов меню могут отличаться, поэтому сверяйтесь с интерфейсом своей сборки. Значения recordsize и compression подбирайте под реальный профиль файлов: замерьте средний размер изображения в каталоге и отталкивайтесь от него, а не от общих рекомендаций.