mdadm & raid6: does "re-create(with different chunk size) + resync" destroy orig. data?

Я хотел бы спасти данные на моем программном массиве raid-6. Я сделал несколько глупых действий (описанных ниже) с этим оригинальным массивом.

Главный вопрос:

Мне нужно знать, действительно ли исходные данные, хранящиеся в массиве raid-6, потеряны (или нет) после того, как следующие действия были подготовлены для этого массива (выполняются в порядке, указанном ниже):

  1. обнуление суперблоков всех активных дисков / разделов, зарегистрированных в массиве

  2. Выполнение команды "mdadm --create ..." с использованием других параметров (см. список ниже), которые использовались при первоначальном создании массива: -> другой размер чанка -> другой макет -> другой порядок дисков

  3. повторная синхронизация массива

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

Я думаю, что пункты 1) и 2) не должны даже касаться исходных данных, поскольку они должны манипулировать только суперблоками

Я считаю точку 3) наиболее важной с точки зрения потери данных: я не уверен, что именно происходит с массивом во время повторной синхронизации, но на основании высокой активности всех задействованных жестких дисков (в течение ~7 часов) я предполагаю, что данные Складское помещение полностью переработано...

Суб-вопросы:

  1. Играет ли порядок жестких дисков / разделов (как они упорядочены в командной строке mdadm) роль для создания raid6 и первоначальной повторной синхронизации?

  2. Что необходимо сделать для резервного копирования после создания массива, чтобы можно было безопасно воссоздать массив в аналогичной ситуации, как у меня (например, информация о суперблоках резервного копирования и информация таблицы разделов для каждого диска, включенного в массив...)?

Комментарий:

Вики-статья mdadm ( http://en.wikipedia.org/wiki/Mdadm) должна быть пересмотрена, и автора следует подтолкнуть к заднице немного, или даже чуть больше...
В статье упоминается обнуление суперблоков и последующее воссоздание массива в качестве решения для устранения проблемы "mdadm: Cannot open ...: Device or resource busy".
Автор почему-то забыл упомянуть важный шаг - сделать резервную копию параметров исходного массива (суперблоков) в качестве первого шага... а также мое исследование, похоже, указывает на то, что упорядочение задействованных дисков / разделов также играет роль...

Спасибо за ответы,
Питер

Источник

3 ответа

Я посмотрел статью в Википедии, и немного о том, как удалить суперблок и т. Д., Верно, но он должен использоваться для решения проблемы, отличной от той, которую вы пытались решить. Цель этой статьи - "очистить" диск со старыми настройками RAID, чтобы вы могли использовать его в новом массиве.

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

Источник

Запутанная часть:

создать, а затем повторно в течение 7 часов.

Когда создается массив, файловая система обычно создается сверху и повторной синхронизации не происходит. Обнуление суперблоков затрудняет определение набора рейдов, в каком порядке дисководы, когда raidset пытается собрать себя автоматически. Что вы сделали с созданием? создать его с двумя дисками, пропав без вести 2, затем увеличить его и добавить остальные? или вы создали его как набор raid-6 и добавили все диски одновременно.

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

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

Одна вещь, которую я нахожу очень любопытной, - это повторная синхронизация. Raid-6 может принять два отказа диска и все еще иметь возможность восстановления. Но некоторые вещи, которые вы сделали, почти заставили меня думать, что вы находитесь в ситуации, которая будет почти неустранимой, кроме экспертов.

Источник

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

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

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

редактировать
К счастью, поскольку перестройка данных о четности должна влиять ТОЛЬКО на данные о четности, теоретически у вас может остаться только достаточно информации, чтобы не тронуть исходный контент, при условии, что вы начали с чистого и исправного массива до того, как произошел этот беспорядок.

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

Тем не менее, он почти наверняка не выживет, если будет делать подобные вещи дважды.

Источник
Другие вопросы по тегам