Debian/Ubuntu: как исправить device or resource busy при mdadm --stop RAID

Ситуация знакомая: есть программный RAID на mdadm, вы хотите его остановить, разобрать, удалить или переиспользовать диски, а в ответ получаете ошибку device or resource busy. На Debian и Ubuntu это одна из самых частых проблем при работе с md-массивами, особенно после миграций, замены дисков, отключения старого хранилища или перед пересборкой разметки.

Главная мысль простая: mdadm --stop почти никогда не «ломается сам по себе». Если массив считается занятым, значит ядро, systemd, LVM, файловая система, swap, процессы, контейнеры или другой слой хранения всё ещё держат устройство открытым. Поэтому лечится это не повторением команды с надеждой, а нормальной диагностикой стека блочного устройства сверху вниз.

Типичный сценарий выглядит так: администратор проверяет /proc/mdstat, видит массив /dev/md0, запускает остановку и получает отказ. Дальше начинаются попытки форсировать удаление суперблока или даже перезагружать сервер. Иногда это помогает, но часто приводит только к дополнительной путанице: устройство автоматически собирается снова, LVM повторно активирует volume group, а причина остаётся.

Если вы разбираете старый массив, правило номер один — сначала убедитесь, что это точно не корневой раздел, не активный swap, не часть LVM, не база Docker, не точка монтирования для резервных копий и не устройство, с которого что-то сейчас читает или пишет система. Даже если каталог не смонтирован «на глаз», это ещё не значит, что устройство свободно.

Ниже разберём порядок действий, который помогает в большинстве случаев, когда возникает ошибка при остановке массива на рабочем сервере или на VDS.

Что именно означает ошибка

Сообщение device or resource busy означает, что блочное устройство всё ещё используется каким-то потребителем. Для mdadm --stop это может быть:

• смонтированная файловая система на массиве или внутри него;
• активный swap на /dev/mdX;
• LVM PV/VG/LV, построенные поверх массива;
• dm-crypt или другие device-mapper слои;
• dmraid или остатки старой метадаты fake RAID;
• процессы, открывшие файлы на этом устройстве;
• контейнеры, гипервизор, backup-агенты, мониторинг;
• автосборка массива через udev, systemd или mdmon.

Самая частая ошибка в диагностике — смотреть только на сам /dev/mdX. Проверять нужно весь стек: что расположено поверх массива и что лежит под ним.

Базовая схема диагностики: от верхнего уровня к нижнему

Начните с понимания структуры устройства. Важно увидеть не только сам массив, но и дочерние или родительские сущности: разделы, LVM-тома, точки монтирования, swap и типы файловых систем.

lsblk -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,UUID

Эта команда часто показывает половину проблемы сразу. Если на /dev/md0 есть lvm, сначала придётся деактивировать логические тома. Если виден swap, его нужно выключить. Если есть точка монтирования, сначала размонтировать её.

Затем проверьте, что ядро думает о массиве:

cat /proc/mdstat
mdadm --detail /dev/md0

После этого отдельно посмотрите монтирования и подкачку:

findmnt -rno TARGET,SOURCE /dev/md0
mount | grep '/dev/md0'
swapon --show

Если массив используется как PV для LVM, то findmnt по самому /dev/md0 может ничего не показать, потому что смонтированы уже логические тома, а не сам массив. Именно поэтому одного только mount недостаточно.

Проверяем LVM: самая частая причина busy-массива

Очень часто проблема связана не с обычным монтированием, а с тем, что поверх RAID поднят LVM. Сценарий типичный: массив /dev/md0 является physical volume, внутри него есть volume group, а уже из неё смонтированы логические тома. Пока LVM активен, остановить массив нельзя.

pvs
vgs
lvs -a -o +devices

Если среди устройств виден ваш /dev/md0, сначала нужно размонтировать файловые системы на логических томах, затем деактивировать сами тома и группу.

findmnt
umount /путь/к/точке_монтирования
swapoff /dev/mapper/vgname-lvname
lvchange -an /dev/vgname/lvname
vgchange -an vgname

После этого проверьте, что volume group действительно ушла в неактивное состояние:

lvs -a -o +devices
pvs

Если LVM всё ещё активируется автоматически, посмотрите, не держит ли его какой-нибудь сервис, например Docker, libvirt, резервное копирование или база данных, размещённая на логическом томе.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Ищем открытые файлы и процессы: lsof и fuser

Когда структура хранения уже понятна, пора выяснить, кто именно удерживает устройство. Для этого полезны и lsof, и fuser.

lsof /dev/md0
fuser -vm /dev/md0

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

lsof +f -- /mount/point
fuser -vm /mount/point

Типичные виновники:

• bash или ssh-сессия, чей текущий каталог находится на этом разделе;
• резервное копирование, rsync, архиваторы;
• Docker, containerd, Podman;
• виртуальные машины через libvirt или qemu;
• мониторинг, который читает файловую систему или RAID-статус;
• редакторы, оболочки, файловые менеджеры;
• systemd-юниты с рабочим каталогом на этом томе.

Если нашли процесс, не спешите сразу делать жёсткое завершение. Сначала остановите сервис штатно:

systemctl stop имя_сервиса
systemctl status имя_сервиса

Потом повторно проверьте lsof и fuser. Жёсткое завершение процессов допустимо только когда вы точно понимаете последствия.

Проверяем swap на RAID

Ещё одна причина, о которой часто забывают: массив или логический том на его основе используется как подкачка. Визуально это легко пропустить, особенно если система поднимала swap автоматически из fstab.

swapon --show --output=NAME,TYPE,SIZE,USED,PRIO

Если видите там нужное устройство, отключите его:

swapoff /dev/md0

Либо, если подкачка находится на логическом томе:

swapoff /dev/vgname/lv_swap

После этого имеет смысл проверить, не включится ли она снова автоматически через systemd или после перечитывания fstab. На этапе демонтажа массива лучше временно закомментировать соответствующую строку в конфигурации и потом уже продолжать работы.

Device Mapper, dmraid и dm-crypt: когда проблема глубже, чем кажется

Если простой RAID-сценарий не сходится, посмотрите на device mapper. Часто встречается история, когда на дисках раньше был fake RAID, LUKS или другая метадата, а теперь система видит сразу несколько слоёв. В результате массив кажется занятым, хотя удерживает его вовсе не файловая система.

lsblk -o NAME,PATH,TYPE,FSTYPE,MOUNTPOINTS
dmsetup ls --tree

Если поверх массива открыт LUKS-контейнер, его надо закрыть после размонтирования файловой системы внутри:

cryptsetup status cryptname
cryptsetup close cryptname

Если в системе остались следы dmraid, стоит посмотреть их отдельно:

dmraid -r
dmraid -s

Смешение dmraid, LVM и mdadm — классическая причина долгой отладки. Здесь главная задача — не удалять метаданные вслепую, пока вы не поняли, кто реально владеет устройством.

Если после разборки массива вы планируете расширять файловую систему или диск на сервере, может пригодиться отдельная инструкция по увеличению раздела и файловой системы на VDS.

Проверяем, не держит ли массив mdmon, udev или systemd

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

ps aux | grep mdmon
systemctl list-units | grep md
udevadm info /dev/md0

Также полезно посмотреть последние сообщения ядра и udev:

dmesg | tail -n 100
journalctl -xe --no-pager | grep -E 'md|raid|lvm|dm-'

Если после остановки массив тут же пересобирается, причиной может быть автосканирование. В такой ситуации важно не бороться с симптомом, а временно остановить сервисы или изменить порядок действий: деактивировать верхние слои, убедиться, что ни один участник массива не используется, и только потом выполнять остановку.

Практический порядок безопасного dismantle RAID

Если задача — именно разобрать старый RAID в Debian или Ubuntu, а не просто временно его остановить, лучше действовать последовательно.

1. Сделайте резервную копию и убедитесь, что массив не содержит нужных данных.
2. Проверьте структуру устройств через lsblk.
3. Найдите и размонтируйте все файловые системы поверх массива.
4. Отключите swap, если он расположен на RAID или внутри LVM на RAID.
5. Деактивируйте LVM: сначала lvchange -an, затем vgchange -an.
6. Закройте cryptsetup, если есть LUKS-слой.
7. Остановите сервисы и процессы, которые держат устройство, проверив это через lsof и fuser.
8. После этого выполните mdadm --stop /dev/mdX.
9. Только когда массив точно остановлен, переходите к очистке суперблоков или новой разметке.

Сама команда остановки выглядит просто:

mdadm --stop /dev/md0

Но запускать её имеет смысл только после всех предыдущих шагов. Если система отвечает ошибкой снова, не форсируйте разрушение метаданных до повторной проверки. Обычно причина просто ещё не найдена.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Когда busy вызывает неочевидное монтирование

Иногда массив не смонтирован напрямую, но используется bind-монтированиями, chroot-окружениями, контейнерами или namespace-процессами. В таких случаях стандартный mount | grep md0 может ничего не показать, а файловая система всё равно занята.

Помогают такие проверки:

findmnt -R
lsns
systemctl list-units --type=mount
docker ps
virsh list --all

Особенно часто это случается на серверах, где старый RAID использовался как каталог данных Docker, backup target или storage для виртуальных машин. Формально монтирование есть, но удерживает его уже не интерактивный пользователь, а демон.

Почему не стоит сразу делать --zero-superblock

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

Сначала остановка и полное освобождение устройства, потом очистка метаданных. Не наоборот.

Если вы собираетесь полностью уничтожить старый массив, проверьте ещё раз, что он больше нигде не описан в fstab, не фигурирует в конфигурации initramfs и не нужен для загрузки системы. Для корневого RAID последовательность действий будет совсем другой и обычно требует live-окружения или rescue-режима.

Чек-лист, если mdadm всё ещё пишет busy

Если после всех шагов массив по-прежнему не останавливается, пройдитесь по короткому чек-листу:

• точно ли это не корневой или загрузочный RAID;
• нет ли смонтированных LVM-томов поверх массива;
• не активен ли swap;
• не открыт ли cryptsetup;
• не используют ли устройство контейнеры или виртуальные машины;
• не держит ли точку монтирования текущая shell-сессия;
• нет ли автосборки через udev, mdmon или systemd;
• не осталась ли старая метадата dmraid или device mapper.

В сложных случаях полезно зафиксировать полную картину состояния перед изменениями:

lsblk -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,UUID
cat /proc/mdstat
mdadm --detail /dev/md0
pvs
vgs
lvs -a -o +devices
swapon --show
dmsetup ls --tree
lsof /dev/md0
fuser -vm /dev/md0

Если похожие проблемы возникают из-за зависших сервисов поверх томов, полезно отдельно включить и разобрать slowlog для PHP-FPM, чтобы понять, какие процессы дольше всего держат файловую систему.

Итог

Ошибка device or resource busy при mdadm --stop в Debian или Ubuntu почти всегда указывает на реального потребителя устройства. В большинстве случаев это LVM, активный swap, смонтированная файловая система, контейнерный runtime, device mapper или просто процесс с открытыми файлами.

Рабочий подход такой: сначала lsblk и карта слоёв, потом проверка монтирования и swap, затем LVM, lsof и fuser, после этого device mapper и фоновые сервисы. И только когда стек полностью освобождён, mdadm --stop проходит штатно.

Именно такая последовательность экономит больше всего времени: не гадать, а методично снять все зависимые слои и только потом работать с самим RAID.