Песочница →
Программный RAID-6 под Linux: опыт восстановления массива 16Тб
Несколько дней назад вышел из строя один из жестких дисков на бюджетном массиве из 16х1ТБ дисков. Уровень массива: RAID 6. Ситуация осложнилась тем, что (как оказалось) ранее также встал кулер на видеокарте этого же сервера, что не было заранее подмечено, и после замены HDD, в результате изменения режима охлаждения корпуса — это стало проявляться в виде зависаний во время синхронизации, что само по себе очень неприятно. Вылилось это в то, что массив перестал автособираться, и были помечены как сбойные еще несколько дисков, и пришлось уже разбираться с ним по-серьёзному, курить вики, мануалы и форумы (форумы — самое полезное, поскольку описывают опыт конкретных людей в конкретных ситуациях).
Структура моего массива:
16х1Тб HDD
разделы:
md0 — /root 8х1 Гб, RAID 6
md1 — /data: 16х999Гб, RAID 6
Сначала все эксперименты по сборке ставились на md0, т. е. на рутовой партиции, которая сама по себе большой ценностью не обладает, разве что тот факт что это настроенная система.
Итак я загрузился с 1-го диска Дебиан в режиме «Resque mode»
Попытка автосборки массива через
привела к выводу ошибки «недостаточно дисков для сборки массива».
Продолжаем по науке:
1. Необходимо сохранить информацию описания для массивов, которые содержат иформацию, какой конкретно диск является каким номером в массиве. На случай если придется собирать «опасными методами»:
Данные фалы содержат что-то похожее на приведенное ниже для всех HDD, у которых на партиции sdX1 есть суперблок (в моем случае только 8 из 16 для md0 имеют суперблок на sdX1)
Ниже пример вывода одного из разделов:
Кратко о том, что это означает:
sdf2 — текущая анализируемая партиция
Version 0.90.00 — Версия суперблока
Также вы увидите кучу полезной информации — размер массива, UUID, Level, Размер массива, Кол-во устройств и т. д.
Но самое важное для нас сейчас — это таблица внизу списка, первая строчка в ней, указывает, каким по счету HDD в массиве является наш экзаменуемый:
Также обратите пристальное внимание на версию суперблока! В моем случае это 0.90.00.
Тут мы видим его номер в массиве, т. е. 4 — такие же номера вы найдете в выводе для всех других устройств из списка. Обратите внимание, что буковка диска в строчке статуса другая — sdl1 — это означает, что диск был проинициализирован на другом SATA порту, затем перемещен. Это некритичная информация, но может быть полезной.
Критичным является название устройства и его номер в массиве (они поменяются при переносе устройств с порта на порт).
Сохраняем созданный файл raid_layout (например на флешке), чтобы не потерялся, и приступаем к следующему шагу:
2. Пытаемся собрать массив
Собрать массив можно 2мя способами: автоматический и ручной.
Автоматический:
Если автоматически он собрался, считайте вам повезло, надо просто проверить все ли HDD в массиве, и если нет, добавить недостающие, и дальше можно не читать. Но, в моем случае, автоматическая сборка не проходит с ошибкой, что недостаточно работающих устройств:
и массив был создан на 4 из 8 дисков. Работать конечно не будет, поскольку Raid6 позволяет отсутствовать только 2-м дискам.
Проверяем статус массива
Тут есть тонкость — если в списке HDD встречается не проинициализированный или помеченный как сбойный, то сборка немедленно прекращается, поэтому полезен флаг «-v» — чтобы увидеть на каком из HDD сборка встала.
Ручная сборка:
Тоже самое, но мы указали конкретно, какие HDD использовать для сборки.
Скорее всего массив не соберется также, как и в случае с автоматической сборкой. Но, собирая вручную, вы начинаете лучше понимать саму суть происходящего.
Массив также не соберется, если в метаданных раздела, диск помечен как «faulty».
Тут я перескакивая на то, как я запустил массив с данными, поскольку /root массив я потерял, почему и как — рассказано ниже. Собрать массив игнорируя статус «faulty» — можно добавив флаг «-f» (force) — в моем случае это решило проблему сборки основного раздела с данными т. е. раздел был успешно пересобран следующей командой:
наверняка, простой способ собрать его был бы следующим:
Но, поскольку я добрался до флага "-f" через тернии, это сейчас понятно.
Т. е. разделы, помеченные как сбойные, или устаревшие были добавлены в массив, а не проигнорированы. С большой вероятностью, сбойным или устаревшим раздел может быть помечен при плохо, или не плотно сидящем SATA кабеле, что является не редкостью.
Тем не менее, у меня получился массив в режиме degraded, на 14 дисков из 16.
Теперь, чтобы восстановить нормальную работоспособность массива и не бояться за него, нужно добавить в него 2 недостающих диска:
где Х буковка раздела нового HDD
Ниже я приведу сложности с которыми я столкнулся, дабы уберечь других, от наступания на мои грабли:
Я использовал рекомендации WIKI — Linux RAID Recovery ( raid.wiki.kernel.org/index.php/RAID_Recovery ) по работе с массивом с Linux RAID WIKI — Советую быть с ними осторожными, поскольку страничка очень кратко описывает процесс, и благодаря этим рекомендациям, я разрушил /root (md0) моего массива.
До данной строчки в самом низу статьи WIKI, все очень полезно:
Данная строчка демонстрирует как пересоздать массив, зная какие устройства в каком порядке в него входят. Тут очень важно учесть версию своего суперблока, поскольку новые mdadm создают суперблок 1.2 и он располагается в начале раздела, 0.90 же располагается в конце. Поэтому нужно добавить флаг "--metadata=0.90".
После того, как я собрал массив используя «--create», файловая система оказалась разрушенной, и ни основной суперблок ext4, ни резервные не нашлись. Сначала я обнаружил, что новый суперблок не 0.90 а 1.2, что могло являться причиной уничтожения раздела, но, похоже, не являлось, поскольку изменение версии RAID суперблока на 0.90 и поиск backup суперблока ext4 — был неудачен.
Поскольку /root партиция — это не самая важная часть, тут я решил поэкспериментировать — массив был переформатирован и после этого остановлен:
mdadm —stop /dev/md2
и тотчас создан ещё раз через «--create»: результат — файловая система разрушена опять, хотя этого случиться не должно было, я уверен, что не перепутал порядок устройств и первый раз, и тем более 2-й.
Возможно кто-то успешно восстанавливал разделы, через "--create", буду рад добавить в данную статью, что конкретно мною было сделано неправильно, и почему разрушалась FS. Возможно, она была собрана еще и с другими параметрами размера блока (chunk size).
Очевидно что какими либо рекомендациями из данной статьи следует пользоваться на свой страх и риск, никто не гарантирует что в Вашем случае все сработает именно так как в моём.
Структура моего массива:
16х1Тб HDD
разделы:
md0 — /root 8х1 Гб, RAID 6
md1 — /data: 16х999Гб, RAID 6
Сначала все эксперименты по сборке ставились на md0, т. е. на рутовой партиции, которая сама по себе большой ценностью не обладает, разве что тот факт что это настроенная система.
Итак я загрузился с 1-го диска Дебиан в режиме «Resque mode»
Попытка автосборки массива через
mdadm --assemble --scan
привела к выводу ошибки «недостаточно дисков для сборки массива».
Продолжаем по науке:
1. Необходимо сохранить информацию описания для массивов, которые содержат иформацию, какой конкретно диск является каким номером в массиве. На случай если придется собирать «опасными методами»:
mdadm --examine /dev/sd[abcdefghijklmnop]1 > /mnt/raid_layout1 mdadm --examine /dev/sd[abcdefghijklmnop]2 > /mnt/raid_layout2
Данные фалы содержат что-то похожее на приведенное ниже для всех HDD, у которых на партиции sdX1 есть суперблок (в моем случае только 8 из 16 для md0 имеют суперблок на sdX1)
Ниже пример вывода одного из разделов:
/dev/sdp1:
Version : 0.90.00
Raid Level : raid6
Used Dev Size : 975360 (952.66 MiB 998.77 MB)
Raid Devices : 8
Total Devices : 8
Number Major Minor RaidDevice State
this 4 8 177 4 active sync /dev/sdl1
0 0 8 97 0 active sync /dev/sdg1
1 1 8 113 1 active sync /dev/sdh1
2 2 8 129 2 active sync /dev/sdi1
3 3 8 145 3 active sync /dev/sdj1
4 4 8 177 4 active sync /dev/sdl1
5 5 8 193 5 active sync /dev/sdm1
6 6 8 209 6 active sync /dev/sdn1
7 7 8 225 7 active sync /dev/sdo1
Кратко о том, что это означает:
sdf2 — текущая анализируемая партиция
Version 0.90.00 — Версия суперблока
Также вы увидите кучу полезной информации — размер массива, UUID, Level, Размер массива, Кол-во устройств и т. д.
Но самое важное для нас сейчас — это таблица внизу списка, первая строчка в ней, указывает, каким по счету HDD в массиве является наш экзаменуемый:
this 4 8 177 4 active sync /dev/sdl1
Также обратите пристальное внимание на версию суперблока! В моем случае это 0.90.00.
Тут мы видим его номер в массиве, т. е. 4 — такие же номера вы найдете в выводе для всех других устройств из списка. Обратите внимание, что буковка диска в строчке статуса другая — sdl1 — это означает, что диск был проинициализирован на другом SATA порту, затем перемещен. Это некритичная информация, но может быть полезной.
Критичным является название устройства и его номер в массиве (они поменяются при переносе устройств с порта на порт).
Сохраняем созданный файл raid_layout (например на флешке), чтобы не потерялся, и приступаем к следующему шагу:
2. Пытаемся собрать массив
Собрать массив можно 2мя способами: автоматический и ручной.
Автоматический:
mdadm --assemble --scan -v
Если автоматически он собрался, считайте вам повезло, надо просто проверить все ли HDD в массиве, и если нет, добавить недостающие, и дальше можно не читать. Но, в моем случае, автоматическая сборка не проходит с ошибкой, что недостаточно работающих устройств:
mdadm: /dev/md2 assembled from 4 drives - not enough to start the array.
и массив был создан на 4 из 8 дисков. Работать конечно не будет, поскольку Raid6 позволяет отсутствовать только 2-м дискам.
Проверяем статус массива
cat /proc/mdstat
md2 : inactive sdn1[3](S) sdk1[7](S) sdj1[6](S) sdp1[4](S)
3907264 blocks
Тут есть тонкость — если в списке HDD встречается не проинициализированный или помеченный как сбойный, то сборка немедленно прекращается, поэтому полезен флаг «-v» — чтобы увидеть на каком из HDD сборка встала.
Ручная сборка:
mdadm --assemble /dev/sd[abcdefgh]1 -v
Тоже самое, но мы указали конкретно, какие HDD использовать для сборки.
Скорее всего массив не соберется также, как и в случае с автоматической сборкой. Но, собирая вручную, вы начинаете лучше понимать саму суть происходящего.
Массив также не соберется, если в метаданных раздела, диск помечен как «faulty».
Тут я перескакивая на то, как я запустил массив с данными, поскольку /root массив я потерял, почему и как — рассказано ниже. Собрать массив игнорируя статус «faulty» — можно добавив флаг «-f» (force) — в моем случае это решило проблему сборки основного раздела с данными т. е. раздел был успешно пересобран следующей командой:
mdadm --assemble /dev/md3 /dev/sd[abcdefghijklmnop]2 -f
наверняка, простой способ собрать его был бы следующим:
mdadm —assemble —scan -f -v
Но, поскольку я добрался до флага "-f" через тернии, это сейчас понятно.
Т. е. разделы, помеченные как сбойные, или устаревшие были добавлены в массив, а не проигнорированы. С большой вероятностью, сбойным или устаревшим раздел может быть помечен при плохо, или не плотно сидящем SATA кабеле, что является не редкостью.
Тем не менее, у меня получился массив в режиме degraded, на 14 дисков из 16.
Теперь, чтобы восстановить нормальную работоспособность массива и не бояться за него, нужно добавить в него 2 недостающих диска:
mdadm --add /dev/md3 /dev/sdX2
где Х буковка раздела нового HDD
Ниже я приведу сложности с которыми я столкнулся, дабы уберечь других, от наступания на мои грабли:
Я использовал рекомендации WIKI — Linux RAID Recovery ( raid.wiki.kernel.org/index.php/RAID_Recovery ) по работе с массивом с Linux RAID WIKI — Советую быть с ними осторожными, поскольку страничка очень кратко описывает процесс, и благодаря этим рекомендациям, я разрушил /root (md0) моего массива.
До данной строчки в самом низу статьи WIKI, все очень полезно:
mdadm --create --assume-clean --level=6 --raid-devices=10 /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 missing missing /dev/sdl1 /dev/sdk1 /dev/sdj1
Данная строчка демонстрирует как пересоздать массив, зная какие устройства в каком порядке в него входят. Тут очень важно учесть версию своего суперблока, поскольку новые mdadm создают суперблок 1.2 и он располагается в начале раздела, 0.90 же располагается в конце. Поэтому нужно добавить флаг "--metadata=0.90".
После того, как я собрал массив используя «--create», файловая система оказалась разрушенной, и ни основной суперблок ext4, ни резервные не нашлись. Сначала я обнаружил, что новый суперблок не 0.90 а 1.2, что могло являться причиной уничтожения раздела, но, похоже, не являлось, поскольку изменение версии RAID суперблока на 0.90 и поиск backup суперблока ext4 — был неудачен.
Поскольку /root партиция — это не самая важная часть, тут я решил поэкспериментировать — массив был переформатирован и после этого остановлен:
mdadm —stop /dev/md2
и тотчас создан ещё раз через «--create»: результат — файловая система разрушена опять, хотя этого случиться не должно было, я уверен, что не перепутал порядок устройств и первый раз, и тем более 2-й.
Возможно кто-то успешно восстанавливал разделы, через "--create", буду рад добавить в данную статью, что конкретно мною было сделано неправильно, и почему разрушалась FS. Возможно, она была собрана еще и с другими параметрами размера блока (chunk size).
Очевидно что какими либо рекомендациями из данной статьи следует пользоваться на свой страх и риск, никто не гарантирует что в Вашем случае все сработает именно так как в моём.
07.08.2011 00:11+0400