RAID0 восстановление данных и проверка стратегии восстановления

у меня есть расширение Synology (DX213), подключенное к сетевому накопителю. В нем находятся 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 раздела 4GB на USB-ключе, создал массив RAID0 с ними, создал файловую систему EXT4 на массив, смонтировал его и скопировал на него несколько файлов. Вопрос в том, как я могу манипулировать суперблоком одного из разделов, чтобы воссоздать ситуацию, которую я имею с массивом 4TB.

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

7
задан mstaessen
18.04.2023 12:13 Количество просмотров материала 2679
Распечатать страницу

2 ответа

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

удалить диск из массива с

mdadm --manage --set-faulty

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

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

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

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

0
отвечен Overmind 2023-04-19 20:01

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

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

решение: сделать матч superblocks снова.

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

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

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

вторая идея. Манипулировать себя суперблоков, используя HEX-редактор.

плюсы:

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

задачи:

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

как оказалось, эти проблемы довольно легко преодолеть. На Linux-raid wiki есть отличная страница: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К каждый диск. Таким образом я всегда могу вернуться в исходное состояние.

    ДД, если=/dev/sdXY из=sdXY.резервное копирование bs=1 count=8K

  2. извлечь суперблоки каждого диска. Это легко сделать

    ДД, если=/dev/sdXY из=sdXY.суперблок bs=1 количество = 4K пропуск=4K

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

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

  5. записать суперблок в диск.

    dd if=sdXY.суперблок= / dev / sdXY bs=1 count=4K seek=4K

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

  7. измените контрольную сумму на правильную. В шестнадцатеричном редакторе байты инвертируются, поэтому " 99 7F A4 1Abecomes1А А4 7Ф 99` в HEX-редактор.

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

  9. повторить для каждого диска.

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

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

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

0
отвечен mstaessen 2023-04-19 22:18

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх