Отказ одного накопителя не должен оборачиваться простоем сервиса и потерей данных. Зеркальный массив RAID1 страхует от этого без покупки отдельного контроллера: каждый байт одновременно ложится на два диска, и если один из них выйдет из строя, система продолжит работать со второго.
В Linux всем этим заведует встроенная утилита mdadm. Ниже — практический разбор: как с нуля собрать RAID1, от разметки накопителей до автозагрузки и контроля состояния. Примеры команд даны для Ubuntu/Debian; где поведение в RHEL-семействе отличается, это отмечено отдельно.
Что такое программный RAID и mdadm
Программным RAID называют объединение нескольких физических накопителей в единый логический том силами самой ОС, без отдельной платы-контроллера. За эту работу в ядре Linux отвечает подсистема md (multiple devices), а точкой входа для администратора служит утилита mdadm — её применяют и для сборки массивов, и для их дальнейшего сопровождения.
RAID1: принцип зеркалирования
В RAID1 на всех дисках лежат идентичные копии данных. При записи информация дублируется на каждый накопитель, а запросы на чтение можно распределять между ними. Отказ одного диска переводит массив в режим degraded, но не останавливает его: оставшийся накопитель продолжает отдавать данные, и ни простоя, ни потерь при этом не происходит.
Сильные стороны: надёжность, моментальное восстановление чтения, несложная настройка.
Слабые стороны: под полезные данные доступен объём лишь одного диска (половина суммарной ёмкости); запись чуть медленнее, чем на одиночный накопитель, поскольку дублируется.
Программный RAID против аппаратного
| Параметр | mdadm (программный) | Аппаратный контроллер |
|---|---|---|
| Затраты | без доплат | требуется контроллер |
| Миграция на другой сервер | без проблем | завязан на контроллер |
| Расход ресурсов CPU | для RAID1 минимальный | снимается контроллером |
Под зеркало mdadm подходит как нельзя лучше: вычислительные затраты на дублирование ничтожны, а сам массив не привязан к железу и без труда переезжает с сервера на сервер.
Что понадобится перед началом
- Два накопителя одинакового размера (в примере —
/dev/vdbи/dev/vdc, типичные virtio-диски облачной ВМ). - Права root либо учётная запись с sudo.
- Свежая резервная копия.
Важно: содержимое дисков, которые войдут в массив, будет стёрто. Дважды проверьте имена устройств, прежде чем продолжать.
В руководстве собирается отдельный массив под данные, который затем монтируется в каталог. Перенос на RAID1 корневого и загрузочного разделов — задача со своей спецификой (метаданные версии 1.0, запись GRUB сразу на оба диска), и здесь она не затрагивается.
Установка mdadm
sudo apt update
sudo apt install mdadm
mdadm --version
В RHEL/CentOS/Rocky пакет ставится через sudo dnf install mdadm.
Подготовка и разметка дисков
Выведем перечень накопителей и удостоверимся, что работаем именно с нужными:
lsblk
На каждом диске создадим таблицу разделов GPT и один раздел во весь объём с флагом raid. Для /dev/vdb это выглядит так:
sudo parted /dev/vdb --script mklabel gpt
sudo parted /dev/vdb --script mkpart primary 0% 100%
sudo parted /dev/vdb --script set 1 raid on
Те же три команды повторяем для /dev/vdc. В итоге появляются разделы /dev/vdb1 и /dev/vdc1.
Если диски раньше работали в составе другого массива, сотрём остаточные метаданные, чтобы они не спровоцировали конфликт:
sudo mdadm --zero-superblock /dev/vdb1 /dev/vdc1Создание массива RAID1
Зеркало собирается одной командой:
sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/vdb1 /dev/vdc1Что означают аргументы:
/dev/md0— имя будущего массива;--level=1— уровень RAID (зеркалирование);--raid-devices=2— сколько активных дисков входит в массив;- далее перечислены сами разделы-участники.
Если разделы не помечены загрузочными, mdadm может предупредить о формате метаданных и попросить подтверждение — для дискового (незагрузочного) массива отвечаем y.
Проверка состояния массива и resync
Сразу после сборки запускается первичная синхронизация (resync): диски приводятся к одинаковому содержимому. Пользоваться массивом можно немедленно, не дожидаясь её завершения. Ход процесса отображает /proc/mdstat:
cat /proc/mdstatПримерно такой вывод:
md0 : active raid1 vdc1[1] vdb1[0]
209584128 blocks super 1.2 [2/2] [UU]
[====>................] resync = 23.4% (49072192/209584128) finish=11.3min speed=235008K/sec
Запись [2/2] говорит, что в строю 2 диска из 2, а [UU] — оба исправны (U — Up). Будь один из них недоступен, на его месте оказался бы прочерк: [U_]. Развёрнутые сведения покажет:
sudo mdadm --detail /dev/md0Форматирование и монтирование
Создадим поверх массива файловую систему ext4, каталог для подключения и смонтируем том:
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/storage
sudo mount /dev/md0 /mnt/storage
df -h /mnt/storage
После этого массив доступен в /mnt/storage и ведёт себя как обычный диск.
Сохранение конфигурации массива
Чтобы после перезагрузки система знала, как собрать массив, занесём его описание в конфигурационный файл:
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
В Ubuntu и Debian файл лежит по пути /etc/mdadm/mdadm.conf, в системах на базе RHEL — /etc/mdadm.conf. Команда дописывает строку ARRAY в конец файла, поэтому при повторном запуске (например, когда массив пересобирают) загляните в конфиг и убедитесь, что описание массива в нём одно, без дубля.
Затем пересоберём образ initramfs, чтобы массив поднимался на раннем этапе старта:
sudo update-initramfs -u
В RHEL/CentOS для этого служит sudo dracut -f.
Важно: пропускать этот шаг нельзя. Без строки в mdadm.conf и обновлённого initramfs массив после перезагрузки рискует не собраться вовсе или получить другое имя — например, /dev/md127.
Автозагрузка через fstab
Для автоматического монтирования пропишем массив в /etc/fstab, опираясь на UUID, а не на имя устройства. Сначала узнаём UUID:
sudo blkid /dev/md0
Добавляем в /etc/fstab строку (UUID подставьте свой):
UUID=ваш-uuid /mnt/storage ext4 defaults,nofail 0 2
Флаг nofail не даст серверу застрять на загрузке, если с массивом что-то пойдёт не так. Запись проверяем без перезагрузки:
sudo mount -aОтсутствие ошибок означает, что всё прописано верно.
Мониторинг mdadm и email-оповещения
Толк от RAID есть лишь тогда, когда о сбое узнают вовремя. mdadm способен наблюдать за массивами в фоне и отправлять письма. Адрес задаётся в конфиге:
MAILADDR raid-alerts@example.com
Демон наблюдения (mdmonitor под управлением systemd) в большинстве дистрибутивов уже работает и читает этот файл. Учтите: само письмо уходит через системный MTA, поэтому без настроенного почтовика (postfix, exim или лёгкий msmtp) уведомление не отправится, даже если тестовая команда отработала без ошибок. Проверить рассылку поможет тестовое уведомление:
sudo mdadm --monitor --scan --test --oneshotДля ручных проверок состояния пригодятся две команды:
cat /proc/mdstat
sudo mdadm --detail /dev/md0
Не лишним будет завести в системе мониторинга оповещение на смену статуса массива (degraded, [U_]) — тогда на отказ диска удастся среагировать в первые же минуты.
Ежемесячно массив стоит прогонять на целостность (scrubbing): ядро перечитывает все блоки обоих дисков и выявляет скрытые сбойные секторы заранее, до того как они помешают ребилду после реальной аварии. Ручной запуск:
echo check | sudo tee /sys/block/md0/md/sync_action
Прогресс отражается в /proc/mdstat, а счётчик расхождений — в /sys/block/md0/md/mismatch_cnt (норма — ноль). В Ubuntu и Debian эта проверка уже выполняется автоматически: за неё отвечает скрипт checkarray из задания /etc/cron.d/mdadm с ежемесячным запуском.
Частые ошибки и FAQ
Массив исчез или сменил имя после перезагрузки. Почти всегда причина — пропущенное сохранение конфигурации. Внесите массив в mdadm.conf и пересоберите initramfs (update-initramfs -u либо dracut -f).
Массив в статусе inactive или auto-read-only. Соберите его вручную: sudo mdadm --assemble --scan. Состояние auto-read-only обычно снимается с первой же записью на массив.
Resync тянется слишком долго или мешает нагрузке. Скорость регулируют параметры /proc/sys/dev/raid/speed_limit_min и speed_limit_max. На работу с массивом синхронизация не влияет — данные уже защищены.
Один из дисков отказал — порядок действий. Базовая последовательность замены: пометить накопитель сбойным, убрать из массива, заменить физически, добавить новый раздел — дальше восстановление пойдёт само:
sudo mdadm --manage /dev/md0 --fail /dev/vdc1
sudo mdadm --manage /dev/md0 --remove /dev/vdc1
# физически меняем диск, затем на новом стираем старые сигнатуры и размечаем как первый:
sudo wipefs -a /dev/vdc
sudo parted /dev/vdc --script mklabel gpt
sudo parted /dev/vdc --script mkpart primary 0% 100%
sudo parted /dev/vdc --script set 1 raid on
sudo mdadm --manage /dev/md0 --add /dev/vdc1
cat /proc/mdstat # следим за восстановлениемДля массивов примерно от сотни гигабайт mdadm по умолчанию заводит внутренний write-intent bitmap (на маленьких зеркалах его может не быть). Bitmap помечает изменённые блоки, поэтому после кратковременного отключения диска повторная синхронизация затрагивает только их, а не весь объём, — и ребилд идёт многократно быстрее.
Сервер на загрузке ждёт ввод из-за деградированного массива. Для тома с данными вопрос снимает опция nofail в fstab (мы её уже добавили). Если же на RAID1 размещён корень, поведением управляет команда sudo dpkg-reconfigure mdadm (параметр BOOT_DEGRADED в /etc/initramfs-tools/conf.d/mdadm): сервер поднимется автоматически даже с единственным живым диском, не дожидаясь администратора.
RAID — это не резервная копия. Зеркало страхует от физического отказа диска, но не спасёт от случайного удаления файлов, ошибки оператора или шифровальщика: всё это мгновенно отразится на обоих дисках. RAID1 и регулярный бэкап решают разные задачи и не заменяют друг друга.
Заключение
Сборка RAID1 на mdadm укладывается в несколько минут и не требует специального оборудования: размечаем диски, создаём массив, форматируем, прописываем автозагрузку и подключаем мониторинг. В результате сервер переживает отказ накопителя без простоя и без потери данных. Ключевое — не пропустить сохранение конфигурации и оповещения: именно они превращают набор команд в реально работающую защиту.
После перезагрузки стоит пробежаться по короткому чек-листу:
cat /proc/mdstatпоказывает[UU]— оба диска в строю;- том смонтирован (
df -h /mnt/storage); - тестовое письмо от mdadm дошло до почты.
Если возиться с дисками и следить за состоянием массивов самостоятельно не хочется, эту заботу можно переложить на инфраструктуру Cloud4y — отказоустойчивое хранилище и серверы обслуживаются на стороне провайдера.
