Собираю NAS для офиса до 50 рабочих мест: железо, RAIDZ2, права из AD и бэкап, который реально восстанавливается

Надёжный NAS для офиса до 50 рабочих мест я собираю на серверной плате с ECC, дисках CMR в RAIDZ2 и TrueNAS Community Edition 25.10. Права раздаю доменными группами, снимки делаю каждые 15 минут, а реплику увожу за пределы офиса. Ниже — расчёт ёмкости, комплектация, настройка ZFS и SMB, регламент обслуживания и кейс агентства недвижимости на 18 мест.

С чего начать сборку NAS: требования, а не корпус

Проектирование NAS я начинаю не с корпуса и не с количества отсеков. Сначала выясняю объём существующих данных, годовой прирост, число одновременных пользователей, типы файлов и допустимый простой. Документы, архив видеонаблюдения и диски виртуальных машин дают принципиально разную нагрузку, и смешивать их на одном пуле без расчёта — прямой путь к жалобам «всё тормозит». В рамках ИТ-аутсорсинга для офисов мы собрали уже не один десяток таких хранилищ, и почти каждая неудачная сборка, которую нам приносили на переделку, начиналась с покупки железа до подсчёта.

Ёмкость считаю минимум на четыре года. Пример: 5,4 ТБ сегодня и прирост 30 % в год дают через четыре года около 15,4 ТБ. К этому добавляются снимки (я закладываю 15–20 %), временные файлы и запас. ZFS не любит заполненности до предела: при планировании я держу рабочий потолок около 80 % полезного объёма. Так 15 ТБ данных превращаются в требование примерно 21–22 ТиБ полезного пространства.

Уровень защиты выбираю по нагрузке. Для файлового сервера на жёстких дисках мой выбор по умолчанию — один RAIDZ2 из шести дисков: переживает отказ любых двух и тратит на чётность треть сырой ёмкости. Зеркала оставляю для виртуальных машин и баз данных — там важнее IOPS и быстрый resilver. RAIDZ1 на дисках 8 ТБ и больше для рабочих данных больше не ставлю: восстановление идёт сутками, и второй отказ за это время уже не экзотика. Аппаратный RAID-контроллер под ZFS тоже не беру — он отнимает у файловой системы прямой контроль над дисками.

• зафиксировать RPO — сколько данных допустимо потерять
• зафиксировать RTO — за сколько сервис должен вернуться
• измерить объём, суточные изменения и пик подключений
• разделить файлы, бэкапы, видеонаблюдение и виртуализацию
• назначить владельцев папок до миграции

Какое железо брать для NAS на 20–50 рабочих мест

Мой базовый выбор для офиса — серверная плата Supermicro X13SCL-F под процессоры Intel Xeon E-2400 и память DDR5 ECC UDIMM. Плата даёт ECC и BMC с удалённой консолью через отдельный порт управления — это экономит выезды. Для офиса на 15–25 мест хватает четырёхъядерного Xeon E-2414 и 64 ГБ ECC; для 40–50 мест и активной работы с крупными файлами беру шестиядерный E-2436 и 128 ГБ. Экономить на памяти не советую: ZFS использует её как кэш чтения ARC, и именно RAM, а не SSD-кэш, чаще всего даёт заметный прирост.

Диски — одинаковые SATA CMR с расчётом на работу 24/7, серии NAS или enterprise. Смешивать CMR и SMR нельзя: документация TrueNAS прямо предупреждает, что SMR-накопители дают непредсказуемую запись и затягивают resilver. Если SATA-портов платы не хватает на все отсеки, ставлю HBA в режиме простого контроллера без RAID, например Broadcom 9500-8i. Систему ставлю на зеркало из двух SSD по 240–480 ГБ. Один диск того же типа держу рядом холодным запасом — он не изнашивается в массиве и не ждёт доставки, когда нужен.

Сеть для 20 мест — встроенные гигабитные порты, этого достаточно: рабочие места всё равно на 1 Гбит/с. При 40–50 местах и работе с фото и видео ставлю одну карту 10GbE в управляемый коммутатор: один порт 10 Гбит/с проще и предсказуемее агрегации каналов. Обязателен ИБП с USB или сетевым управлением и запасом времени на корректное выключение. Выбирая между готовым NAS и сборкой, я опираюсь на критерии из статьи NAS или классический файловый сервер: если нужен домен, снимки с «предыдущими версиями» и реплика, самосборка на TrueNAS обычно выигрывает.

• корпус с отсеками горячей замены и маркировкой корзин
• Supermicro X13SCL-F, Xeon E-2414 или E-2436, 64–128 ГБ DDR5 ECC
• диски CMR одной модели + один холодный запас
• 2 SSD под зеркальный загрузочный пул
• HBA без RAID, если не хватает портов платы
• ИБП с управлением, порт BMC в отдельной сети управления

Как запустить сервер: прошивки, прогон и привязка дисков к корзинам

До того как на сервер попадут данные, обновляю BIOS, BMC, прошивку HBA и микрокод дисков до проверенных версий. HBA должен отдавать каждый диск операционной системе напрямую, без виртуальных томов и собственного кэша записи. Каждый диск записываю в ведомость: номер корзины и серийный номер. Это не бюрократия: при аварии в стрессе вынуть исправный диск вместо сбойного — классическая ошибка, после которой RAIDZ2 начинает работать без запаса.

Кабели проверяю так же внимательно, как диски. Если в SMART растёт счётчик ошибок CRC интерфейса, первым делом меняю кабель или слот корзины, а не диск: сам накопитель в этом случае обычно исправен. Новый сервер прогоняю до миграции: несколько проходов теста памяти, длительная нагрузка на процессор, полное чтение поверхности всех дисков, контроль температур и пробное отключение питания через ИБП. Прогон занимает двое-трое суток, и я ни разу не пожалел о потраченном времени.

В UEFI включаю восстановление состояния после подачи питания, но помню, что автозапуск не заменяет корректного выключения по сигналу ИБП. Сетевым интерфейсам — статические адреса, порт BMC — в отдельную сеть управления, веб-интерфейс NAS в интернет не публикуется никогда. Первую проверку ИБП провожу на тестовых данных: наличие USB-кабеля не гарантирует, что конкретная модель корректно работает с драйвером NUT.

• записать серийные номера дисков и номера корзин
• проверить ECC и объём памяти в BMC и в ОС
• убедиться, что ОС видит каждый диск отдельно
• под нагрузкой смотреть температуры CPU, HBA и дисков
• проверить выключение по сигналу ИБП
• сохранить настройки BIOS, BMC и схему сети

Установка TrueNAS и настройка пула ZFS

На 23 сентября 2026 года TrueNAS рекомендует для обычного использования версию 25.10.7 (Goldeye, maintenance от 2 сентября 2026), а TrueNAS 26 находится в статусе бета для ранних пользователей. Для рабочего сервера беру стабильную ветку и не обновляюсь в день выхода релиза. Установщик ставлю на зеркало SSD, после первого входа настраиваю DNS, NTP, часовой пояс, оповещения по почте, двухфакторный вход администратора и сразу выгружаю конфигурацию вместе с секретным seed — без него зашифрованные наборы данных после переустановки не открыть.

Пул tank — один RAIDZ2. На корне пула общие папки не публикую: под каждую политику доступа и хранения создаю отдельный dataset — tank/sdelki, tank/obekty, tank/scans, tank/backups. Для смешанных офисных файлов оставляю recordsize=128K (значение по умолчанию), сжатие LZ4, dedup=off, sync=standard. Для архивов фото и видео пробую recordsize=1M на отдельном dataset. Квоты назначаю наборам данных отделов, а не всему пулу.

После настройки проверяю состояние из системной оболочки — эти команды ничего не меняют и годятся для первичной диагностики:

zpool status -v tank
zpool list tank
zfs list -o name,used,avail,refer,mountpoint -r tank
zfs get compression,dedup,recordsize,sync tank/sdelki
zpool iostat -v tank 5

Нормальное начальное состояние — ONLINE, нули в READ, WRITE и CKSUM, сжатие включено, дедупликация выключена. Результаты первых замеров скорости сохраняю как базовую линию: через полгода по ним видно, стало ли хранилище медленнее на самом деле или жалоба субъективная. Менять параметры стараюсь через веб-интерфейс, а оболочку использую для проверки — так настройки не потеряются при обновлении.

• не добавляйте одиночный диск отдельным vdev — его потеря уничтожит весь пул
• не включайте дедупликацию «на всякий случай»
• не покупайте L2ARC до замеров эффективности ARC
• SLOG нужен только для синхронной записи и только с защитой от потери питания

SMB и права из Active Directory без общего пароля

В Windows-сети TrueNAS присоединяю к домену через раздел Credentials → Directory Services. NAS должен смотреть на доменные DNS, иметь синхронное время с контроллером и присоединяться отдельной учётной записью. Контроллер домена держу на независимом сервере: если он работает на том же железе, авария хранилища оставит компанию без файлов и без входа одновременно. Базовую защиту самого домена я описывал в статье про защиту Active Directory от взлома — NAS в домене наследует все её слабые места.

Datasets создаю с пресетом SMB и NFSv4 ACL, публикую отдельные ресурсы и назначаю права доменным группам вида NAS_Sdelki_RW и NAS_Sdelki_RO, а не отдельным сотрудникам. Состав групп утверждает руководитель отдела, изменения при приёме и увольнении делаются в AD, а не на NAS. Гостевой доступ отключён, SMB разрешён только из пользовательских сетей и VPN, интерфейс администрирования — только из сети управления.

Периодические снимки ZFS TrueNAS показывает Windows-клиентам как «Предыдущие версии» файла. Пользователь сам возвращает случайно перезаписанный документ без обращения к бэкапу, но удалять снимки прав у него нет. Разделяю ACL файловой системы и ACL общего ресурса: первая определяет доступ к данным, вторая — вход через конкретную публикацию. Итоговые права проверяю тестовыми учётными записями «чтение», «изменение» и «запрет».

• отдельный dataset для каждой политики доступа
• группы RO и RW, полный доступ — только администраторам
• не публикуйте один путь по SMB и NFS без мультипротокольного пресета
• проверяйте доступ из каждой сети и из VPN
• записывайте владельца каждой папки

Снимки, реплика и регламент обслуживания

Схема — 3-2-1: рабочие данные, реплика на втором сервере вне офиса и независимая копия. Для активных папок снимки каждые 15 минут с хранением 48 часов, почасовые — 14 дней, ежедневные — 90 дней, ежемесячные — год. Снимки лежат в том же пуле и погибнут вместе с ним, поэтому задача Replication в TrueNAS отправляет их на отдельный сервер по SSH от выделенной учётной записи. Учётные данные основного NAS не должны позволять удалить снимки на реплике — иначе шифровальщик, получивший права администратора, почистит обе стороны.

Простая синхронизация папок в облако резервной копией не является: удаление или шифрование синхронизируется вместе с полезными изменениями. Третьей копией может быть объектное хранилище с версионированием и блокировкой объектов или ротация зашифрованных внешних дисков, которые хранятся отключёнными. Раз в квартал восстанавливаю выбранную папку на изолированный путь и записываю фактическое время — это и есть реальные RPO и RTO, а не то, что написано в договоре. Если на реплику в ЦОД нет бюджета, минимум — два отключаемых диска, которые меняются местами каждую неделю и никогда не подключены одновременно.

Scrub проверяет контрольные суммы всех занятых блоков и при наличии избыточности исправляет повреждённые копии. Для пула на шесть дисков начинаю с ежемесячного scrub. Важная деталь версии 25.10: встроенное расписание SMART-тестов из интерфейса убрали, существующие задания при обновлении переносятся в cron, а оповещения о критичном состоянии дисков остаются. Поэтому короткие тесты раз в неделю и длинные раз в месяц я настраиваю задачами cron, не совмещая их со scrub и репликацией:

smartctl -t short /dev/sda
smartctl -a /dev/sda
zpool scrub tank
zpool status -v tank

• ежедневно: оповещения, свободное место, успешность реплики
• еженедельно: короткие SMART-тесты
• ежемесячно: scrub и длинные SMART-тесты
• ежеквартально: тестовое восстановление и запись фактических RPO/RTO
• после изменений: выгрузка конфигурации TrueNAS

Разбор из практики: агентство недвижимости на 18 рабочих мест

Риэлторская компания «Жилой фонд», 18 рабочих мест. Исходная картина типичная: 5,4 ТБ сканов договоров купли-продажи, фото и видеообзоров объектов лежали на старом настольном компьютере с двумя дисками в зеркале Windows и частично — у агентов на ноутбуках. Права — общая папка «Все» с одним паролем, резервной копии вне офиса не было. Прирост за последний год — около 30 %, в основном фото и видео объектов. С руководителем согласовали RPO 15 минут для папки сделок, 4 часа для архива объектов и RTO 4 часа для основной публикации.

Собрали: Supermicro X13SCL-F, Xeon E-2414, 64 ГБ DDR5 ECC, корпус на восемь отсеков, шесть CMR-дисков по 8 ТБ в RAIDZ2 плюс один холодный запас, два SSD под систему, ИБП с сетевой картой. Сырая ёмкость данных RAIDZ2 — 32 ТБ, около 29 ТиБ до служебных расходов; рабочий потолок я записал в 22 ТиБ. При 5,4 ТБ сегодня и 30 % в год этого хватит больше чем на четыре года, а два свободных отсека оставлены под расширение. Железо в нашей закупке обошлось примерно в 390 тыс. ₽, из них почти половина — диски. TrueNAS 25.10, присоединение к существующему домену на отдельном сервере, пять наборов данных с группами RO/RW.

Реплика уходит каждые 15 минут для сделок и раз в два часа для архива объектов на резервный TrueNAS в арендуемой стойке в ЦОД; первую полную копию залили локально, а сервер отвезли уже с данными — по офисному каналу 100 Мбит/с первая передача заняла бы больше пяти суток. Раз в месяц делается отключаемая зашифрованная копия папки сделок на внешний диск, который хранится у директора. Весь проект занял три недели: неделя поставки, трое суток прогона, миграция на выходных с контрольной сверкой количества и размеров файлов.

Приёмка — по фактам, а не по ощущениям: zpool status без ошибок, реплика укладывается в RPO, сервер корректно выключается по сигналу ИБП, тестовая папка на 40 ГБ восстановлена из реплики за 1 час 50 минут. За первые два месяца агенты трижды сами вернули перезаписанные файлы через «Предыдущие версии», ни разу не позвонив нам. Если вы выбираете между такой сборкой и готовой коробкой, посмотрите ещё NAS для малого бизнеса: что купить — для офиса на 5–8 человек готовый NAS часто разумнее.

• пул: 6 × 8 ТБ CMR в RAIDZ2, рабочий потолок 22 ТиБ
• железо: X13SCL-F, Xeon E-2414, 64 ГБ ECC, около 390 тыс. ₽
• доступ: SMB и доменные группы вместо общего пароля
• защита: снимки каждые 15 минут, реплика в ЦОД, офлайн-копия раз в месяц
• приёмка: восстановление 40 ГБ за 1 ч 50 мин

Частые вопросы