mdadm восстановить raid1

Каковы мои дальнейшие действия?

Резервных копий данных нет.

Можешь начинать паниковать.

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

Дождись окончания синхронизации, слей дамп с собранного массива на другой накопитель, можно в файл. На этой копии пробуй запустить fsck. Если починит, то можно сделать это уже на массиве. Если нет (а это вероятно, потому что нет первых нескольких килобайтов для суперблока), то нужно сдампить целый диск из массива, и запускать на нём.

Сейчас идет синхронизация массива. Каковы мои дальнейшие действия? Резервных копий данных нет.

В данной ситуации лучше обновить резюме

У тебя был itel’овский рейд (нечто промежуточное между аппаратным и fake raid), с собственными метаданными. Насколько я понимаю, эти метаданные ты прибил

Желательно сделать посекторные копии дисков, и искать специалистов по восстановлению данных. В принципе можно попробовать testdisk (на копии дисков), на свой страх и риск

Не было там интеловского рейда. Контроллер работал в режиме AHCI, что написано в начале поста(специально делал soft raid, что бы не было проблем. Ага, не тут то было).

Тогда поставим вопрос по другому. Если данным с 99% хана, то имеет смысл забить на этот рейд, тормознуть синхронизацию. Убить массив. Разметить диски и создать массив из двух разделов.

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

Эти данные актуальны ровно 2 месяца, потом надобность в них сама собой отпадает и они удаляются.

Не было там интеловского рейда.

Был. Ты путаешь его с аппаратным контроллером. Скорее всего, встроен в чипсет. Тип метаданных - imsm

Magic : Intel Raid ISM Cfg Sig.

Данные пока на месте, только ФС повреждена. Попробуй сделать то, что я написал в первом комментарии. С большой вероятностью данные получится вернуть.

По всем признакам, эти метаданные в хвосте диска, поэтому не вижу причин не попробовать восстановить файловую систему. IMSM это, или MD 0.9 — так ли важно?

Странно, самого смущает эта надпись, но не должен путать. Этот сервер делался 1,5 года назад мной лично. Там есть ещё железный sas контроллер, но эти два диска подключались и подключены через встроенный на матери sata контроллер.

Так вот, остается вопрос эксперименты будем проводить или стразу все тормозить и строить заново учтя горький опыт?

Если данным с 99% хана, то имеет смысл забить на этот рейд, тормознуть синхронизацию.

Метаданным хана. Данные возможно лежат на месте. По идее они могут даже пережить ребилд через mdamdm, т.к. он не забивает диски нулями, а лишь приводит их к одинаковому виду. Если imsm хранил одинаковые блоки с одним смещением (а это логично), то они не пострадают. Но не факт, что ты получишь к ним доступ после сборки рейда с другой версией метаданных - смещение раздела может поменяться.

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

sudo mdadm –create /dev/md127 –level=1 –raid-devices=2 /dev/sdc /dev/sdd

твой вариант годится. IMSM тоже был нормальным вариантом, но нужно было собирать аккуратнее. Не работал с ним, вот тут есть немного информации:

• https://raid.wiki.kernel.org/index.php/RAID_setup#External_Metadata_.282011.29
• https://unix.stackexchange.com/questions/273819/how-do-i-rebuild-create-assemble-an-imsm-raid-0-array-from-disk-images-instead

IMSM это, или MD 0.9 — так ли важно?

Не работал с ним, и у меня нет информации, где и как он хранит метаданные. Судя по документации к mdadm, в случае imsm сначала создаётся контейнер, а уже в нём - логические тома с произвольным уровнем raid

В тред призывается blind_oracle

Родина-мать (и отец Линус) дала им btrfs - не хочу, хочу жрать говно.

Когда он закончит мне нужно будет запустить fsck с какими опциями?

Тебе нужно будет сделать копию, а потом уже запускать что бы то ни было. Для начала можно без параметров, fsck для ext* сама дальше подскажет.

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

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

После этого я выключил массив и натравил e2fsck на диск /dev/sdd. Утилита исправила fs, диск примонтировался и я увидел свои данные.

В данный момент запущено копирование на удаленную машину.

После копирования хочу заново создать массив и скопировать на него.

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

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

Можем. Создать разделы одинакового размера (лучше на несколько мегабайт меньше максимально возможного) на дисках, потом на них создавать массив. Это поможет избежать некоторых проблем. Каких-то других нюансов нет. У тебя тут изначально проблема была в попытке создать массив заново вместо сборки существующего. Хорошо, что починил, полезный опыт.

Заюзать LVM

Место свободное в начале оставлять или в конце? С дисков нужно вычищать старую информацию о предыдущем массиве?

LVM пока юзать не буду.

Место свободное в начале оставлять или в конце?

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

С дисков нужно вычищать старую информацию о предыдущем массиве?

Если она будет мешать, её предложат удалить соответствующие программы. Но лучше сразу пройтись утилитой wipefs (с -a), чтобы оно потом не вылезло в нештатной ситуации, как этот вот IMSM не пойми откуда.

Создал массив предварительно поработав утилитой wipefs. Сейчас это выглядит так:

1@1:~$ sudo mdadm --create --verbose /dev/md127 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: size set to 3850238976K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md127 started.
1@1:~$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid1 sdd1[1] sdc1[0]
      3850238976 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.0% (1669376/3850238976) finish=307.3min speed=208672K/sec
      bitmap: 29/29 pages [116KB], 65536KB chunk

unused devices: <none>
1@1:~$ sudo mdadm -E /dev/sdc1 /dev/sdd1
/dev/sdc1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 4502e14e:8e428536:83506fe4:74c86066
           Name : 1:127  (local to host 1)
  Creation Time : Wed Nov 29 10:53:59 2023
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7700477952 (3671.87 GiB 3942.64 GB)
     Array Size : 3850238976 (3671.87 GiB 3942.64 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : active
    Device UUID : 39bf1c5e:271c9d7f:394e0ac7:c5fb90b8

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Nov 29 10:56:50 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 458cb0e9 - correct
         Events : 34


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 4502e14e:8e428536:83506fe4:74c86066
           Name : 1:127  (local to host 1)
  Creation Time : Wed Nov 29 10:53:59 2023
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7700477952 (3671.87 GiB 3942.64 GB)
     Array Size : 3850238976 (3671.87 GiB 3942.64 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : active
    Device UUID : d9cd846c:dc1dbb2c:ba7c524e:a8cb3c85

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Nov 29 10:56:55 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 5506bfa8 - correct
         Events : 35


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

Это поможет избежать некоторых проблем.

Каких? Анон, не жмоть опыт.

Про диски чуть-чуть не того размера и резервное место я уже написал. Разделы — это просто хорошая практика. Могут спасти как от своих ошибок, так и от чужих. Например, установщики дистрибутивов могут игнорировать любые метаданные ФС/LVM/MDRAID, которые помещены прямо в начало диска. Как минимум, раньше это было актуально для RHEL. Создаст он тебе таблицу разделов поверх суперблока, и привет.

А вот это нужно было делать?

parted -s /dev/sdc set 1 "raid" on && parted -s /dev/sdd set 1 "raid"

Если не ошибаюсь, на практике это было реально нужно только если массив собирается не из initramfs/initrd, а напрямую ядром. Но для наглядности я бы всё равно задал тип, это удобно. Сделать можно и через gdisk/fdisk.

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

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

LVM в некоторых случаях будет даже лучше, но mdadm на порядок проще

А на минусы забей, скорее всего эти люди до сих пор не в курсе, что lvm давно умеет в рейды

А ещё они не в курсе что LVM портировали в Linux а первоначально он был в IBM AIX. Крайний факт не говорит о том что дизайн и реализация безупречны но как по мне там всё достаточно эстетично.

скорее всего эти люди до сих пор не в курсе, что lvm давно умеет в рейды

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

Не AIX, а HP-UX. И не портировали, а «вдохновились дизайном LVM в HP-UX». Код ведь не открыт.

Да, всё правильно, HP-UX - спасибо за ремарку. Даже команды совпадают

Всем спасибо. Сервер восстановлен, данные не потеряны. Может кому-то это поможет в будущем.

p.s. какой командой нужно было восстановить raid массив?