У меня есть расширение Synology (DX213), подключенное к моему NAS. Он содержит 2 диска по 2 ТБ, и они находятся в конфигурации RAID0 (ужасная идея, я знаю, и мне не нужно напоминание;)). В прошлые выходные массив вышел из строя, и я больше не могу запускать массив RAID.

Я начинаю полагать, что проблема возникла на задней панели (DX213), а не на дисках, потому что они выглядят хорошо. Они точно не мертвы (пока). Я подключил их к машине Linux, и я вижу их очень хорошо:

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000396746752 bytes, 3907024896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000a85dd

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sdb1           256    4980735    4980480  2.4G 83 Linux
/dev/sdb2       4980736    9175039    4194304    2G 82 Linux swap / Solaris
/dev/sdb3       9437184 3907024064 3897586881  1.8T 83 Linux

$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 1.8 TiB, 2000396746752 bytes, 3907024896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004dd4e

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sdc1           256    4980735    4980480  2.4G 83 Linux
/dev/sdc2       4980736    9175039    4194304    2G 82 Linux swap / Solaris
/dev/sdc3       9437184 3907024064 3897586881  1.8T 83 Linux

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

$ sudo mdadm --examine /dev/sd[bc]3 
/dev/sdb3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 1d7dd58f:dd7dd3d2:b646173b:afd51417
           Name : mist-nas:2
  Creation Time : Tue Nov 26 19:47:24 2013
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 3897584833 (1858.51 GiB 1995.56 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : 46933df7:36901a5b:7a1239fe:e999c419

    Update Time : Sat Aug 27 20:14:12 2016
       Checksum : 42117b5b - correct
         Events : 8

     Chunk Size : 64K

   Device Role : Active device 0
   Array State : A. ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 1d7dd58f:dd7dd3d2:b646173b:afd51417
           Name : mist-nas:2
  Creation Time : Tue Nov 26 19:47:24 2013
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 3897584833 (1858.51 GiB 1995.56 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : e4b60f4c:604b2e27:359cb71b:24453937

    Update Time : Tue Nov 26 19:47:24 2013
       Checksum : 997fa41a - correct
         Events : 4

     Chunk Size : 64K

   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

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

Я клонировал оба диска с dd на новые диски, чтобы создать резервную копию на случай, если я сделаю что-нибудь глупое. Новые диски имеют размер сектора 4096 (это диски объемом 3 и 4 ТБ), тогда как старые диски имеют размер сектора 512. Размер раздела sd [bc] 3 не кратен 4096 секторам, поэтому мне пришлось округлить размер раздела до следующего сектора. Я надеюсь, что это не проблема?

Команда, которую я собираюсь запустить:

$ sudo mdadm --create --readonly --assume-clean --level=0 -n2 /dev/md2 /dev/sdb3 /dev/sdc3

Эта команда, вероятно, перезапишет текущие суперблоки, поэтому я хочу быть абсолютно уверенным, что это не разрушит мои шансы вернуть мои данные. Что будет результатом этой команды?

Я также хотел бы проверить свою стратегию, прежде чем действовать. Я создал 2 раздела по 4 ГБ на USB-ключе, создал с ними массив RAID0, создал файловую систему EXT4 в массиве, смонтировал его и скопировал на него некоторые файлы. Вопрос в том, как я могу манипулировать суперблоком одного из разделов, чтобы воссоздать ситуацию, сложившуюся у меня с массивом 4 ТБ.

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

|источник

2 ответа2

0

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

Так что мой массив RAID0 сломан из-за несоответствующих суперблоков. Поскольку в RAID0 нет избыточности, mdadm не может запустить массив RAID0, если не совпадают все суперблоки. Мои диски выглядели нормально, но суперблоки были не синхронизированы.

Решение: снова сопоставить суперблоки.

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

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

Вывод: плохая идея.

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

Плюсы:

  • Я контролирую, если я не сделаю глупую ошибку, никакие изменения не будут внесены в байты, которые не имеют значения.
  • Будут изменены только несовпадающие значения суперблока, поэтому компоновка массива не будет затронута.

проблемы:

  • Где суперблок записан на диске?
  • Как это выглядит?
  • Могу ли я определить правильные байты и восстановить вывод mdadm --examine из чтения шестнадцатеричных значений?
  • Изменение атрибутов сделает недействительной контрольную сумму суперблока. Как получить действительную контрольную сумму?

Как оказалось, эти проблемы довольно легко преодолимы. В вики linux-raid есть отличная страница: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats. Он документирует суперблок v1 и где его найти на диске. Для суперблока v1.2 он расположен в 4 КБ от начала диска и записывается в следующих 4 КБ (потому что он выровнен по секторам, а новые диски используют 4 КБ, хотя диск, на котором он используется, имел 512-байтовые сектора),

Вы также можете обратиться к исходному коду суперблока v1, который не слишком сложен для чтения: https://github.com/neilbrown/mdadm/blob/master/super1.c

После тщательного анализа я остановился на этом плане:

  1. Сначала сделайте резервную копию первых 8 КБ каждого диска. Таким образом, я всегда могу вернуться к исходному состоянию.

    dd if =/dev/sdXY of = sdXY.backup bs = 1 счет = 8K

  2. Распакуйте суперблоки каждого диска. Это легко сделать

    дд если =/dev/sdXY из = sdXY.superblock bs = 1 счет = 4K пропустить = 4K

  3. Читайте в суперблоке в шестнадцатеричном редакторе. Я нашел веб-сайт http://hexed.it очень хорошим.

  4. Измените необходимые атрибуты, оставьте контрольную сумму как есть. Будьте осторожны при изменении меток времени. Временная метка Linux занимает 32 бита или 4 байта, в mdadm временная метка занимает 64 бита или 8 байтов. Не забудьте скопировать остальные 4. Суперблок составляет 256 байтов + 2 байта для каждого члена массива. Эти последние байты являются последовательностью идентификаторов членов или ролей.

  5. Запишите суперблок на диск.

    dd if = sdXY.superblock of =/dev/sdXY bs = 1 счет = 4K искать = 4K

  6. Изучите суперблок с помощью mdadm --examine /dev/sdXY . Он покажет вам, что контрольная сумма недействительна, но также покажет вам ожидаемую контрольную сумму.

  7. Измените контрольную сумму на правильную. В шестнадцатеричном редакторе байты инвертируются, поэтому `` 99 7F A4 1A becomes 1A A4 7F 99` в шестнадцатеричном редакторе.

  8. Запишите новый суперблок на диск той же командой, что и в шаге 5.

  9. Повторите для каждого диска.

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

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

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

|источник
0

Вы должны удалить диск из массива, удалить его из системы, повторно найти диски, а затем снова добавить диск обратно в массив.

Удалите неисправный диск из массива с помощью 

mdadm --manage --set-faulty

Извлеките и снова вставьте диск из / в систему физически (или с помощью удаления устройства и сканирования scsi host).

Теперь проверьте, найден ли диск снова, и проверьте, работает ли он правильно. Вы можете увидеть вывод dmesg или посмотреть /proc /partitions. Запустите pv < на устройстве.

Затем повторно добавьте диск в массив с помощью mdadm .

Затем выполните последнюю проверку с помощью команды cat /proc/mdstat чтобы убедиться, что вам это удалось.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .