mdadm raid5 восстанавливает двойной сбой диска - с поворотом (порядок дисков)


14

Позвольте мне прежде всего подтвердить, что я допустил ошибки и что у меня есть резервная копия для большинства, но не для всех данных на этом RAID. У меня все еще есть надежда на восстановление остальных данных. У меня нет денег, чтобы отвезти диски в экспертную компанию по восстановлению.

Ошибка № 0, без 100% резервной копии. Я знаю.

У меня есть система mdadmRAID5 4x3TB. Диски / dev / sd [be], все с одним разделом /dev/sd[b-e]1. Я знаю, что RAID5 на очень больших дисках опасен, но я все равно это сделал.

Недавние события

RAID становится ухудшенным после отказа двух дисков. Один диск [/ dev / sdc] действительно пропал, другой [/ dev / sde] вернулся после цикла питания, но не был автоматически повторно добавлен в RAID. Поэтому у меня остался RAID-массив с 4 устройствами и только 2 активными дисками [/ dev / sdb и / dev / sdd].

Ошибка № 1, не использовать копии дисков для восстановления RAID. У меня не было дисков или времени. Ошибка № 2, а не создание резервной копии суперблока и mdadm -Eоставшихся дисков.

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

Я собрал RAID в ухудшенном режиме с

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Я мог тогда получить доступ к своим данным. Я заменил /dev/sdcна запасной; опорожнить; идентичный диск.

Я удалил старый /dev/sdc1из RAID

mdadm --fail /dev/md0 /dev/sdc1

Ошибка № 3, не делайте этого до замены диска

Затем я разделил новый /dev/sdcи добавил его в RAID.

mdadm --add /dev/md0 /dev/sdc1

Затем он начал восстанавливать RAID. ЭТА 300 мин. Я проследил за процессом /proc/mdstatдо 2%, а затем пошел заниматься другими делами.

Проверка результата

Через несколько часов (но менее 300 минут) я проверил процесс. Он остановился из-за ошибки чтения /dev/sde1.

Вот где действительно начинается проблема

Я тогда удалил /dev/sde1из RAID и повторно добавил это. Я не могу вспомнить, почему я это сделал; было поздно.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Однако /dev/sde1теперь был помечен как запасной. Поэтому я решил воссоздать весь массив, используя --assume-clean, используя то, что я считал правильным порядком, и /dev/sdc1отсутствующим.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Это сработало, но файловая система не была распознана при попытке монтирования. (Это должен был быть EXT4).

Порядок устройства

Затем я проверил недавнюю резервную копию /proc/mdstatи обнаружил порядок дисков.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Затем я вспомнил, что этот RAID потерял накопитель около года назад, и восстановился после замены неисправного накопителя на запасной. Это могло немного изменить порядок устройств ... поэтому не было диска [3], а были только [0], [1], [2] и [4].

Я попытался найти порядок дисков с помощью скрипта Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl, но это не нашло правильный порядок.

Вопросов

Теперь у меня есть два основных вопроса:

  1. Я облажался все суперблоки на дисках, но только дал:

    mdadm --create --assume-clean
    

    команды (поэтому я не должен был перезаписывать сами данные /dev/sd[bde]1. Прав ли я в том, что теоретически RAID можно восстановить (если на мгновение все /dev/sde1будет в порядке), если я просто найду правильный порядок устройств?

  2. Важно ли /dev/sde1указывать номер устройства [4] в RAID? Когда я создаю это с

    mdadm --create /dev/md0 --assume-clean -l5 -n4 \
      /dev/sdb1 missing /dev/sdd1 /dev/sde1
    

    ему присваивается номер [3]. Интересно, имеет ли это отношение к вычислению блоков четности. Если это окажется важным, как я могу воссоздать массив с /dev/sdb1[0]отсутствующим [1] /dev/sdd1[2] /dev/sde1[4]? Если бы я мог заставить это работать, я мог бы запустить это в ухудшенном режиме и добавить новый диск /dev/sdc1и позволить ему повторно синхронизироваться снова.

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


1
+1 Это очень хорошо продуманный и задокументированный вопрос. Хотел бы я иметь ответ для вас.
Грант

Спасибо за ваш комментарий, я думаю, это сложный вопрос.
Питер Бос

Вы отказались от этого или продолжаете работать над этим? Если вы работаете над этим, мой совет, соберите все диски, которые у вас лежат, и создайте JBOD на другой машине, для которой вы можете создавать образы DD, лучше справиться с этим таким образом, так как вы можете продолжать пытаться снова и снова , (Используйте LVM, а затем используйте снимки, как только он будет завершен, так что вы можете продолжать удалять снимок, и вам не придется повторно копировать все это). Я был в аналогичной лодке, и мне удалось восстановить массив, сохранив большую часть данных.
Regan

Спасибо за вашу реакцию. Через некоторое время я отказался от этого, заменил два диска на новые, восстановил 98% из резервной копии, принял потерю данных 2% и пошел дальше. Сейчас я использую RAID-Z и обновил свою стратегию резервного копирования. Все идет нормально.
Питер Бос

Ответы:


3

Чтобы ответить на ваши вопросы,

  1. Можно ли его восстановить?

    • Перво-наперво - СТОП, откиньтесь на спинку кресла и просто немного подумайте. Да, алгоритм, размер чанка и порядок дисков жизненно важны для правильной повторной сборки любой файловой системы, которая присутствовала. Но поскольку вы перезаписали суперблоки, теперь у вас остались проб и ошибок.
    • Во-вторых, есть ли способ восстановить прежнюю разметку диска? Я всегда делаю mdadm --detail> backupfile, чтобы сохранить расположение диска где-нибудь в безопасности. Проверьте dmesg, / var / log на наличие доказательств того, как диски были настроены в рейде.
    • Наконец, если вы соответствуете предыдущему размеру чанка и порядку дисков, возможно, вы повредили суперблок ext4 - есть способы быстрого сканирования других суперблоков (и есть отличная программа под названием TestDisk, которая сканирует суперблоки существующих файловых систем и пытается просмотреть их вручную: http://www.cgsecurity.org/wiki/Main_Page )
  2. Так как sdc является новым, я бы продолжал пытаться собирать вручную через отсутствующее предложение, и да, sde должен быть в правильном порядке для его сборки в ухудшенном режиме. Как только вы найдете правильный макет - скопируйте все данные из массива и начните заново, документируя макет (чтобы вы больше не сталкивались с этой проблемой).

Удачи


1
ext3 / 4 записывает избыточные суперблоки. Вы можете передать смещение суперблока в качестве аргумента для монтирования или fsck, чтобы вместо него использовать резервные суперблоки. Тем не менее, два диска в RAID 5 = игра окончена.
Дмурати

1

Прежде чем делать НИЧЕГО, запишите 'mdadm --examine / dev / sdX1' для каждого из дисков, которые были в вашем массиве, и 'mdadm --detail / dev / md0' из этого, вы сможете определить Точная планировка.

Я просто должен был сделать это сам, чтобы восстановить массив Synology в отдельном вопросе:

Как восстановить массив mdadm на Synology NAS с диском в состоянии «E»?

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

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


1

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

Самая опасная ошибка, которую вы совершили, - это не та, которую вы пронумеровали.

mdadm --create ...

на оригинальные диски, прежде чем вы были готовы, зная, что делать. Это перезаписало метаданные, поэтому у вас нет записи о порядке дисков, смещении данных, размере чанка и т. Д.

Чтобы восстановиться после этого, вам нужно снова перезаписать их правильными значениями. Самый простой способ узнать это - посмотреть на метаданные, но вы их уже уничтожили. Следующий способ - угадать. Угадайте по различным комбинациям команды, подобной этой, с разными значениями для любого из параметров, кроме того, что вы знаете (4 устройства, уровень 5), а также с другим порядком диска:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

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

Как только вы нашли аргументы, которые создают рабочий массив, который вы можете fsck или смонтировать и проверить (например, проверьте контрольную сумму файла, достаточно большого, чтобы охватить все элементы raid, например iso, который вы должны были сохранить с его контрольной суммой / pgp подпись, или распаковать -t или gunzip -та большой архив)


Спасибо. Тем временем я перешел к использованию ZFS (RAIDZ2). Однако было очень интересно читать ваши заметки. Теперь я понимаю , что создать команду сделал перезапись метаданные, в то время как в то время я предположил , что это не так. Также я не знал о оверлейных файлах. Это действительно здорово! Благодарность!
Питер Бос
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.