Введение: что решает при выборе дисков для NAS
Короткий ответ для тех, кто выбирает сейчас: берите HDD с CMR-записью и избегайте SMR; смотрите на рабочую нагрузку в ТБ/год, наработку на отказ MTBF и ресурс TBW; SSD-кэш ставьте только под конкретную нагрузку (SLOG под синхронную запись, L2ARC под случайное чтение); ёмкость считайте с запасом 20-30% на рост данных и потери RAID. Такая последовательность решений закрывает большинство ошибок при подборе накопителей для домашних и корпоративных хранилищ.
Цена ошибки высока. SMR-диск в RAIDZ из шести накопителей способен выпасть из массива во время резильвера: скорость записи проваливается до 20-40 МБ/с, задержки растут до секунд, и контроллер помечает диск сбойным раньше, чем перестройка массива завершится. Дешёвый SLOG без защиты от потери питания добавляет риск потерять запись, которую файловая система уже подтвердила приложению. Просчёт в расчёте ёмкости приводит к повторной закупке: массив заполняется на 90%, ZFS начинает фрагментировать данные, производительность падает, а свободного места под снапшоты нет.
Дальше материал идёт по критериям: тип записи HDD, класс накопителя и метрики надёжности, кэширование в ZFS и других файловых системах, расчёт ёмкости с учётом RAID, готовые конфигурации для дома, малого бизнеса и предприятия.
CMR или SMR для NAS: главный критерий выбора HDD
CMR (Conventional Magnetic Recording) пишет дорожки параллельно, без перекрытия: перезапись сектора не затрагивает соседей, а скорость держится ровно по всей поверхности диска. SMR (Shingled Magnetic Recording) укладывает дорожки внахлёст, как черепицу. Плотность записи выше на 10-25%, но записать одну дорожку без перезаписи соседних нельзя. Диск с управлением на стороне устройства (DM-SMR) прячет перестройку за кэшем на 20-25 ГБ: пока буфер не заполнен, скорость держится около 180-200 МБ/с, после заполнения падает в разы.
Для холодного архива, куда данные пишут один раз, SMR приемлем. В RAID и ZFS он создаёт три проблемы. Первая: непредсказуемая задержка. ZFS и mdraid ждут ответа на запись с таймаутом в 30-60 секунд, а SMR в момент перестройки дорожек может молчать дольше. Диск помечается сбойным и уходит из массива. Вторая: скорость резильвера. Перестройка RAIDZ на дисках 8-12 ТБ занимает от 12 часов, с SMR тот же процесс растягивается на дни и недели, и всё это время массив работает без защиты. Третья: длинный хвост задержек в RAIDZ, когда очередь запросов к пулу растёт и страдают все клиенты NFS и SMB, а не только тот, кто пишет.
Показательный случай - линейка WD Red 2019 года. Модели WD20EFAX, WD30EFAX, WD40EFAX и WD60EFAX были SMR, при этом в спецификациях тип записи не указывался. После волны отказов и жалоб производитель вернул CMR в линейки Red Plus и Red Pro, а SMR-модели остались в WD Blue и в архивных сериях. Практический вывод: название линейки с пометкой NAS не гарантирует CMR. Проверять нужно конкретную модель.
Как определить CMR или SMR у конкретной модели
- Спецификация производителя. С 2020 года WD и Seagate указывают тип записи в datasheet и на странице модели (поле Recording Technology). Это самый надёжный источник.
- Имя модели и индекс. У WD Red SMR-версии получили суффикс EFAX, CMR - EFPX и EFRX. У Seagate SMR встречается в Barracuda (например, ST8000DM004) и в архивных сериях, а IronWolf и Exos идут с CMR.
- Утилиты. smartctl -a /dev/sdX покажет зонирование только у host-managed SMR (строка Zoned Device), у DM-SMR тип записи не виден. hdparm -I тоже не даёт ответа. Эти команды полезны для проверки, но отсутствие отметки о SMR ничего не доказывает.
- Практический тест при сомнениях. Запишите на диск 150-200 ГБ последовательных данных и следите за скоростью. Ровные 180-200 МБ/с на всём объёме говорят в пользу CMR, провал до 20-40 МБ/с после первых десятков гигабайт - признак SMR.
Покупая партию, проверяйте одну модель из партии тестом, а не только по наклейке: производители меняют начинку внутри линейки без смены названия.
Корпоративные или потребительские HDD: что выбрать для NAS
Разница между линейками видна по четырём параметрам: допустимая нагрузка в ТБ/год, наработка на отказ MTBF, гарантия и набор функций для работы в массиве. Потребительские диски рассчитаны на работу в одиночной установке, NAS-линейки - на круглосуточную работу в группе, корпоративные - на высокую нагрузку и жёсткие соглашения об уровне сервиса.
| Класс | Примеры линеек | Нагрузка, ТБ/год | MTBF, часов | Гарантия |
|---|---|---|---|---|
| Потребительские | WD Blue, Seagate Barracuda, Toshiba P300 | 55 или не указана | 600 000 | 2 года |
| NAS | WD Red Plus, Seagate IronWolf, Toshiba N300 | 180 | 1 000 000 | 3 года |
| NAS Pro | WD Red Pro, IronWolf Pro, N300 Pro | 300 | 1 000 000 - 1 200 000 | 5 лет |
| Корпоративные | Seagate Exos, WD Gold, Toshiba MG | 550 | 2 500 000 | 5 лет |
Что стоит за таблицей. Диски NAS-линеек получают датчики вибрации (RV sensors), которые гасят резонанс от соседей по корзине. В массиве из восьми и более дисков без них растёт число ошибок позиционирования и падает скорость. Второй пункт - поведение при ошибке чтения: потребительский диск пытается вычитать сектор до 15 секунд, а контроллер RAID за это время успевает счесть накопитель сбойным. Диски для массивов поддерживают TLER/ERC: время восстановления ошибки ограничено примерно 7 секундами, решение о переносе данных принимает RAID. Третий пункт - циклы парковки головок: у NAS-линеек это 300 000 циклов, у корпоративных 600 000, а при нагрузке с частой записью счётчик расходуется быстрее, чем кажется.
Выбор по деньгам простой: домашнее хранилище закрывают WD Red Plus, Seagate IronWolf или Toshiba N300; для бизнеса с нагрузкой выше 180 ТБ/год на диск нужны Red Pro, IronWolf Pro, N300 Pro либо корпоративные Exos, WD Gold и Toshiba MG. Разница в цене между NAS-линейкой и корпоративной моделью держится в пределах 15-30% за терабайт, а по заявленной нагрузке корпоративные отличаются втрое.
Ресурс TBW и наработка на отказ: как интерпретировать
TBW (Total Bytes Written) относится к SSD: это объём записи, после которого производитель не гарантирует работу. Считать просто. Накопитель с TBW 600 ТБ при записи 10 ГБ в сутки исчерпает ресурс примерно через 164 года (600 000 ГБ / 10 ГБ / 365). Ограничение наступит раньше по другой причине: контроллер, прошивка или физический износ. Для накопителей под SLOG смотрите на DWPD, число полных перезаписей ёмкости в сутки: 1 DWPD на SSD 1,92 ТБ за пять лет даёт около 3,5 ПБ записи, и это адекватный уровень для журнала.
MTBF (Mean Time Between Failures) для HDD считают по статистической модели, а не по полевым замерам, поэтому 1 000 000 часов не означают, что диск проработает 114 лет. Полезнее пересчитать MTBF в AFR (Annualized Failure Rate): AFR = 8760 / MTBF. Получается 1,46% в год для потребительского диска с MTBF 600 000 часов, 0,88% для NAS-модели с MTBF 1 000 000 часов и 0,35% для корпоративной с 2 500 000. Практическая польза появляется в масштабе: 100 дисков с AFR 0,88% дают примерно один отказ в год, и это основа для планирования запаса и сроков замены. Публичная статистика крупных хостеров показывает, что отказы чаще приходятся на первые месяцы работы и на последние годы службы, а не распределяются равномерно, поэтому первые 30 дней после установки проверяйте SMART каждую неделю.
Для HDD вместо TBW смотрите рабочую нагрузку (Workload Rating) в ТБ/год. Она суммирует запись и чтение: диск с индексом 180 ТБ/год легко выберет лимит за год, если к обычной нагрузке добавятся два полных резильвера массива.
SSD-кэш, SLOG и L2ARC в ZFS: когда кэширование ускоряет работу
ZFS сначала использует оперативную память: ARC держит в RAM и данные, и метаданные. Практическое правило - не меньше 1 ГБ RAM на 1 ТБ сырой ёмкости пула, для дедупликации требование выше в разы. Пока ARC попадает в нужные блоки, никакой SSD-кэш не нужен: чтение идёт из памяти. Вопрос о кэше возникает после того, как рабочее множество данных перестаёт помещаться в ARC.
Дальше важно разделить два вида кэша. SLOG (Separate Log Device) обслуживает синхронную запись, L2ARC обслуживает чтение. Путаница между ними приводит к покупке ненужного железа: SLOG не ускоряет обычную запись файлов, а L2ARC не помогает транзакциям.
SLOG: когда нужен и как выбрать SSD
Синхронная запись возникает там, где приложение ждёт подтверждения от диска: NFS с sync, iSCSI, коммиты в базах данных, часть операций SMB. ZFS обязан записать блок в ZIL, и без выделенного устройства журнал ложится на те же HDD. Каждый синхронный запрос превращается в два прохода по диску, и задержка вырастает до 5-15 мс. SLOG переносит журнал на SSD и возвращает приложению подтверждение за десятки или сотни микросекунд.
Требования к SLOG простые и жёсткие: низкая задержка, выносливость, защита от потери питания (power loss protection, PLP). Без PLP диск может потерять уже подтверждённую транзакцию при отключении питания, а это прямой путь к повреждению пула. Подходящие модели 2026 года: Samsung PM9A3, Kingston DC1500M, Kioxia CD8. Intel Optane P1600X и P4800X остаются эталоном по задержке, но сняты с производства, и замену ищут в сегменте PLP-NVMe. Ёмкость SLOG не критична: 20-50 ГБ хватает, данные из журнала сбрасываются на HDD постоянно. Ставьте зеркало из двух SLOG-устройств: выход из строя единственного SLOG останавливает синхронную запись до переключения журнала обратно на HDD.
Проверьте нагрузку до покупки: если приложение не делает sync-вызовов, SLOG ничего не изменит. Счётчики zilstat и zpool iostat показывают, есть ли синхронная запись вообще. Плохой SLOG хуже отсутствия SLOG: потребительский NVMe без PLP с задержкой выше, чем у журнала на HDD, замедлит систему и износится за месяцы.
L2ARC: когда имеет смысл и сколько RAM нужно
L2ARC - второй уровень кэша чтения, который живёт на SSD. Он не заменяет RAM, а расширяет её: каждый блок в L2ARC требует заголовка в оперативной памяти. Раньше соотношение было около 1 ГБ RAM на 5-10 ГБ L2ARC; в OpenZFS 2.x накладные расходы на индекс снижены до десятков байт на запись, а кэш переживает перезагрузку. Проверка остаётся простой: если ARC не заполнен, а hit rate низкий, L2ARC только отнимает память.
Типовой случай, где L2ARC работает: пул на 200 ТБ, рабочее множество 5-10 ТБ случайного чтения, RAM 128-256 ГБ. Сценарий, где он бесполезен: потоковое видео и бэкапы, то есть последовательное чтение мимо ARC. Отказа L2ARC не боится: потеря SSD приводит к потере кэша, но не данных, поэтому сюда допустимо ставить потребительские NVMe с высоким TBW.
В других файловых системах кэширование устроено иначе. bcache, dm-cache и кэш LVM ускоряют и чтение, и запись, но режим writeback делает данные зависимыми от исправности кэш-устройства: его отказ означает потерю последних операций. Режим writethrough безопасен, но прирост даёт только на чтении. Для серверов с ZFS это неактуально, а для XFS и ext4 на mdraid такой кэш остаётся рабочим вариантом. Сравнение SSD под нагрузку с цифрами TBW и MTTF разобрано в материале о жизненном цикле данных в серверных системах.
Как рассчитать необходимую ёмкость NAS с учётом RAID и роста данных
Расчёт занимает пять шагов, и каждый отсекает потери, которые обычно забывают.
- Текущий объём. Сложите данные, снапшоты, образы виртуальных машин и локальные резервные копии. Снапшоты в ZFS часто занимают 20-30% пула, и без их учёта расчёт теряет смысл.
- Прогноз роста. Домашние хранилища растут на 10-15% в год, корпоративные на 20-30%. Считайте по формуле сложного процента: объём через N лет = текущий объём × (1 + рост)^N. Для 10 ТБ и 20% в год через три года получается 17,3 ТБ.
- Потери на RAID. Зеркало и RAID 10 отдают 50% ёмкости, RAIDZ1 теряет один диск на чётность, RAIDZ2 два, RAIDZ3 три. Из шести дисков по 8 ТБ в RAIDZ2 остаётся 32 ТБ.
- Накладные расходы файловой системы. ZFS резервирует около 3,1% под slop space, добавляет метаданные, padding и блоки по 128 КБ: для массива с большим числом мелких файлов считайте потери 10-20%. ext4 и XFS держат 5% зарезервированных блоков.
- Запас на свободное место. Оставляйте 20-30% пула свободными. При заполнении выше 80% ZFS работает с фрагментацией, скорость записи проседает, а снапшоты съедают остаток быстрее, чем ожидается.
Итог по примеру: 17,3 ТБ данных через три года, RAIDZ2 из шести дисков по 8 ТБ даёт 32 ТБ после вычета чётности и около 29-30 ТБ доступной ёмкости с учётом накладных расходов ZFS. Запас на рост и снапшоты остаётся, повторная закупка дисков не требуется. Порядок сборки, проверки пула и настройки поведения при отказе описан в практическом руководстве по сборке дискового массива на TrueNAS или OMV.
Отдельно про расширение. В OpenZFS 2.3 и новее поддерживается добавление диска в существующий vdev RAIDZ, но данные по нему не перераспределяются автоматически: место освобождается только по мере перезаписи блоков. Планировать ёмкость проще на этапе закупки, чем растягивать vdev по одному диску. И держите один диск той же модели в запасе: найти идентичную партию через два года сложно, а смешивание разных прошивок внутри vdev добавляет непредсказуемость.
Какой RAID выбрать для NAS: сравнение уровней
| Уровень | Минимум дисков | Потери на чётность | Отказоустойчивость | Когда подходит |
|---|---|---|---|---|
| RAID 1 / зеркало | 2 | 50% | 1 диск | Домашний NAS, важные данные малого объёма |
| RAID 5 / RAIDZ1 | 3 | 1 диск | 1 диск | Массивы из 3-5 дисков до 4 ТБ при наличии внешнего бэкапа |
| RAID 6 / RAIDZ2 | 4 | 2 диска | 2 диска | Рабочий вариант для дисков 8 ТБ и выше |
| RAIDZ3 | 5 | 3 диска | 3 диска | Массивы на 16 ТБ и выше с долгим резильвером |
| RAID 10 | 4 | 50% | 1 диск на пару | Базы данных и ВМ, где важны IOPS и предсказуемая задержка |
Для дисков 8 ТБ и больше RAID 5 и RAIDZ1 стали рискованными. Причина в невосстановимой ошибке чтения (URE): у потребительских дисков она заявлена как одна на 10^14 бит, то есть примерно на 12,5 ТБ прочитанных данных, у корпоративных одна на 10^15 бит, то есть на 125 ТБ. Перестройка RAID 5 из дисков по 12 ТБ прочитывает весь массив, и вероятность наткнуться на URE в этом процессе высокая. Если вторая ошибка случится в другом диске, массив теряется целиком. Выбирайте RAIDZ2 или RAID 6 для дисков от 8 ТБ, RAIDZ3 для массивов на 16 ТБ и выше, где резильвер длится сутками.
RAID не заменяет резервную копию: массив не защищает от удаления файлов, шифровальщиков и ошибок администратора. Правило 3-2-1 (три копии, два типа носителей, одна копия вне площадки) остаётся обязательным, и под него стоит закладывать отдельный бюджет.
Практические сценарии выбора дисков для домашних и корпоративных NAS в 2026 году
Три сценария закрывают большинство задач: домашнее хранилище на 4-24 ТБ, малый бизнес на 10-40 ТБ и корпоративный массив на 50 ТБ и выше. Различаются они не только ёмкостью, но и требованиями к нагрузке, кэшу и числу дисков в vdev.
Домашний NAS: бюджетный и оптимальный варианты
Бюджетный вариант: два диска WD Red Plus или Seagate IronWolf по 4-8 ТБ в зеркале. Полезная ёмкость равна ёмкости одного диска, отказоустойчивость - один накопитель, цена минимальна. Скорость вращения 5400 об/мин здесь предпочтительнее 7200: массив тише, холоднее и потребляет меньше, а пропускной способности 1GbE хватает с запасом.
Оптимальный вариант: четыре диска по 8 ТБ в RAIDZ1 дают около 21-22 ТБ доступной ёмкости и переживают отказ одного накопителя. Если данные нельзя пересоздать, добавьте пятый диск и перейдите на RAIDZ2: полезная ёмкость составит около 21 ТБ, а массив выдержит два отказа подряд. SSD-кэш дома нужен только под виртуалки и iSCSI; для файлового хранилища и медиатеки достаточно 16-32 ГБ RAM под ARC. Конфигурации под сборку своими руками собраны в гайде по сборке минимального NAS, а критерии выбора готового устройства разобраны в статье про выбор NAS для дома и офиса.
Корпоративный NAS: требования к надёжности и производительности
Малый бизнес. Шесть дисков по 8-12 ТБ из линеек WD Red Pro, IronWolf Pro или N300 Pro в RAIDZ2, 64-128 ГБ RAM, SLOG на PLP-NVMe в зеркале, если по сети отдаются iSCSI-тома или NFS для виртуалок. SLOG здесь окупается: задержка синхронной записи падает с 5-15 мс до десятых долей миллисекунды, и виртуальные машины перестают упираться в диск.
Крупное хранилище. Восемь и более дисков Seagate Exos, WD Gold или Toshiba MG на 16-24 ТБ в RAIDZ2 или RAIDZ3, 256 ГБ RAM и больше, L2ARC под случайное чтение при рабочем множестве в единицы терабайт, зеркало SLOG. Массив из восьми дисков по 16 ТБ в RAIDZ2 даёт около 96 ТБ полезной ёмкости после вычета двух дисков на чётность. В 2026 году в этом сегменте появляются диски с HAMR-записью на 30 ТБ и выше: они дают больше ёмкости на отсек, но увеличивают время резильвера, поэтому для них особенно важно сразу закладывать RAIDZ3 и второй узел репликации.
Смешивать в одном vdev диски разных моделей и разной ёмкости не стоит: vdev работает по самому медленному и самому маленькому члену. Для холодных копий и архива удобно использовать облачное хранилище вместо дополнительной полки с дисками: например, Timeweb Cloud даёт объектное хранилище и VDS, куда уходят бэкапы по расписанию, а локальный пул освобождается под рабочие данные. Внешний контур хранения закрывает требование о копии вне площадки из правила 3-2-1, и его стоимость предсказуема.
Сравнение корпоративных вариантов по стоимости владения и отказоустойчивости приведено в материале о выборе системы хранения файлов для компании: там же таблица вопросов поставщику и разбор ошибок, которые ведут к простоям.
Чек-лист выбора дисков для NAS в 2026 году
- Проверьте тип записи в спецификации модели: только CMR. SMR допустим лишь для холодного архива вне RAID.
- Дом: WD Red Plus, Seagate IronWolf, Toshiba N300. Офис с нагрузкой выше 180 ТБ/год на диск: Red Pro, IronWolf Pro, N300 Pro. Дата-центр: Seagate Exos, WD Gold, Toshiba MG.
- Сверьте рабочую нагрузку в ТБ/год, MTBF и гарантию. Пересчитайте MTBF в AFR, если планируете парк от 20 дисков.
- Посчитайте ёмкость по пяти шагам: текущие данные, рост на три года, потери RAID, накладные расходы файловой системы, 20-30% запаса.
- Для дисков от 8 ТБ выбирайте RAIDZ2 или RAID 6, для 16 ТБ и выше - RAIDZ3. RAID 5 оставьте для небольших массивов с внешним бэкапом.
- SLOG ставьте под синхронную запись и только на NVMe с PLP, в зеркале, ёмкостью 20-50 ГБ. L2ARC добавляйте при RAM от 128 ГБ и рабочем множестве, которое не влезает в ARC.
- Проверьте конфигурацию на тестовых данных: залейте 150-200 ГБ, замерьте скорость записи и резильвера, проверьте SMART и восстановление из бэкапа.
Что делать дальше: возьмите спецификации двух-трёх выбранных моделей, сравните рабочую нагрузку и тип записи, посчитайте ёмкость под свой рост данных и только потом оформляйте заказ. Первые 30 дней после сборки проверяйте SMART и температуру раз в неделю: большая часть отказов новых дисков проявляется именно в этот период.