Короткий ответ: для сервера на NVMe с современным Linux выбирайте программный RAID, mdadm или ZFS. Аппаратный контроллер оправдан в трех случаях: массив из десятков SATA/SAS-дисков, транзакционная база данных с интенсивной синхронной записью, платформа, где ОС не умеет нужный уровень программного RAID.
Решение определяют три вводных: тип дисков, профиль нагрузки и требование к переносимости массива. Дальше разбор этих критериев с цифрами, сценариями и ошибками, которые чаще всего приводят к потере данных.
Ключевые отличия аппаратного и программного RAID
Аппаратный RAID переносит вычисления на выделенный chip, программный считает четность силами CPU и хранит метаданные в дисках или в ОС. Отсюда следуют все остальные различия: цена, переносимость, потолок производительности и точки отказа.
Как работает аппаратный RAID-контроллер
Плата контроллера содержит собственный процессор (ROC), буферную DRAM-память объемом от 512 МБ до 4 ГБ, прошивку и модуль защиты кэша: батарею (BBU) или суперконденсатор с флеш-памятью. ROC считает четность, управляет дисками, следит за состоянием каждого накопителя и отдает ОС один виртуальный диск.
Система видит логический том как обычный блочный девайс и не знает, из скольких дисков он собран. Обратная сторона: нужны драйверы (megaraid_sas, mpt3sas) и вендорские утилиты вроде storcli, perccli или arcconf для мониторинга и ремонта. Типичные представители: Broadcom MegaRAID 9361-8i и 9560-16i, Dell PERC H740P и H755, решения HPE Smart Array. Tri-mode-контроллеры работают с SAS, SATA и NVMe одновременно.
Ключевая функция аппаратного кэша: write-back с защитой батареей. Запись подтверждается ОС сразу после попадания в DRAM, а на диски уходит позже. Именно это снижает задержку fsync, пока батарея исправна. При разряженной или отсутствующей BBU прошивка переключает режим на write-through, и преимущество в скорости записи исчезает.
Как работает программный RAID (mdadm, ZFS, Storage Spaces)
mdadm управляет драйвером md в Linux и собирает уровни RAID 0, 1, 5, 6, 10, 1E прямо в ядре. Метаданные версии 1.2 хранятся в начале или конце диска, поэтому массив переносится между серверами одной командой. Четность считается на CPU с векторными инструкциями AVX-512, современный Xeon или EPYC выдает десятки гигабайт в секунду на четность, чего хватает для десятков HDD и любых NVMe.
ZFS объединяет файловую систему и менеджер томов: пулы, vdev, уровни RAIDZ1/2/3, контрольные суммы каждого блока, самовосстановление, снапшоты, сжатие, scrub. Ошибку на диске ZFS видит и исправляет по копии, а не просто фиксирует. Плата за это - оперативная память: планируйте около 1 ГБ ОЗУ на 1 ТБ дискового пространства, минимум 8 ГБ для домашнего хранилища. Storage Spaces в Windows Server работает по схожей логике: пул дисков, виртуальный диск, режимы mirror и parity, целостность ReFS.
Готовые команды для сборки обоих вариантов и чек-лист действий при отказе диска собраны в материале про RAID-массивы 2026: полный гид по выбору и настройке.
Производительность: что быстрее в 2026 году
Спор решился не в пользу контроллеров. На NVMe-массивах программный RAID стабильно быстрее, потому что диски подключены к линиям PCIe напрямую и не проходят через SAS-бэкенд платы.
| Критерий | Аппаратный RAID | Программный RAID |
|---|---|---|
| Последовательная скорость | Ограничена шиной SAS и ROC, обычно 6-14 ГБ/с на контроллер | Ограничена линиями PCIe и CPU, десятки ГБ/с на массиве NVMe |
| Случайная запись на HDD | Кэш с BBU сглаживает пики, fsync около 0,2-0,5 мс | Без SLOG fsync упирается во вращение шпинделя, 5-10 мс |
| Нагрузка на CPU | Почти нулевая, четность считает ROC | Несколько процентов ядра на RAIDZ2 из NVMe, больше на HDD-массивах |
| Гибкость | Зависит от прошивки и вендора | Снапшоты, кэши, дедупликация, любой уровень в командной строке |
Сценарии с высокой нагрузкой на запись
Синхронная запись остается территорией аппаратного кэша. PostgreSQL или MS SQL с fsync на аппаратном RAID 10 из SAS-дисков дает стабильные 0,2-0,5 мс на коммит, тогда как mdadm на тех же HDD без кэша ждет физической записи и получает 5-10 мс. Пропускная способность транзакций различается в разы.
ZFS закрывает разрыв отдельным устройством лога. SLOG на NVMe с защитой от потери питания возвращает задержку синхронной записи к уровню аппаратного контроллера. Условие: диск лога должен быть быстрым и надежным, обычный потребительский NVMe без конденсаторов тут не подходит. Для асинхронных нагрузок, файловых хранилищ, потоковой записи логов и бэкапов разницы между подходами почти нет, обе схемы упираются в диски.
Массивы под СУБД и виртуализацию требуют отдельного расчета по уровню избыточности и размеру страйпа, разбор с рекомендациями по latency есть в руководстве про выбор и настройку RAID для серверов СУБД и виртуализации.
Влияние NVMe и PCIe 5.0 на выбор
NVMe-накопители подключаются к линиям PCIe процессора и не требуют контроллера. Программный RAID собирает их в RAID 10 или зеркала ZFS и выдает миллионы IOPS, единственное ограничение - число линий: массив из 24 NVMe по x4 занимает 96 линий, что близко к пределу одного сокета EPYC. Аппаратные tri-mode-контроллеры для NVMe существуют, стоят от 2000 долларов и добавляют к каждой операции десятки микросекунд на проход через ROC. Выигрыш они дают только в одном: горячая замена и единая точка управления дисками для ОС, которая иначе не умеет видеть больше одного накопителя.
Стоимость владения: аппаратный vs программный RAID
Программный RAID бесплатен на уровне лицензий, аппаратный стоит денег на старте и продолжает стоить в эксплуатации: батареи, прошивки, резервные платы.
Прямые затраты на оборудование и лицензии
Ориентировочные цены 2026 года: MegaRAID 9361-8i - около 500 долларов, комплект BBU к нему - 150-250 долларов, 9560-16i - 900-1400 долларов, tri-mode с NVMe - от 2000 долларов. Добавьте кабели, backplane, экспандеры для полок и резервный контроллер той же модели, без которого любой ремонт превращается в поиск редкого железа. Часть вендоров по-прежнему продает расширенные функции отдельными ключами: кэширование SSD, некоторые уровни RAID, шифрование.
Программный вариант не требует плат: mdadm и OpenZFS входят в состав дистрибутива, Storage Spaces доступен в редакции Windows Server. Реальные затраты уходят в ресурсы: около 1 ГБ ОЗУ на 1 ТБ под ARC в ZFS, один-два быстрых NVMe под SLOG и L2ARC, плюс запас производительности CPU. На сервере с 256 ГБ памяти и 64 ядрами это незаметно, на бюджетной платформе с 32 ГБ уже требует расчета.
Если сервер размещен в облаке, уровень RAID скрыт от вас целиком: провайдер отвечает за избыточность накопителей и за замену вышедших из строя. Такой вариант рассматривают, когда собственная СХД не нужна, а нужны предсказуемые ресурсы и быстрый запуск, пример - облачная инфраструктура Timeweb Cloud с серверами, хранилищем и Kubernetes.
Косвенные расходы: энергопотребление и обслуживание
Контроллер потребляет 10-25 Вт и греется, ему нужен обдув в корпусе. Программный RAID поднимает загрузку CPU на несколько процентов, что дает сопоставимые 5-15 Вт в пике. По совокупному энергопотреблению варианты близки, разница редко превышает 20 Вт на сервер.
Обслуживание различается по характеру. Аппаратный контроллер требует обновления прошивки, замены батареи каждые 3-5 лет и контроля состояния кэша по storcli. Программный требует обновления ОС, регулярного scrub в ZFS и мониторинга SMART через smartd. Главный финансовый риск аппаратной схемы - простой: при отказе платы без холодного резерва сервер стоит, пока не найдется совместимая модель с подходящей версией прошивки.
Переносимость массивов и риски при отказе контроллера
Здесь у программного RAID преимущество, которое сложно переоценить деньгами: массив привязан к дискам, а не к плате.
Как перенести аппаратный RAID на другой сервер
Порядок действий такой: пометить диски по слотам, снять дамп конфигурации, установить контроллер той же или совместимой модели, импортировать иностранную конфигурацию (в storcli это операция foreign import). Совместимость не гарантирована: переход с PERC H730 на H740 обычно проходит, но иногда требует обновления прошивки и ручной правки конфигурации, а контроллер другого вендора массив просто не увидит. Если включено шифрование с локальным ключом, ключ может храниться на плате, и после ее смерти данные останутся нечитаемыми.
Преимущества программного RAID при миграции
В Linux достаточно подключить диски и выполнить сборку: mdadm --assemble --scan для программного массива, zpool import для пула ZFS. ZFS переносит пул между серверами за минуты, включая снапшоты и настройки наборов данных, при условии совместимости версий ПО. Одно предупреждение: после zpool upgrade пул нельзя импортировать на сервер с более старой версией OpenZFS, поэтому обновляйте флаги осознанно и одинаково по всей инфраструктуре. Storage Spaces переносится между серверами с совместимой версией Windows Server, пул подключается целиком без пересборки.
Когда аппаратный RAID оправдан: практические сценарии
Список короткий, но в нем сценарии, где программный RAID проигрывает по задержке или по масштабу.
Высоконагруженные СУБД и OLTP
Кэш с BBU сокращает время коммита и делает нагрузку предсказуемой. PostgreSQL с fsync, MS SQL с журналом транзакций, Oracle на SAS-дисках показывают более ровные графики задержки на аппаратном RAID 10, чем на программном массиве без SLOG. Если база уже живет на NVMe, преимущество исчезает: программный RAID 10 из NVMe дает меньшую задержку и большую пропускную способность при меньшей цене, а ZFS с SLOG закрывает вопрос синхронной записи.
Серверы с большим количеством SATA/SAS дисков
Контроллер с экспандерами обслуживает до 240 дисков в одном массиве, снимает с CPU четность и держит единую точку мониторинга. Массив из 24-60 HDD SATA под файловое хранилище или бэкап на аппаратный RAID 6 собирается быстрее и работает стабильнее, чем тот же набор в mdadm, особенно если процессор слабый. Еще один случай: ОС или загрузчик не поддерживают нужный уровень программного RAID, а собрать массив нужно на этапе установки.
Когда программный RAID выигрывает: практические сценарии
Большинство задач 2026 года попадает сюда: NVMe, гиперконвергентные кластеры, домашние и офисные хранилища.
Домашние и офисные NAS на TrueNAS/ZFS
Сборка на 4-8 HDD с уровнем RAIDZ2 дает контроль целостности, снапшоты, сжатие и перенос пула на другое железо без покупки контроллера. Для домашнего сервера экономия составляет сотни долларов, а восстановление после смерти материнской платы сводится к переносу дисков. Уровни избыточности для таких сборок и команды обслуживания разобраны в статье про RAID в системах хранения данных: уровни, настройка и рекомендации.
Гиперконвергентные инфраструктуры и Ceph
vSAN, Ceph, Longhorn и другие SDS требуют прямого доступа к дискам: контроллер переводится в режим HBA или JBOD, избыточность формируется на уровне кластера, а не отдельного сервера. Аппаратный RAID в такой схеме не только бесполезен, но и вреден, потому что скрывает отказ диска от распределенной системы. Расширение таких массивов без простоя описано в материале про масштабирование системы хранения без простоя.
Типичные ошибки при выборе и настройке RAID
Большинство аварий приходит не от технологии, а от конфигурации и отсутствия бэкапов.
Ошибки, приводящие к потере данных
- RAID не заменяет резервное копирование. Массив защищает от смерти диска, но не от ошибки администратора, шифровальщика или сбоя прошивки.
- RAID 5 на дисках 16-20 ТБ. Ребилд занимает сутки и больше, а при типичной частоте неисправимых ошибок 10 в 14-й степени второй сбой во время восстановления становится реальным сценарием. Для больших дисков берите RAID 6 или RAIDZ2.
- Аппаратный RAID без BBU или с разряженной батареей. Кэш переходит в write-through, а при отключении питания возможна потеря подтвержденных операций.
- Несовместимые диски: разные модели, размеры, прошивки и особенно SMR-накопители в массивах с четностью. SMR-диск в ZFS или mdadm дает провалы по задержке и выпадает из массива.
- Шифрование массива с ключом на контроллере без резервной копии ключа.
- Обновление прошивки контроллера или zpool upgrade без свежего бэкапа.
Ошибки конфигурации производительности
Неверный размер страйпа снижает скорость на конкретной нагрузке: для баз данных разумны 64-256 КБ, для файловых хранилищ и потоковой записи - 1 МБ. В ZFS вместо страйпа настраивается recordsize: 8-16 КБ для баз данных, 128 КБ по умолчанию, 1 МБ для медиатеки. Обязательная проверка - ashift, для дисков с сектором 4 КБ нужен ashift=12, иначе каждый блок читается с кратным увеличением трафика.
Ошибки, которые видны не сразу: отсутствие горячего резерва, отключенный мониторинг SMART, игнорирование еженедельного scrub, ручное вмешательство в массив без снятия дампа метаданных. Проверяйте состояние массива после каждого изменения, а не раз в квартал.
Итоговые критерии выбора под вашу инфраструктуру
Чек-лист, по которому решение принимается за пять минут:
- Диски NVMe или PCIe 5.0: программный RAID, аппаратный только при требовании вендорской поддержки.
- 12 и более SATA/SAS HDD, слабый CPU, нагрузка с синхронной записью: аппаратный контроллер с BBU и холодным резервом.
- Нужна независимость от вендора и быстрый перенос массива: программный RAID, mdadm или ZFS.
- Гиперконвергентная инфраструктура, Ceph, vSAN: контроллер в режиме HBA, избыточность на уровне кластера.
- Устаревшая ОС без поддержки программного RAID: аппаратный контроллер.
- Ограниченный бюджет при мощном CPU: программный RAID, деньги лучше вложить в ОЗУ и NVMe под SLOG.
Для большинства современных серверов выигрывает программный RAID: он дешевле, быстрее на NVMe, проще переносится и не создает зависимости от одной платы. Аппаратный контроллер оставьте там, где он реально нужен: десятки HDD, жесткие требования к задержке синхронной записи и устаревшие платформы. Общее правило не зависит от выбора: без резервных копий и мониторинга любой массив рано или поздно теряет данные.