RAID в Proxmox: настройка отказоустойчивого хранилища данных

У вас Proxmox, десяток виртуальных машин, и всё крутится на одном массиве дисков. Пока всё работает - жизнь прекрасна. Но диски штука смертная, причём умирают они без предупреждения и, как назло, в неподходящий момент. Вопрос не в том, откажет ли диск, а когда. И ответ на этот вопрос определяет, будете ли вы спокойно менять накопитель по hot-swap или судорожно восстанавливать данные из бэкапов (если они есть).

Proxmox VE предлагает три пути к отказоустойчивому серверу: ZFS - встроенный и рекомендованный разработчиками, mdadm - проверенный Linux software RAID, и аппаратный RAID - когда нужна сырая производительность с железным контроллером. Каждый из них решает задачу по-своему, и выбор зависит не от маркетинговых обещаний, а от конкретной нагрузки. Где-то побеждает ZFS с его снапшотами и интеграцией в кластер, где-то - контроллер с батарейным кэшем, который перемалывает random write в разы быстрее. Разберёмся, кому что подходит.

Версии на момент обновления: Proxmox VE 9.2 от 21 мая 2026, в составе - ZFS 2.4 и ядро Linux 7.0. Всё описанное ниже работает и на ветке 8.x, кроме RAIDZ-экспансии: она требует ZFS 2.3 и новее.

ZFS, mdadm, аппаратный RAID: кто есть кто

Proxmox VE рекомендует ZFS вместо аппаратного RAID для полной интеграции с гипервизором. Логика простая: ZFS даёт снапшоты, компрессию, дедупликацию и контроль целостности данных на уровне файловой системы - без внешних утилит и дополнительных слоёв абстракции. Но рекомендация не приговор. Есть сценарии, где mdadm или аппаратный контроллер работают лучше.

Аппаратный RAID с батарейным кэшем (BBU) заметно выигрывает у ZFS на случайной записи, особенно под базами данных на обычных HDD. Разрыв измеряется разами и сильно зависит от глубины очереди, размера блока и того, включён ли на контроллере режим write-back. Механизм простой: контроллер собирает случайные записи в энергонезависимом кэше и сбрасывает их на диски последовательно. ZFS так не умеет - каждая транзакционная группа пишется атомарно. На SSD-пулах разрыв съёживается, а с SLOG на отдельном устройстве под синхронную запись почти исчезает.

Но у медали две стороны. ZFS видит каждый диск напрямую и контролирует целостность на уровне блоков. Аппаратный контроллер - это «чёрный ящик», и если он выходит из строя, вам нужен точно такой же (или совместимый) для восстановления массива. Потерял контроллер - потерял данные, даже если диски целы. Кроме того, ZFS поверх аппаратного RAID - спорная конфигурация: контроллер скрывает физические диски, и ZFS не может отслеживать ошибки на отдельных накопителях, теряя одно из главных преимуществ - end-to-end checksumming. Если уж используете аппаратный RAID - ставьте поверх него ext4 или xfs, а не ZFS.

Про сами уровни RAID и их арифметику - в отдельном разборе, что такое RAID и какие уровни бывают. Ниже - только то, что касается ZFS-варианта этих уровней.

RAIDZ1, RAIDZ2, RAIDZ3 и зеркала: сколько дисков и сколько отказов

RAIDZ - это ZFS-аналог RAID с распределённым паритетом, где цифра означает количество дисков избыточности. RAIDZ1 переживает отказ одного диска, RAIDZ2 - двух, RAIDZ3 - трёх. Отличие от классического RAID5/6 в том, что RAIDZ пишет полосу переменной длины и не страдает от «дыры записи» (write hole): каждая транзакция либо записана целиком, либо не записана вовсе.

Общая рекомендация OpenZFS - держать в одном vdev от 3 до 9 дисков. Под случайные операции берут группы поуже: 3 диска в RAIDZ1, 6 в RAIDZ2, 9 в RAIDZ3. Шире - выгоднее по ёмкости, уже - быстрее по IOPS.

Главное, что стоит понять про производительность: один vdev RAIDZ даёт примерно IOPS одного диска, сколько бы дисков в него ни входило. Причина в том, что каждая запись затрагивает всю группу, и группа не может обслуживать две операции параллельно. Восемь дисков в одном RAIDZ2 по случайной записи ведут себя как один диск. Восемь дисков в четырёх зеркалах - как четыре. Отсюда и правило: под виртуальные машины и базы берут зеркала, под архивы и файловые шары - RAIDZ.

Зеркало из двух дисков: самый частый случай

Массив из двух дисков в ZFS называется mirror и делается одной командой. Это ровно то, что нужно под системный раздел Proxmox или под небольшой пул на паре SSD:

Ёмкость - половина суммарной, зато чтение распараллеливается по обоим дискам, а ребилд после замены самый быстрый из возможных: ZFS копирует только реально занятые блоки, а не весь объём диска. Третий диск в то же зеркало добавляется командой zpool attach tank /dev/sda /dev/sdc - получится тройное зеркало, которое переживёт отказ двух накопителей из трёх.

Чего зеркало не даёт - защиты от одновременного отказа обоих дисков. Звучит маловероятно, пока не вспомнишь, что диски обычно покупают парой из одной партии и включают в один день. Зеркало не отменяет бэкап.

ZFS в Proxmox с нуля: пул, ashift и ARC

Установить Proxmox на ZFS можно прямо из инсталлятора: на шаге выбора диска нажмите Options и выберите zfs (RAID1) для пары дисков или zfs (RAIDZ-2) для четырёх и более. Альтернатива - ext4 поверх LVM, вариант по умолчанию. Тем, кто с самой файловой системой ещё не работал, стоит начать с разбора, что такое ZFS и кому она нужна - там про механику копирования при записи и чексумм.

Что выбрать. ZFS в корне даёт снапшоты системы, контроль целостности и зеркалирование загрузочного раздела из коробки, но требует памяти под кэш и не даёт менять уровень массива задним числом. ext4 проще, легче по памяти и не тянет ZFS-специфику - под него обычно берут mdadm или аппаратный контроллер. На одиночной ноде с парой SSD и достаточным объёмом ОЗУ удобнее ZFS; там, где памяти впритык, ext4 честнее.

ashift: единственный параметр, который нельзя поменять потом

ashift задаёт минимальный размер блока, которым ZFS оперирует на устройстве, как степень двойки. ashift=12 - это 2¹², то есть 4096 байт, физический размер сектора практически всех современных накопителей.

Ставить его вручную нужно потому, что некоторые диски врут о своей геометрии: сообщают систему 512-байтных секторов (эмуляция 512e), хотя физически работают с 4К. ZFS поверит и создаст пул с ashift=9, после чего каждая запись будет вызывать чтение-модификацию-запись целого сектора. Просадка на записи получается многократной.

ARC: сколько памяти заберёт ZFS

ARC - кэш чтения ZFS, живущий в оперативной памяти. По умолчанию апстримный ZFS отдаёт под него до половины всей памяти хоста, и на гипервизоре это неприятный сюрприз: половина ОЗУ уходит под кэш, а виртуальным машинам остаётся остальное.

Proxmox это учёл. Начиная с версии 8.1 инсталлятор ограничивает ARC десятью процентами физической памяти, но не больше 16 ГиБ, и записывает лимит в /etc/modprobe.d/zfs.conf.

Здесь прячется ловушка. Лимит выставляется только если ZFS выбран в инсталляторе. Поставили систему на ext4, а ZFS-пул собрали позже руками - никакого файла не появится, и ARC будет работать по апстримному правилу «до 50% памяти». Проверить текущее ограничение:

Задать свой лимит - правкой той же строки в /etc/modprobe.d/zfs.conf (пример на 8 ГиБ):

Файл правят редактором, а не перезаписывают через >: инсталлятор мог положить туда и другие параметры модуля. Дальше, если корень системы лежит на ZFS, пересобрать initramfs и перезагрузиться:

Сколько оставить - зависит от того, сколько памяти просят виртуальные машины. Общий ориентир по железу под гипервизор разобран в материале про системные требования Proxmox, там же посчитано, как складывать аппетиты гостей, самого Proxmox и ZFS.

Подключить готовый пул как хранилище

Созданный пул Proxmox подхватывает через Datacenter → Storage → Add → ZFS: выбираете пул, отмечаете, что на нём хранить (образы дисков, контейнеры), и он появляется в списке хранилищ. Из командной строки то же самое:

ZFS в Proxmox: снапшоты, компрессия и RAIDZ-экспансия

ZFS в Proxmox работает сразу на двух уровнях: и файловой системой, и менеджером хранилища. Вы создаёте пул, и Proxmox сразу видит его как хранилище для VM-дисков, контейнеров и бэкапов. Снапшоты атомарные и мгновенные, репликация между нодами кластера встроенная. Для HA-кластера Proxmox это означает, что при сбое узла виртуальные машины могут автоматически мигрировать на другую ноду, если данные реплицированы через zfs send/receive.

Как это работает на деле: вы настраиваете репликацию VM между двумя нодами с интервалом, скажем, 15 минут. Proxmox автоматически делает инкрементальный ZFS-снапшот, передаёт дельту на вторую ноду, и при сбое первой HA-менеджер запускает VM на второй. Потеря данных - только за последний интервал репликации. Без ZFS такую схему пришлось бы городить через Ceph или shared storage, что на порядок сложнее для небольших инсталляций на 2-3 ноды.

Снапшот ZFS удерживает старое состояние блоков, поэтому пул под ним не уменьшается, пока снимок жив. Чем это оборачивается, если про снимки забыть, разобрано в статье про снимки виртуальных машин и их подводные камни.

Компрессия LZ4 - ещё один аргумент в пользу ZFS. Она почти бесплатна по CPU, а выигрыш в ёмкости зависит от данных: образы VM сжимаются на 20-40%, бэкапы - на 30-60%. Включается одной командой и дальше работает прозрачно для всех операций с пулом.

Создание пула - пара команд:

Экспансия RAIDZ - одна из тех фич, которую сообщество ждало годами. Раньше, чтобы расширить RAIDZ, приходилось создавать новый vdev и добавлять его в пул, что давало неравномерное распределение данных. Теперь можно добавить один или несколько дисков прямо в существующий vdev:

Два нюанса. После экспансии пул получает feature flag raidz_expansion, и импортировать его на системах со старой версией ZFS (до 2.3) уже не получится - учитывайте при планировании миграций. И уровень RAIDZ экспансия не меняет: RAIDZ2 из шести дисков станет RAIDZ2 из семи, а не RAIDZ3.

Выбор уровня RAID для VM-хранилища

Два фаворита для хранения виртуальных машин в Proxmox - RAID10 (striped mirrors) и RAIDZ2. Выбор между ними - это компромисс между производительностью и ёмкостью.

Если на вашем отказоустойчивом сервере крутятся базы данных или VM с интенсивной записью - RAID10. IOPS на записи у зеркал кратно выше, потому что нет вычисления паритета. Каждая запись уходит только на два диска (оригинал плюс зеркало), а не рассчитывается через XOR с распределением по всему массиву. В реальной нагрузке шесть дисков в RAID10 (три зеркальных пары) дают IOPS, сопоставимые с тремя отдельными дисками, тогда как те же шесть дисков в RAIDZ2 работают как один - каждая запись блокирует весь vdev.

RAIDZ2 хорош для хранения больших объёмов с умеренной нагрузкой на запись: PBS (Proxmox Backup Server), файловые хранилища, ISO-образы. И у него есть козырь - защита от двух одновременных отказов. В массивах из 6-8 дисков, где ребилд занимает часы, вероятность потерять второй диск во время восстановления не теоретическая угроза, а вполне реальный сценарий, особенно если диски из одной партии. Под чисто файловые задачи связка «RAIDZ2 плюс сеть» часто оказывается дешевле, чем городить универсальный узел: под такие сценарии собирают отдельный nas файловый сервер с большими медленными дисками.

На крупных инсталляциях (12+ дисков) стоит посмотреть в сторону dRAID - distributed RAID, появившийся в ZFS 2.1 и поддерживаемый в Proxmox VE 9. dRAID распределяет запасные диски по всему пулу, что кратно ускоряет ребилд: вместо записи на один hot-spare данные восстанавливаются параллельно на все диски. Для массива из 24 HDD время ребилда сокращается с десятков часов до нескольких - а это прямо влияет на окно уязвимости, когда массив работает в деградированном состоянии.

mdadm: когда простота - это преимущество

Не всем нужен ZFS. Если задача - зеркалирование boot-дисков или создание простого массива без накладных расходов на ARC и чексуммы, mdadm справляется отлично. У него нет снапшотов, нет компрессии, нет контроля целостности на уровне блоков - зато нет и требований к памяти под кэш, а собственное потребление измеряется килобайтами.

Типичный сценарий: RAID1 для корневого раздела Proxmox на двух SSD. Система грузится с любого из дисков, при сбое одного второй продолжает работать. Proxmox при установке умеет настраивать ZFS mirror для root-раздела, но если вы предпочитаете ext4 или xfs - mdadm ваш вариант.

Уведомления по почте заработают только при настроенном на ноде MTA - без него --mail отработает молча и ничего не отправит. На чистой установке Proxmox проще завести оповещения через штатные каналы уведомлений в Datacenter → Notifications.

Ещё один плюс mdadm - совместимость. Если диск из массива вставить в другой сервер с Linux, mdadm подхватит метаданные и соберёт массив автоматически. С аппаратным RAID такой трюк не пройдёт - нужен совместимый контроллер.

Под хранилище VM лучше брать ZFS - там будут снапшоты и репликация, которых у mdadm нет. А вот гибридная схема - mdadm RAID1 на root, ZFS-пул на отдельных дисках для данных - встречается часто и работает стабильно.

Железо: HBA, ECC RAM и кэширующие SSD

Выбор железа определяет, как будет вести себя RAID в Proxmox под нагрузкой. Несколько правил, которые сэкономят нервы.

Контроллер для ZFS - только HBA в режиме JBOD (IT-mode). Серия LSI 9300/9400 (ныне под маркой Broadcom) или их аналоги - стандарт индустрии. FakeRAID на чипсетах Intel (RST) или AMD категорически не подходит: Proxmox не увидит отдельные диски, а ZFS не сможет контролировать их напрямую. Если у вас есть аппаратный RAID-контроллер, а ZFS нужен - перепрошейте контроллер в IT-mode. Для карт на чипах LSI это штатная процедура, прошивки и инструкции лежат на сайте производителя контроллера. Диски после перепрошивки станут видны ОС как обычные SATA/SAS-устройства. Чем режим JBOD отличается от настоящего массива и когда он уместен сам по себе, разобрано в статье про JBOD и его отличия от RAID.

Когда контроллер только предстоит купить, критерии выбора (интерфейс, кэш, поддержка IT-mode, совместимость с корзиной) собраны в отдельном разборе - как выбрать RAID-контроллер.

Нужна ли ZFS память с ECC

Вокруг этого накопился миф, который стоит разобрать. Формулировка «ZFS без ECC опаснее обычной файловой системы» ходит по форумам под названием «scrub of death»: якобы застрявший бит в памяти заставит скраб посчитать здоровые блоки битыми и переписать весь пул мусором.

Мэтт Аренс, соавтор ZFS, отвечал на это прямо: в ZFS нет ничего, что требовало бы ECC больше, чем ext4, XFS, NTFS или btrfs. Работая на машине без ECC, вы рискуете одинаково при любой файловой системе. FAQ проекта OpenZFS формулирует так же: ECC настоятельно рекомендуется, но не обязательна.

Практический вывод от этого не меняется: на сервере, который держит чужие данные, ECC-память нужна. Просто не потому, что этого требует ZFS, а потому, что этого требует сервер. Разница в том, что отсутствие ECC - не повод отказываться от ZFS в пользу ext4: защищённее вы от этого не станете.

SSD для ускорения ZFS используются в двух ролях. L2ARC - кэш второго уровня для чтения, полезен когда рабочий набор данных не помещается в RAM. SLOG (отдельное устройство под ZIL) ускоряет синхронную запись, что критично при работе с NFS или iSCSI. Без NFS/iSCSI SLOG не даёт заметного эффекта - ZFS и так буферизует записи в RAM перед коммитом.

Для аппаратного RAID ситуация другая: тут важен сам контроллер с BBU или NVRAM-кэшем. Broadcom MegaRAID 9560 или Adaptec SmartRAID - примеры карт с защищённым кэшем. Контроллер без батарейки в режиме write-back - это рулетка: при отключении питания данные из кэша не дойдут до дисков. Особенно аккуратно с кэшем нужно обращаться, когда контроллер меняют: про кэш записи при замене контроллера и порядок действий мы писали отдельно.

Мониторинг и обслуживание: scrub, замена дисков, уведомления

RAID любого типа - это не «настроил и забыл». Без мониторинга вы узнаете о проблеме, когда откажет второй диск в массиве с одной паритетной группой. А это уже потеря данных. Особенно коварна ситуация с тихой деградацией: диск формально в строю, S.M.A.R.T. не ругается, но отдельные секторы уже нечитаемы. Без регулярных проверок вы об этом не узнаете до момента ребилда после отказа другого диска - и тогда ребилд упадёт с ошибкой.

Лечится это скрабом: ZFS проходит по всем блокам пула, сверяет чексуммы и чинит расхождения, если есть избыточная копия данных. Это единственный способ поймать silent data corruption (тот самый bit rot, о котором многие слышали, но мало кто видел - пока не столкнулся).

Раз в месяц - разумный ритм для HDD-пулов: скраб читает весь занятый объём и на медленных дисках идёт часами. На SSD-пулах, где проход быстрый, некоторые переходят на еженедельный. Делается это штатными таймерами, которые появились в ZFS 2.3:

Включив таймер, закомментируйте запись в /etc/cron.d/zfsutils-linux. Иначе пул будет скрабиться и по таймеру, и по крону - лишняя нагрузка на диски без всякой пользы.

ZED (ZFS Event Daemon) отправляет уведомления при ошибках чтения и записи, деградации пула или завершении скраба. Настройка - в /etc/zfs/zed.d/zed.rc, где указывается адрес для алертов. Если вы используете Zabbix или Prometheus - парсите вывод zpool status и zpool list: ключевые метрики это health (ONLINE/DEGRADED/FAULTED), capacity и errors по каждому диску.

Про заполнение стоит сказать отдельно. Классическая рекомендация - не заходить за 80% ёмкости пула: дальше ZFS сложнее искать непрерывные куски свободного места, растёт фрагментация и падает скорость записи. Порог зависит от нагрузки, и на пулах, куда данные в основном дописывают и почти не удаляют, спокойно живут и на 90%. А вот выше 90% выбираться из ситуации уже тяжело в любом сценарии. Если пул под бэкапы упирается в потолок, разобраться поможет статья про очистку места и удаление старых резервных копий.

Диски: как посмотреть состояние и что делать с DEGRADED

Первое место, куда стоит смотреть, - вкладка Disks в веб-интерфейсе ноды. Она показывает все физические накопители, их модель, серийник, размер и итог самодиагностики S.M.A.R.T. в колонке Health. Оттуда же открывается детальный отчёт по конкретному диску. Из командной строки то же самое:

Состояние пула читается по слову в колонке state:

Замена в ZFS - онлайн-операция, останавливать ноду не нужно:

После замены ZFS запускает resilver - восстановление избыточности. Его часто путают со скрабом, хотя задачи разные: скраб проверяет весь пул на целостность, resilver переписывает на новый диск данные, которых на нём не хватает. Важное отличие ZFS от аппаратного RAID: resilver копирует только реально занятые блоки, а не весь объём диска. Пул, заполненный на треть, восстановится примерно втрое быстрее, чем полный.

Разовые ошибки в zpool status - скажем, от дёрнутого кабеля - сбрасываются вручную:

Сбрасывать счётчики имеет смысл только когда вы поняли причину. Ошибки, которые возвращаются после zpool clear, - это отказывающий диск, а не случайность.

Для mdadm логика та же, инструменты свои: состояние массива - в /proc/mdstat и mdadm --detail /dev/md0, замена - через mdadm --manage /dev/md0 --remove /dev/sda1 и --add.

Короткие ответы на частые вопросы

Чем RAIDZ1 отличается от RAID5? Уровнем избыточности они совпадают - один диск паритета. Разница в реализации: RAIDZ пишет полосу переменной длины и не подвержен write hole, из-за которой классический RAID5 может оставить полосу наполовину записанной при пропаже питания. Плюс RAIDZ считает чексумму каждого блока и умеет чинить тихую порчу данных.

Сколько дисков нужно минимум? Зеркало - 2, RAIDZ1 - 3, RAIDZ2 - 4, RAIDZ3 - 5. Это технический минимум; по производительности OpenZFS советует держать в vdev от 3 до 9 дисков.

ZFS или ext4 при установке Proxmox? ZFS, если нужны снапшоты, контроль целостности и зеркалирование системного раздела из коробки, и на хосте есть память под ARC. ext4, если памяти впритык или вы предпочитаете mdadm с аппаратным контроллером. Поменять решение потом можно только переустановкой.

Обязательна ли ECC-память для ZFS? Нет. ZFS без ECC не опаснее, чем ext4 или NTFS без ECC, - это подтверждали и соавтор ZFS Мэтт Аренс, и FAQ проекта OpenZFS. Но ECC нужна любому серверу с чужими данными, независимо от файловой системы.

Можно ли собрать ZFS поверх аппаратного RAID? Технически да, практически не стоит. Контроллер прячет физические диски, и ZFS теряет главное - возможность увидеть, на каком именно накопителе ошибка, и починить её по избыточной копии. Есть аппаратный контроллер - ставьте ext4 или xfs, а под ZFS переводите карту в IT-mode.

Что такое resilver и чем он отличается от scrub? Resilver восстанавливает избыточность после замены диска: пишет на новый накопитель то, чего на нём не хватает. Scrub проверяет целостность всего пула и чинит найденные расхождения. Первый запускается сам после zpool replace, второй идёт по расписанию.

Можно ли расширить существующий RAIDZ? С ZFS 2.3 - да, командой zpool attach прямо в работающий vdev. В Proxmox VE 9.2 идёт ZFS 2.4, так что функция доступна. Уровень при этом не меняется: RAIDZ2 останется RAIDZ2, просто дисков станет больше.

Что дальше

RAID в Proxmox - это фундамент, на котором стоит отказоустойчивый сервер. ZFS с интеграцией в Proxmox, репликацией и снапшотами - выбор для тех, кто строит HA-кластер и хочет управлять хранилищем из одного места. Аппаратный RAID с BBU - для нагрузок, где критичен каждый IOPS на записи, и вы готовы привязаться к конкретному контроллеру. mdadm - для простых сценариев, где надёжность нужна без накладных расходов и дополнительных требований к оперативной памяти.

Гибридные схемы тоже работают: mdadm на boot, ZFS на данных, аппаратный контроллер в JBOD-режиме для проброса дисков. Не бойтесь комбинировать - лучшая архитектура хранилища та, которая учитывает вашу конкретную нагрузку, бюджет и навыки команды.

А какую бы технологию вы ни выбрали - настройте мониторинг и проверьте, что скраб реально идёт по расписанию. Массив без наблюдения деградирует тихо, и вы об этом узнаете в тот день, когда уже будет поздно.