ZFS или mdadm: что выбрать для сервера хранения в 2026 году

Краткий ответ: что выбрать в 2026 году

Для сервера хранения, медиатеки и виртуализации в 2026 году выбирайте ZFS. OpenZFS 2.3 работает на ядрах Linux 6.x, считает контрольные суммы для каждого блока, поддерживает снапшоты, сжатие lz4 и zstd, самовосстанавливает повреждённые данные при наличии избыточности и переносит наборы данных через zfs send. Цена решения - 8-16 ГБ RAM минимум и более тщательное планирование пула на старте.

mdadm 4.5+ остаётся рабочим выбором в трёх случаях: сервер с 4-8 ГБ RAM, где ARC негде разместить; простые файловые серверы и загрузочные разделы, которым нужна предсказуемость; парк, где уже используется Btrfs с контрольными суммами или стоят дистрибутивы без модулей ZFS. Для баз данных с высокой нагрузкой на запись ZFS с SLOG на NVMe выигрывает по надёжности, но требует настройки recordsize и режима sync.

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

NVMe сместил баланс в пользу ZFS. Задержка 100-150 мкс снимает главную боль файловой системы на синхронной записи: SLOG на NVMe закрывает разрыв с mdadm по latency, а на быстрых накопителях ARC нужен меньший объём, потому что часть чтений и так укладывается в микросекунды.

Как устроен ZFS: пулы, vdev и кэширование

ZFS объединяет менеджер томов и файловую систему. Вы не создаёте раздел и не форматируете его в ext4, вы создаёте пул (zpool) и внутри него наборы данных (datasets) со своими свойствами. Пул собирается из vdev: одиночного диска, зеркала или группы RAIDZ1, RAIDZ2, RAIDZ3. Полезная ёмкость и отказоустойчивость считаются на уровне vdev, и отказ любого vdev означает отказ всего пула.

Это ключевое отличие от mdadm, где вы держите несколько независимых массивов и потеря одного не убивает второй. В ZFS избыточность закладывается сразу в каждый vdev.

Каждый блок данных получает контрольную сумму и записывается по принципу copy-on-write: новые данные уходят в свободные блоки, указатель переключается после успешной записи. Отсюда берутся атомарные снапшоты и консистентность после сбоя питания. Фоновая проверка scrub читает все блоки, сверяет контрольные суммы и при несовпадении восстанавливает данные из избыточной копии.

Пример расчёта: пул из 6 дисков по 8 ТБ в RAIDZ2 даёт около 32 ТБ полезной ёмкости и выдерживает отказ двух дисков. Тот же пул из трёх зеркал по 2 диска даёт 24 ТБ, зато случайное чтение размазывается по шести шпинделям. Как выбрать между этими схемами под конкретную нагрузку, разобрано в материале про архитектуру ZFS и распределение данных в пулах vdev.

Долгое время vdev не расширялся по одному диску: увеличить пул можно было только добавлением нового vdev, а вместе с ним росла вероятность отказа. В OpenZFS 2.3 появилось расширение RAIDZ через raidz_expand, но операция переписывает существующие данные, идёт часами или сутками и не меняет уровень избыточности. Планировать ёмкость на три года вперёд по-прежнему дешевле, чем расширяться на боевом сервере.

Пул и vdev: как не потерять данные при проектировании

Не смешивайте в одном пуле vdev разных типов без расчёта. Комбинация зеркал и RAIDZ работает, но теряет предсказуемость: скорость пула задаёт самый медленный vdev, а полезная ёмкость считается по самой затратной схеме избыточности.

RAIDZ1 на дисках больше 2 ТБ в 2026 году не ставьте. Классическая ошибка выглядит так: пул из одного vdev RAIDZ1 на 8 дисках по 4 ТБ, то есть массив, которому для восстановления нужно прочитать около 28 ТБ данных. При отказе одного диска rebuild длится 12-24 часа, и всё это время пул живёт без запаса. Второй отказ за окно восстановления означает полную потерю пула вместе со снапшотами.

Для медиахранилища берите RAIDZ2, для баз данных - зеркала (RAID 10). Зеркала восстанавливаются копированием одного диска без расчёта чётности и дают в разы больше IOPS на случайном чтении.

Задавайте ashift=12 при создании пула на дисках 512e и 4Kn. Неверное выравнивание снижает скорость записи и увеличивает износ, а поменять ashift после создания vdev нельзя.

ARC, L2ARC и SLOG: когда они реально нужны

ARC - адаптивный кэш чтения в оперативной памяти. По умолчанию OpenZFS отдаёт ему до 50% RAM, граница задаётся параметром zfs_arc_max. Для HDD-пула практический минимум - 16 ГБ, для виртуализации и баз данных - 32-64 ГБ.

Правило «1 ГБ RAM на 1 ТБ пула» устарело как норматив, но остаётся разумным ориентиром для консервативного планирования. Отдельная история - дедупликация: таблица DDT требует примерно 5 ГБ RAM на 1 ТБ данных, а её отсутствие приводит к свопу и падению производительности в разы. Включайте dedup только там, где доля одинаковых блоков доказана замером.

L2ARC - второй уровень кэша чтения на SSD или NVMe. Он помогает, когда одни и те же данные читаются чаще объёма RAM, и не ускоряет запись вообще. Кэш расходует часть ARC на заголовки блоков, поэтому при малом объёме памяти выигрыш может уйти в минус. Начиная с OpenZFS 2.0 в L2ARC по умолчанию пишутся и данные, и метаданные, но для медиасервера часто разумнее оставить только метаданные: zfs set secondarycache=metadata tank.

SLOG - отдельное устройство под ZIL, то есть под лог синхронной записи. Он нужен только тогда, когда приложение пишет синхронно: NFS, iSCSI, zvol виртуальных машин, базы данных с sync=always. Асинхронную запись SLOG не ускоряет. Ставьте его на NVMe с низкой задержкой и ресурсом больше 3 DWPD, а Intel Optane подходит сюда лучше всего. Практический эффект: база с 10 тыс. синхронных IOPS снижает задержку примерно с 10 мс до 0,5 мс. SLOG почти всегда зеркалируют, потому что потеря устройства без копии означает потерю ещё не зафиксированных транзакций.

mdadm: классический программный RAID в Linux

mdadm управляет программными RAID-массивами на уровне ядра Linux. Поддерживаются уровни 0, 1, 4, 5, 6, 10, а также linear и multipath. В версии 4.5 стабильны write-intent bitmap (журнал для RAID 5/6, заметно ускоряющий rebuild), замена диска на ходу и изменение геометрии массива.

Файловой системой mdadm не управляет: вы собираете массив и ставите сверху ext4, XFS или Btrfs. Это даёт гибкость и полностью снимает вопрос совместимости с GRUB. Платой идут отсутствие контрольных сумм, снапшотов, сжатия и дедупликации. Требования к ресурсам при этом минимальны: 1-2 ГБ RAM, а CPU загружается только расчётом чётности в RAID 5/6.

Пример: массив RAID 10 из четырёх NVMe через mdadm выдаёт задержку около 0,1 мс, но bit rot вы не заметите, пока не прочитаете повреждённый файл. RAID здесь защищает от отказа железа, а не от порчи содержимого.

mdadm хорошо сочетается с LVM: логические тома, тонкое выделение места и снапшоты на уровне тома. Разницу в потреблении памяти и схемах управления томами разбирает сравнение LVM и ZFS для малого сервера хранения.

Когда mdadm выигрывает у ZFS

• RAM меньше 8 ГБ. ZFS с ARC 4 ГБ будет хронически голодать по памяти, тогда как mdadm + ext4 работает стабильно.
• Загрузочные разделы и минималистичные образы, где ремонт массива из GRUB предсказуем, а настройка корня на ZFS требует дополнительного загрузчика.
• Системы на Btrfs. Целостность и снапшоты там уже есть, и ZFS становится избыточной надстройкой.
• Старые ядра, встраиваемые системы и дистрибутивы, где модули ZFS не поставляются и не собираются.

Практический пример: сервер 1U с 8 ГБ RAM и четырьмя дисками по 2 ТБ. mdadm RAID 10 плюс ext4 даст ровную производительность на 2 ТБ кэша ядра. ZFS на этой машине упрётся в ARC, а включение L2ARC только усугубит ситуацию: часть памяти уйдёт под заголовки блоков.

Сравнение по ключевым критериям

Надёжность и защита от потери данных

ZFS считает контрольные суммы для всех блоков данных и метаданных. При сверке scrub несовпадение означает порчу, и файловая система сама достаёт верную копию из зеркала или RAIDZ. Так закрывается bit rot, silent data corruption и ошибки HBA.

mdadm контрольные суммы не считает. Если сектор на диске тихо изменился, RAID-10 отдаст данные из первой доступной копии и о проблеме не сообщит. Частично это лечится Btrfs поверх mdadm: файловая система с контрольными суммами и самовосстановлением есть, но избыточность на уровне RAID о ней не знает и служебные структуры не защищает.

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

Производительность: IOPS, пропускная способность, задержки

На последовательных операциях ZFS RAIDZ2 и mdadm RAID 6 идут наравне, потому что обе схемы ограничены шпинделями: 6 HDD 7200 rpm дают примерно 500 МБ/с в ZFS и 550 МБ/с в mdadm.

На случайном чтении разрыв больше. RAIDZ2 обслуживает мелкие случайные чтения фактически на IOPS одного диска, это плата за переменный размер полосы. Зеркала и ARC меняют картину: при ARC 32 ГБ ZFS выдаёт порядка 50 тыс. IOPS на 4K-чтении там, где HDD-массив через mdadm показывает около 5 тыс. IOPS.

На синхронной записи ZFS с SLOG на NVMe укладывается в 0,5 мс, mdadm RAID 10 на NVMe - в 0,1 мс, но без защиты от bit rot. Сжатие lz4 частично компенсирует накладные расходы: на текстовых и лог-данных пропускная способность растёт на 20-40%. Проверенные замеры на SSD, NVMe и HDD с готовыми командами fio собраны в отдельном материале о производительности дисковых подсистем.

Потребление оперативной памяти и требования к CPU

ZFS: ARC по умолчанию забирает до 50% RAM, минимум для стабильной работы 8 ГБ, комфортный старт 16 ГБ. Дедупликация добавляет около 5 ГБ на 1 ТБ. Контрольные суммы (fletcher4, sha256) и сжатие (lz4, zstd) съедают 5-15% CPU, современные многоядерные процессоры это почти не замечают.

mdadm: достаточно 1-2 ГБ RAM, CPU нагружается расчётом чётности в RAID 5/6. Пример на сервере с 32 ГБ RAM и восемью дисками по 4 ТБ: ZFS отдаёт под ARC 16 ГБ, mdadm оставляет свободными около 30 ГБ. На NVMe-пулах потребность в больших ARC ниже, потому что промах кэша стоит не миллисекунды, а микросекунды.

Удобство администрирования и мониторинг

ZFS: единый набор команд, zpool create, zfs create, zfs snapshot, zpool status, zpool iostat, zfs list, zpool scrub, zpool replace. Снапшоты и клоны встроены, репликация делается через zfs send. Мониторинг закрывают zpool status, smartctl и экспортёры метрик для Prometheus.

mdadm: команды mdadm --create и mdadm --detail, состояние в /proc/mdstat, автоматическая сборка через mdadm.conf и mdmonitor. Файловую систему, LVM и монтирование вы настраиваете отдельно, снапшотов на уровне массива нет. Графический интерфейс дают TrueNAS и Proxmox, но только поверх ZFS.

Типичные ошибки при выборе RAID и дисков

Шесть ошибок встречаются в разборах инцидентов чаще всего: RAID 5 и RAIDZ1 на дисках больше 2 ТБ; SMR-диски в массиве; desktop-накопители без TLER; смешивание моделей и размеров внутри одного vdev; отсутствие мониторинга SMART и регулярного scrub; включённая дедупликация без запаса памяти.

RAID 5 и RAIDZ1 в 2026: почему это опасно

Чем больше диск, тем дольше rebuild. Для 8 ТБ это 24-48 часов чтения всех дисков массива. Публичная статистика крупных дисковых парков (Backblaze публикует её с 2013 года) даёт годовой AFR около 1-2% для HDD, то есть на массиве из 8 дисков один отказ в год - ожидаемое событие, а не редкость.

Второй фактор - невосстановимая ошибка чтения. У потребительских SATA-дисков её заявленный уровень 1 на 10^14 бит, то есть примерно один нечитаемый сектор на 12,5 ТБ прочитанных данных. Полное восстановление RAIDZ1 из четырёх дисков по 8 ТБ прокачивает около 24 ТБ, и вероятность попасть в такой сектор превышает 50%. Поэтому для HDD ёмкостью больше 2 ТБ берите RAIDZ2 или RAID 10: пул RAIDZ2 из 6 дисков по 8 ТБ даёт около 32 ТБ полезной ёмкости и переживает два отказа.

SMR, CMR и TLER: какие диски подходят для сервера

SMR-диски пишут черепицей и переписывают соседние дорожки при случайной записи. В массиве это оборачивается провалами производительности после заполнения половины ёмкости и rebuild длиной в недели, потому что накопитель уходит в длительную перестройку зон. Для RAID годятся только CMR-модели: WD Red Plus и Red Pro, Seagate IronWolf и IronWolf Pro, Toshiba N300.

TLER (Time-Limited Error Recovery) ограничивает время, которое диск тратит на исправление ошибки чтения. Desktop-диск без этой функции может думать минутами, контроллер за это время успевает признать его отказавшим и выкинуть из массива. Пример из практики: партия WD Red на SMR-платформе в RAIDZ1 давала таймауты и выпадения дисков до 40 секунд на случайной записи, тогда как Red Plus на CMR работала без замечаний.

Не смешивайте модели и объёмы внутри одного vdev. Пул выравнивается по самому слабому диску, а полезная ёмкость RAIDZ считается по минимальному размеру: диск на 12 ТБ рядом с тремя на 8 ТБ отдаст только 8 ТБ.

Практические рекомендации для конкретных сценариев

Медиахранилище: ZFS RAIDZ2 с L2ARC

Конфигурация: 8 дисков по 12 ТБ CMR в RAIDZ2, это около 72 ТБ полезной ёмкости, 64 ГБ RAM, L2ARC на NVMe 1 ТБ под метаданные и часто читаемые файлы, ARC 32 ГБ. Сжатие lz4, atime выключен, дедупликация не нужна. Такой пул спокойно отдаёт несколько потоков 4K-стриминга и не деградирует на сканировании библиотеки.

zpool create -o ashift=12 tank raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi
zfs set compression=lz4 tank
zfs set atime=off tank/media
zfs set secondarycache=metadata tank

Альтернатива на mdadm: RAID 6 плюс XFS. Она дешевле по памяти, но не защищает от bit rot и не даёт снапшотов, поэтому бэкап придётся строить отдельно. Пошаговый разбор развёртывания пулов, ashift, снапшотов и iSCSI есть в руководстве по СХД на базе TrueNAS и ZFS.

База данных: ZFS RAID 10 + SLOG

Конфигурация: 4 NVMe по 2 ТБ в два зеркала, SLOG на устройстве с ресурсом больше 3 DWPD (Optane 900P, P4800X или серверный NVMe), ARC 32 ГБ, recordsize=16K для PostgreSQL, sync=always, logbias=latency. Снапшоты перед миграциями схемы делаются одной командой и занимают секунды.

zpool create tank mirror nvme0n1 nvme1n1 mirror nvme2n1 nvme3n1 log mirror nvme4n1 nvme5n1
zfs set recordsize=16K tank/db
zfs set sync=always tank/db
zfs set compression=lz4 tank/db

На 10 тыс. транзакций в секунду связка ZFS с SLOG держит задержку около 0,5 мс, mdadm RAID 10 на NVMe - около 0,1 мс. Разница заметна только на очень горячих OLTP-нагрузках, зато ZFS дополнительно ловит порчу блоков, а mdadm этого не делает. Если задержка критична, оставьте mdadm, но добавьте реплику и проверку контрольных сумм на уровне приложения.

Виртуализация: ZFS RAID 10 + L2ARC

Конфигурация: 8 SSD или NVMe в четыре зеркала, L2ARC на NVMe 2 ТБ, SLOG в зеркале под синхронные записи гостей, ARC 64 ГБ, сжатие lz4. Диски виртуальных машин создаются как zvol с volblocksize=16K, снапшоты делаются перед каждым обновлением гостевой системы, а клоны позволяют поднять тестовую копию продакшен-ВМ за минуты.

zfs set compression=lz4 tank/vms
zfs set sync=standard tank/vms
zfs snapshot tank/vms@before-update
zfs clone tank/vms@before-update tank/vms-test

Пример: 20 виртуальных машин по 4 ГБ RAM на пуле RAID 10 из NVMe дают около 100 тыс. IOPS при среднем размере блока 16K. Вариант на mdadm требует RAID 10 плюс LVM плюс ext4: производительность будет не хуже, а вот снапшоты и клоны придётся собирать вручную, и целостность внутри гостя никто не проверит.

Итог: алгоритм выбора за 5 минут

1. RAM меньше 8 ГБ, старые ядра, Btrfs или встроенная система: mdadm.
2. Данные критичны, нужна защита от bit rot, снапшоты и репликация: ZFS.
3. Медиахранилище: ZFS RAIDZ2 из CMR-дисков, L2ARC под метаданные, SLOG не нужен.
4. База данных: ZFS RAID 10 на NVMe с зеркалированным SLOG и recordsize под свой движок. Если нужна минимальная задержка без защиты от порчи блоков - mdadm RAID 10.
5. Виртуализация: ZFS RAID 10 на SSD или NVMe, L2ARC, SLOG, ARC 64 ГБ и выше.
6. Никогда не берите RAID 5, RAIDZ1 и SMR-диски на ёмкостях больше 2 ТБ.

Перед боевым запуском проверьте конфигурацию на стенде: соберите пул, прогоните fio под своим профилем нагрузки, отработайте сценарий замены диска и восстановления из снапшота. Если свободного железа нет, тестовый стенд быстрее поднять на облачном сервере нужной конфигурации, например во Timeweb Cloud, и уже после замеров закупать диски и RAM под боевую систему. Сверьте свой план с чек-листом по уровням избыточности и типам дисков из полного гида по RAID-массивам, и только затем переносите данные в продакшен.