# Притча о том, как я RAID воскрешал (почти)

![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/fac9d383-b4c5-42f3-a184-266318307e4d/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=a2f034341992e57b867ceeda3cd7a11b3e113b09ecdf8bc09226800bff325ef3&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =1080x819")

# ДИСКЛЕЙМЕР

> **ВНИМАНИЕ!**
>
> Все события, хосты, UUID, md-устройства, hypervisor’ы, логи и особенно “тот самый sda7” в этом топике являются полностью вымышленными.
>
> 
> Любые совпадения с реально существующими продакшн-хостами, vSphere-кластерами, datastore’ами, корпоративными продуктами и особенно рабочими миграциями - абсолютно случайны.
>
> 
> Настоящий кейс произошёл в параллельной вселенной, где:
>
> * хосты не падают в Not Responding
> * миграции всегда проходят успешно
> * а RAID1 из одного диска - это нормальная идея
>
> 
> Все UUID, номера md-устройств, размеры разделов и временные метки были:
>
> * искажены
> * подделаны
> * переименованы
> * замаскированы
> * подвергнуты процедуре “мы вообще не знаем о чём вы говорите”
>
> 
> Никакие реальные логи не пострадали.  
> Никакие реальные storage-файлы не были побиты.  
> Никакие реальные админы не нервничали.
>
> 
> Если вы думаете, что узнали свою инфраструктуру - **это не она.**  
> Это *другая* инфраструктура.  
> Очень похожая. Но не ваша.
>
> 
> Спасибо за понимание.  
> И помните: это всё было сделано “на тестовом стенде”. Всегда.


---

# Кейс

Одним вечером на нашем vSphere во время миграции ВМ хост решил уйти в статус **not responding**, как результат… побитые storage файлы на ВМ.

Получаю трассу при попытке стартануть ВМ:

```bash
Timed out waiting for device /dev/disk/by-uuid/0c2ab381-4122-4a60-8894-f1bafc0d9491
Dependency failed for /mnt/logs
Dependency failed for /var/log
Dependency failed for Local File Systems
...
You are in emergency mode
...
```

В целом… это **классический кейс падения в emergency mode из-за отсутствующего/недоступного диска**, прописанного в `/etc/fstab`… подумал я, но оказалось все немного сложнее.

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/d8544616-5f78-4229-a7e0-2b7e7fe9f531/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=364b9f674a8332d444f2f96605de90476af603b079bc039ad7bb18851af0d231&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =1280x720")

## **Что происходит технически**

* В `/etc/fstab` есть запись с UUID:

  `0c2ab381-4122-4a60-8894-f1bafc0d9491 `
* При старте `systemd`:
  * пытается смонтировать этот UUID
  * ждёт появления устройства в `/dev/disk/by-uuid/`
* Устройство не появляется → происходит timeout.
* Падают зависимости:
  * `/mnt/logs`
  * `/var/log`
  * `local-fs.target`
* Базовые файловые системы не собираются → система уходит в `emergency mode`.

## Первичный анализ

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

* `cat /etc/fstab` - проверяем fstab, хотим убедится, что строка с UUID существует

  fstab содержит UUID - тут всё ожидаемо.
* `blkid` - проверить, существует ли UUID

  И вот тут начинается самое интересное, при выполнении команды мы получаем:

  ```bash
   [ 388.113146 ] Buffer I/O error on dev md124
  ```

Это уже не похоже на проблему fstab…

## Смотрим, что такое md124

Хм… окей, давайте глянем к какому RAID мемберу он может относится:

```bash
lsblk -f
```

И видим там такое:

```bash
sda7  linux_raid_member
 └─ md124
```

Какой вывод мы можем сделать…

* `sda7` - RAID member
* он собирается в `md124`
* ext4 UUID отсутствует
* присутствуют I/O ошибки

  Выходит… это уже уровень блока, а не конфигурации.

## Проверяем состояние RAID

Окей… мы в целом поняли, что дело не в fstabе, теперь надо провести анализ mdшки и убедится, что она живая:

```bash
cat /proc/mdstat

md124 : active (auto-read-only) raid1 sda7[0]
State : clean
Working Devices : 1
Failed Devices : 0
```

Это значит:

* RAID собран
* состояние clean
* диск не failed
* массив single-disk RAID1 (по факту просто зеркало из 1 диска)

Окей круть, выходит RAID metadata читается.

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/bb1108ea-cfe0-4a34-be54-0679a35f439e/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=d1c458294e7b77cf3e3bb23770439d4425ac3db3638b8c4e7bc27e7dc25284b3&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =687x458")Но это не значит, что читаются данные.

## Попытки восстановления

Дальше идет очень и очень долгий путь… проб различными способами восстановить `/dev/md124`, в ход шло:

```bash
fsck.ext4 -f /dev/md124 # тут мы вообще зависали
...
blkid /dev/md124
file -s /dev/md124
mount /dev/md124 /mnt/test
...
...
# А ТУТ ВЕЗДЕ Я ПОЛУЧАЛ
Buffer I/O error on dev md124, logical block 0
```

Как итог… ядро не может прочитать блоки с md124 по сути это ошибка I/O диска

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/2fe17ad3-3838-4e1c-88e8-2a10dba5d6f6/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=e7e0750dd9d62f690616ca27bba07ca218395d945a93c7289f4f33d518f4d62c&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =600x329")


---

# Что это означает в контексте VM

`md124` - это RAID1 из `/dev/sda7`.

RAID1 из одного диска - фактически просто прокси к `sda7`.

Если есть:

```bash
Buffer I/O error on md124
```

То это эквивалент:

```bash
Buffer I/O error on sda7
```

Возможные причины:

* повреждение виртуального диска
* сбой storage backend
* corruption VMDK / datastore
* некорректная миграция
* зависший hypervisor

Физическая деградация диска - исключаем, это виртуалка.

**Итог:** раздел logs физически не читается.

## Быстрое решение (временное)

В целом… мы можем запустить нашу систему, для этого достаточно закомментировать записи в `/etc/fstab`:

```bash
#UUID=0c2ab381-4122-4a60-8894-f1bafc0d9491 /mnt/logs ...
#/mnt/logs/system ...
#/mnt/logs/core ...
#/mnt/logs/coredump ...
```

После:

```bash
mount -a # тут важно убедится, что нет ошибок
reboot
```

Система загрузится.

Но… теряем весь раздел логов

## Финальное решение: чистое пересоздание массива logs

Принимаю волевое решение - пересоздать md-массив.

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/d6a61b38-c823-4293-9d76-78005fbfeefd/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=e8e6b126edee80a7fb74409d749d814909224bed5013fb314f2b3d8f3943f61d&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =480x542")

А почему нет, погнали!

p.s. всяко бекапов нет… а все что там было уже давно превратилось в тыкву.

После ребута массив сменил номер (md124 → md126).  
Номер не важен - важно устройство и размер (\~200G).

И для этого нам нужно пройти 8 шагов:


1. Найти logs-массив
2. Убрать старые записи из fstab
3. Остановить массив
4. Очистить superblock
5. Пересоздать массив
6. Создать файловую систему
7. Получить новый UUID
8. Ребут

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/616b8bfa-3343-4da6-9f4c-823ecb162831/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=59a67eba5361852792f559904794081a1f055bb1eb099a7b6a40a6c7a8029a1e&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =768x576")

### Найти logs-массив

```bash
cat /proc/mdstat
lsblk -f
```

Ищем md-устройство \~200G без mountpoint.  
В моём случае - `/dev/md126`.

### Убрать старые записи из fstab

Закомментировать UUID и bind-mount строки (если вдруг мы раскомментили, вообще тут уже можно убирать старый UUID, он нам не нужен):

```bash
#UUID= /mnt/logs ...
#/mnt/logs/system ...
#/mnt/logs/core ...
#/mnt/logs/coredump ...
```

Проверить:

```bash
mount -a
```

Если нет ошибок → идем дальше

### Остановить массив

```bash
umount /dev/md126 2>/dev/null
mdadm --stop /dev/md126
```

Важно так же убедиться, что он исчез из `/proc/mdstat`.

### Очистить superblock

```bash
mdadm --zero-superblock /dev/sda7
mdadm --examine /dev/sda7
```

RAID metadata больше не должно быть

### Пересоздать массив

```bash
mdadm --create /dev/md126 \
  --level=1 \
  --raid-devices=1 \
  /dev/sda7 \
  --metadata=1.2 \
  --force
```

Проверяем что массив создался:

```bash
cat /proc/mdstat
```

### Создать файловую систему

```bash
mkfs.ext4 -F /dev/md126
```

Если здесь снова появится I/O error - проблема в виртуальном диске и чинить нужно storage на гипервизоре.

Но благо… в моём случае ошибок не было.

### Получить новый UUID

```bash
blkid /dev/md126
```

И теперь его надо добавить в `/etc/fstab` и раскомментировать строчки:

```bash
UUID=<новый UUID> /mnt/logs ...
/mnt/logs/system /var/log ...
/mnt/logs/core ...
/mnt/logs/coredump ...
```

### Перезагрузка

```bash
reboot
```

Если система стартует - проверяем:

```bash
df -h mount | grep logs
```

И убеждаемся, что:

* `/mnt/logs` смонтирован
* `/var/log` - bind с него
* логи создаются корректно


---

# Итоги

В моем случае все успешно завелось

Пхпхпп… буквально на протяжении всего анализа… я ощущал себя примерно так:

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/b8b229e6-7237-436f-80b9-88c7903cf269/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=7a3770a03fcece52c71eecd6d2cbac3ac5bddc674eaf46e7bbb877ffcf5bf582&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =781x712")

Хватался буквально за все… и был железно уверен, что виноват ОН, а он оказался **НИ ПРИ ЧЕМ**…

Проблема выглядела как классический fstab issue.

На деле - это был I/O error уровня виртуального диска после некорректной миграции… хоть где-то знания полученные с сертификации RHCSA по RAID массивам… пригодились на практике, как я долго этого ждал.