Восстановление raid

Если это именно диски от RAID и на них тем более есть файловая система новая - выключайте ПК, отключайте диски и в сервис по восстановлению данных с денюжкой.

hdd диски с linux soft raid

Soft RAID каким образом организован? mdadm, zfs, btrfs, lvm?

А что должно быть на дисках? RAID суперблок был на голом диске (sda) или на разделе (sda1)? Что говорят mdadm --examine /dev/sda, mdadm --examine /dev/sda1, mdadm --examine /dev/sdb, mdadm --examine /dev/sdb1.

vitus@vitus-home:~$ sudo mdadm --examine /dev/sda
/dev/sda:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 0c09f93f:4a6ed2de:cdd51d04:aa80e098
           Name : vitus-home:1  (local to host vitus-home)
  Creation Time : Wed Jan 15 20:30:32 2025
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 23437506560 sectors (10.91 TiB 12.00 TB)
     Array Size : 11718753280 KiB (10.91 TiB 12.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : clean
    Device UUID : 40911201:ef6aded7:1b9c5013:6971915a

Internal Bitmap : 8 sectors from superblock
    Update Time : Thu Oct 30 10:57:02 2025
  Bad Block Log : 512 entries available at offset 56 sectors
       Checksum : 7c71edd7 - correct
         Events : 182049


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
vitus@vitus-home:~$ sudo mdadm --examine /dev/sda1
mdadm: cannot open /dev/sda1: No such file or directory

Диск b там вообще всё похерено

Никаких извратов обычный mdadm с ext4

Если просканировать, то

vitus@vitus-home:~$ sudo mdadm --examine --brief --scan --config=partitions
ARRAY /dev/md/1  metadata=1.2 UUID=0c09f93f:4a6ed2de:cdd51d04:aa80e098

такое. Что вроде как должно внушать надежду. Но как это всё восстановить не понятно.

Вообщем добился такого какого-то результата

vitus@vitus-home:~$ cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sda[1](S)
      11718753280 blocks super 1.2
       
unused devices: <none>
vitus@vitus-home:~$ 
vitus@vitus-home:~$ sudo mount /dev/md1 /mnt/vitus/disk
mount: /mnt/vitus/disk: can't read superblock on /dev/md1.
       dmesg(1) may have more information after failed mount system call.

Какие-нить идеи?

-o loop,offset=$((512*8)),ro /dev/sda

А можно полную команду. Я немного не просёк куда это вставить

если в лоб то

itus@vitus-home:~$ sudo mount -o loop,offset=$((512*8)),ro /dev/sda /mnt/vitus/disk
mount: /mnt/vitus/disk: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

Если затёрта первая копия суперблока ext4 - можно попробовать запустить mkfs.ext4 с параметрами по умолчанию на блочное устройство и ключом -n

       -n     Causes  mke2fs to not actually create a file system, but display what it would do if it were to create a file system.  This can be used to determine the location of the backup superblocks for a particular file system,
              so long as the mke2fs parameters that were passed when the file system was originally created are used again.  (With the -n option added, of course!)

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

К сожалению, что такое

Disk /dev/sda: 10,91 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: ST12000VE001-38N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xde49c90a

Device     Boot Start        End    Sectors Size Id Type
/dev/sda1           1 4294967295 4294967295   2T ee GPT

Partition 1 does not start on physical sector boundary.

vitus@vitus-home:~$ sudo mkfs.ext4 -n /dev/sda1
mke2fs 1.47.2 (1-Jan-2025)
The file /dev/sda1 does not exist and no size was specified.

У вас файловая система была просто на /dev/md1, зачем вы что-то пробуете делать с /dev/sda1?

sudo mount /dev/md1 /mnt/vitus/disk

А так, в выводе cat /proc/mdstat

vitus@vitus-home:~$ cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sda[1](S)
      11718753280 blocks super 1.2

У вас только один spare диск и RAID неактивен, не уверен, что данные вы так достанете.

Если очень нужно - соберите чётко картину на каких дисках он был /dev/sda1, /dev/sdb1, какой был размер чанка, какой версией утилиты mdadm он создавался. Далее делаете полную посекторную копию каждого диска или посредством утилиты md можете создать виртуальное блочное устройство с записью изменений в файл и пробуйте собрать RAID из тех дисков, что были.

Так же нужно знать с какого смещения начинаются данные, это значение может меняться в зависимости от версии утилиты mdadm которой создавался массив.

       --data-offset=
              Arrays with 1.x metadata can leave a gap between the start
              of the device and the start of array data.  This gap can be
              used for various metadata.  The start of data is known as
              the data-offset.  Normally an appropriate data offset is
              computed automatically.  However it can be useful to set it
              explicitly such as when re-creating an array which was
              originally created using a different version of mdadm which
              computed a different offset.

              Setting the offset explicitly over-rides the default.  The
              value given is in Kilobytes unless a suffix of 'K', 'M',
              'G' or 'T' is used to explicitly indicate Kilobytes,
              Megabytes, Gigabytes or Terabytes respectively.

              --data-offset can also be used with --grow for some RAID
              levels (initially on RAID10).  This allows the data-offset
              to be changed as part of the reshape process.  When the
              data offset is changed, no backup file is required as the
              difference in offsets is used to provide the same
              functionality.

              When the new offset is earlier than the old offset, the
              number of devices in the array cannot shrink.  When it is
              after the old offset, the number of devices in the array
              cannot increase.

              When creating an array, --data-offset can be specified as
              variable.  In the case each member device is expected to
              have an offset appended to the name, separated by a colon.
              This makes it possible to recreate exactly an array which
              has varying data offsets (as can happen when different
              versions of mdadm are used to add different devices).

Но все пробы форсированной сборки массива в ручную делайте на копии данных или используйте утилиту md для перенаправления записи.

Наверное надо выполнить последовательную сборку массива:

mdadm /dev/md0 --incremental --run /dev/sda

Должен получиться /dev/md0. А файловая система была создана прямо на RAID томе, или на RAID томе таблица разделов, а в разделе уже файловая система?

blkid /dev/md0 – посмотреть что там.

fdisk -l /dev/md0 посмотреть таблицу разделов.

dmesg(1) may have more information after failed mount system call.

Ты ж сделал как он советует? Почему не сделал то?

С массивом у тебя всё в порядке, просто он выключен т.к. нет второго диска. На sda1 не смотри, это GPT-заглушка чтобы старый софт не посчитал что диск пустой и не записал на него что-нить.

mdadm --run /dev/md1 должен его запустить, после этого монтируй

Не надо ничего собирать, массив md1 уже есть просто ждёт второй диск по дефолту.

Поставил диск с виндой, hdd диски с linux soft raid отключать не стал

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

Лана спасибо всем не равнодушным. Полночи мучился, но рейд взлететь отказался потому данные получены обходным путём - вернул из помойки поломанный m2, который грузиться уже не хотел, и не монтировался, но бекап с него получить ещё раз получилось с потерей кучи данных, но хомяк оказался цел, фоточки и часть документом были достаны с дисков «прошлых» рейдов.

Как всё таки в этих ваших виндовсах и линуксах и в железе всё через ж. Винда за каким-то хреном портит рейд, 1 тб от самсунга, это не 1 тб от других товарищей. Восстановление партиции на диск с меньшим размером до сих пор проблема. Развёрнутая из бекапа партиция монтируется, но груб с неё загружать систему отказывается. Установка debian с нуля всё такое же убожество - с зависаниями nouveau, чёрными экранами nvidia и т.д.

Не мудрено, что все человеки свалили на смартфоны и планшеты, где начал две кнопки и получил результат.

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

Лучше создавать RAID суперблок не на голом диске, а на разделе. Тогдя любая операционка увидит, что на диске уже есть таблица разделов, и не станет «инициализировать» диск и создавать свою таблицу разделов.

Дельно, спасибо, попробую поиграться с этим.

Дело не в спец-софте, дело в самой винде. Это большой троян от микрософта, который по командам с его серверов может делать на твоём компе то угодно. Допускать его к данным не следует, только в игры поиграть изолированно от всего остального.

Полночи мучился, но рейд взлететь отказался

Что mdadm --run /dev/md1 писал? Что в dmesg?

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

root@vitus-home:~# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md127 : inactive sda[1](S)
      11718753280 blocks super 1.2
root@vitus-home:~# mdadm --run /dev/md127
mdadm: started array /dev/md/vitus-home:1
root@vitus-home:~# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md127 : active (auto-read-only) raid1 sda[1]
      11718753280 blocks super 1.2 [2/1] [_U]
      bitmap: 0/88 pages [0KB], 65536KB chunk

unused devices: <none>

И он даже работает, но fdisk всё равно выдаёт про этот диск какую-то муру

vitus@vitus-home:/data/devel/build$ sudo fdisk -l /dev/sda
Disk /dev/sda: 10,91 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: ST12000VE001-38N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xde49c90a

Device     Boot Start        End    Sectors Size Id Type
/dev/sda1           1 4294967295 4294967295   2T ee GPT

Partition 1 does not start on physical sector boundary.

или fdisk-ом нельзя на файлухи в рейде смотреть ? Вроде всегда смотрел и такой картинки не видел.

Что ты надеешься увидеть fdisk-ом? Ты же таблицу разделов на диске не создавал, а создал на голом диске RAID суперблок. Конкретно сейчас fdisk показывает Protective MBR. Почему не показывает GPT таблицу – фиг знает. Наверное она повреждена. И это ожидаемо. Ведь RAID на голом диске и GPT таблица на голом диске. Запись в RAID суперблок ломает GPT таблицу, запись в GPT таблицу ломает RAID суперблок. Суперблок 1.2 находится по смещению 4 KiB от начала диска и занимает 4 KiB. GPT таблица находится по смещению 0.5 KiB от начала диска и занимает обычно 16.5 KiB. Плюс резервная копия GPT таблицы хранится в самом конце диска.

уже есть просто ждёт второй диск по дефолту.

Ну как бы не совсем. Если бы mdadm видел один живой диск, то и поднял бы массив как (U_). А не один spare. Там явно нужно было что-то делать.

А, это не знаю, я не приглядывался как оно выглядит до активации. Но после того как он --run сделал у него U_ и стало показываться.

Это потому, что совпала версия mdadm, это важно, offset начала данных RAID массива и расположения мета информации в разных версиях mdadm может быть разный.

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

Нет, без конфига при ручной сборке массива или exam нужно указывать смещение.

Так то он поддерживает и соберёт, если указано смещение при отсутствие конфига.

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

Проверю на тестовой виртуалке, но 99% это либо что-то крайне древнее, либо, скорее, для ручного восстановления в тяжелых случаях

Не надо ничего собирать, массив md1 уже есть просто ждёт второй диск по дефолту.

А можно меня просвятить? Если в зеркале 1 диск отваливается что 2й становится не доступен?

(просто вашей фразы не понимаю применительно к недоступности данных)

А можно меня просвятить?

С этим в церковь.

Если в зеркале 1 диск отваливается что 2й становится не доступен?

Не становится. Но если система только что запустилась и собирается включить массив - будет ждать оба диска. По крайней мере в новых дебианах так, и это проблема (упадёт в initramfs если вторая половина системного рейда исчезла). Я себе фиксил.

Странно как то, вроде это софтверный райд, и ты ему указываешь диск после загрузки. Ну хз, в конце концов можно фейл 2второму указать …

P.S. Интересно, почему это винда испортила два одинаковых диска по разному …

P.S. Интересно, почему это винда испортила два одинаковых диска по разному

Кстати да. На тестовом стенде мне win10 инициализировала оба диска одинаково

root@ubuntu2204-i1:~# gdisk -l /dev/sdb

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           32767   16.0 MiB    0C01  Microsoft reserved ...

и т.к. пострадали только первые 17 MiB (а скорее всего и вовсе только первый 1 MiB, то попробовал сделать так, и все тестовые данные были на месте и целые

# удалил виндовый раздел через gdisk
gdisk /dev/sdb
   d
   1
   w

# заново создал рейд НА ОДНОМ диске на том же месте БЕЗ ИНИЦИАЛИЗАЦИИ
root@ubuntu2204-i1:~# mdadm --create --level=1 --raid-devices=1 --assume-clean  /dev/md0 /dev/sdb --force

# все на месте
root@ubuntu2204-i1:~# blkid /dev/md0
/dev/md0: UUID="d195d869-ab4b-4e5c-ac93-abec4639ebf3" BLOCK_SIZE="4096" TYPE="ext4"

root@ubuntu2204-i1:~# mount /dev/md0 /mnt/

root@ubuntu2204-i1:~# md5sum /mnt/alse-1.7.7.livecd.iso
c4f4453c950f72607b3340935eec8d1d  /mnt/alse-1.7.7.livecd.iso

Скорее всего, и у ТС получится вытащить данные с того диска, на котором мелкий 16 MiB раздел

Только обычно перед попыткой реанимации нужно сделать копию диска, а он вряд ли найдёт лишние 10 Тб, т.е. будет одна попытка без права на ошибку

• нужно искать этот диск заново, т.к. нумерация дисков может меняться после каждого ребута. возможно, при следующей загрузке он будет sda
• удалить на нём раздел через gdisk
• создать mdadm raid 1 из ОДНОГО диска БЕЗ ИНИЦИАЛИЗАЦИИ
• через blkid проверить, что ФС на месте
• если нет, то искать смещение резервных копий суперблока. как уже сказал kostik87, через ключ -n для mkfs. Если конечно там был именно ext4

vtVitus

Не мудрено, что все человеки свалили на смартфоны

На которых получить свои данные обратно тот еще геморой.

Кстати да.

Может он в раид вгонял их с разными таблицами? ;)

P.S. Тут как то в треде пытался одному вдолбить что btrfs сразу на устройстве это плохо, судя по ответам до него не дошло. Ну ни че, время его вылечит ;)

Ну, ТС сам себе злобный буратино - создал рейд прямо на диске без партиций. На железных хостах так не делают именно чтобы кто-нибудь случайно не инициализировал. Вот на виртуалках можно, там внезапная винда не происходит %)

Она только второй диск испортила, первый не заметила почему-то.

На железных хостах так не делают именно чтобы кто-нибудь случайно не инициализировал. Вот на виртуалках можно, там внезапная винда не происходит %)

4.2

Не делают только там где виндузятники кругом и суют свои руки куда не следует.

Data Offset : 264192 sectors вот это надо подставлять вместо 8. коболд перепутал.

вот как я делал в другой теме (монтировал разные части зеркала как обычный диск):

Проблема флага O_DIRECT (комментарий)

#mount -o ro,offset=17825792 /dev/sdf2 /mnt

смещение как раз брал из data offset *512 (размер сектора, может отличаться, например 4K)

PS: у тя будет

#mount -o ro,offset=135266304 /dev/sda /mnt

сохраняй данные с mnt и потом уже делай что надо с диском

можно кстати missing дать при сборке md. и подняться только на 1 диске.

достаточно дать -b и к обычному расположению прибавить 264192

ну или через dumpe2fs -o superblock=то что выше - проверить сначала что годно

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

P.S. кстати может 2й как то хитро испортился и ему нужно было просто первый отключить и все.

А я уже отвечал что по крайней мере дебиан половину зеркала без ручной команды не запускает.