metalsoft Опубликовано 3 июня, 2021 · Жалоба Доброго всем! Случилось так, что развалился софт raid 10. После перезагрузки утром того дня raid был помечен как деградированный, имел статус UUU_, но собирался и монтировался. после этого все диски сняли с сервера, подключили к винде, чтоб проверить в Crystal Disk. Результат - все диски ОК, я подключил их обратно к линуксовому серверу и попытался снова его собрать (mdadm --assemble --scan, mdadm --detail --scan и т.д). Но mdadm уже ничего не выводил, т.е. отвечал пустой строкой, не обнаруживал raid'а. gdisk показал, что на дисках отсутствуют разделы. Собсно и вопрос: что еще можно попытаться сделать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 июня, 2021 · Жалоба Есть подозрение что теперь диски кристально чистые.. А что сделать.. Ну воостановиться с бакапа, это наверное единственное, что остаётся.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 3 июня, 2021 · Жалоба 1 час назад, metalsoft сказал: Crystal Disk А smartctl, hdparm, ddrescue, dd и кучка прочих утилит не устраивают именно отсутствием красивых менюшек? Я бы еще понял, если бы сняли "посмотреть" винт, который "выпал" из массива, но зачем остальные?.. 1 час назад, st_re сказал: воостановиться с бакапа Если он был - вопрос этот врят ли бы задавали, скорее всего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 3 июня, 2021 · Жалоба 12 минут назад, passer сказал: А smartctl, hdparm, ddrescue, dd и кучка прочих утилит не устраивают именно отсутствием красивых менюшек? Я бы еще понял, если бы сняли "посмотреть" винт, который "выпал" из массива, но зачем остальные?.. Сам уже пожалел об этом решении, но тогда оно показалось самым быстрым. А что винда какие-то изменения на диск внесет, опроверг уже более поздний эксперимент. Насчет бэкапа - этот рейд предполагался неубиваемым да и бэкапить такой объем не на чем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 июня, 2021 · Жалоба А причём тут винда, если вы использовали "Crystal Disk" ? там наверное есть тест на запись.. вот оно и оттестировало. Причем если там были нечитаемые сектора, то оно их релокейтнуло.. в общем можно было не снимая dd if=/dev/zero of=/dev/sda bs=1M ; dd if=/dev/sda oif=/dev/null bs=1M сделать тоже самое.. :/ Вообще там наверное был и недеструктивный тест.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 3 июня, 2021 · Жалоба Мой коллега, делая очередной бэкап, до сих пор похохатывает: "люди делятся на тех кто не делает бэкапы, и тех кто уже делает". На дисках были разделы объединенные mdadm? Тогда попробуйте натравить testdisk на эти винты. Вытаскивать их для этого из linux-машины не нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 3 июня, 2021 · Жалоба 12 минут назад, st_re сказал: А причём тут винда, если вы использовали "Crystal Disk" ? там наверное есть тест на запись.. вот оно и оттестировало. Причем если там были нечитаемые сектора, то оно их релокейтнуло.. Вообще там наверное был и недеструктивный тест.. Тогда надо предположить, что нечитаемые сектора были именно в том месте, где нужно и сразу на всех 4х дисках 12 минут назад, passer сказал: На дисках были разделы объединенные mdadm? Тогда попробуйте натравить testdisk на эти винты. Вытаскивать их для этого из linux-машины не нужно. Как раз сейчас провел такую операцию на тестовом диске: создал GPT таблицу, на ней - раздел типа LinuxRAID, удалил его. Запустил testdisk - он нашел какие-то древние ntfs разделы, файлы на них, но ни следа от LinuxRAID :( Завтра попробую на копии боевого диска Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 июня, 2021 · Жалоба 5 минут назад, metalsoft сказал: Тогда надо предположить, что нечитаемые сектора были именно в том месте, где нужно и сразу на всех 4х дисках с чего бы ? сия умная чекалка просто переписала ВЕСЬ диск нулями.. все 4 диска.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 3 июня, 2021 (изменено) · Жалоба 5 минут назад, st_re сказал: с чего бы ? сия умная чекалка просто переписала ВЕСЬ диск нулями.. все 4 диска.. Разве это не заняло бы несколько часов? С целью разобраться, как я умудрился потерять разделы, просмотрел bash_history. Все, что я вводил, это fdisk -l, cat /proc/mdstat, mdadm --scan, mdadm --examine, mdadm --assembe --scan Изменено 3 июня, 2021 пользователем metalsoft Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 3 июня, 2021 · Жалоба 9 минут назад, metalsoft сказал: разу на всех 4х дисках Вы же сами написали, что UUU_, т.е. выпал один винт. Далее было бы разумно почитать логи, чаво это диск забракован, глянуть S.M.A.R.T. и по вкусу отполировать тестом на чтение винта. И ежели всё норм, воткнуть винт в массив и наблюдать дальше. 1 минуту назад, metalsoft сказал: Разве это не заняло бы несколько часов? Совсем не ведаем чем вы занимались и, если и обсуждаем, то только предоставленную вами информацию. А в ней конкретики мало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 3 июня, 2021 · Жалоба 5 минут назад, passer сказал: Совсем не ведаем чем вы занимались и, если и обсуждаем, то только предоставленную вами информацию. А в ней конкретики мало. Прошу пардону, виноват. Я это написал к тому, что пытаюсь понять, что привело к потере данных и мы бы заметили, что комп чем-то непонятным занимается с ценным винтом несколько часов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 3 июня, 2021 · Жалоба Можете слить метаблоки mdadm и посмотреть что в них. Для этого любой редактор подойдет. Не удивлюсь, что там нули. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 июня, 2021 · Жалоба ну тогда разбейте диски как они были разбиты до начала операции и посмотрите что будет.. вообще мне тут коллеги из виндовз подсказывают что эта штука ддействительно делает деструктивный тест... кроме того ТЕСТ, а не посмотреть смарт подразумевает хотябы полное чтение диска.. даже если сделать длиный смарт тест, он всёравно занимает много времени, потому, что ничего волшебного не делает но просто перечитывает весь диск.. поэтому что вы там делали и что вы понимаете под тестами, тайна есть... а просто посмотреть смарт в любой ОС, или почитать диск, разделы не убивает... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 3 июня, 2021 · Жалоба 4 hours ago, st_re said: с чего бы ? сия умная чекалка просто переписала ВЕСЬ диск нулями.. все 4 диска.. Хватит городить какую-то херню. Ну честно. Из известных вводных этого никак не следует. CrystalDiskInfo это просто инструмент для отображения SMART, аля smartctl. CrystalDiskMark имеет недеструктивный тест на запись, требующий обязательного наличия уже существующей ФС на диске. Для "посмотреть состояние" даже гадать нечего, пользовались естественно первым. Да и второй ничего не стал бы писать, не видя диск как доступный для чтения-записи с известной ФС и "буквой диска". Если конечно юзер не делал что-либо ещё, например какую-нибудь Викторию и т.д. Кроме того, если изначально под RAID использовались raw-диски (весь диск без разделов), то при попытке такой диск открыть в Disk Management в винде, она предлагает его инициализировать в GPT, и если с этим согласиться, создаёт там Microsoft Reserved Partition, и вот этим как раз успешно убивает метаданные RAID'а. Но и на это не похоже по симптомам, автор вроде говорит, что разделов сейчас вообще нету никаких (даже Microsoft Reserved), в то время как должны были быть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 4 июня, 2021 · Жалоба @rm_ Вам не кажется что Ваша первая часть противоречит Вашей же второй ? Если тесты не деструктивные то там даже ничего собирать не надо было бы, они бы сами бы увиделись бы на той же системе где и были ранее, если на диск ничего не писалось, то в общем пофиг втыкали ли их там куда то или нет в промежутке от выключения до включения.. если действительно диски были без разделов и винда их проинитила, то раделов то там не появится, если их не создавать, а будет пустая таблица разделов.. ну снести 1 сектор и собрать массив руками с теми же параметрами как оно было изначально. плохо что 1 диск был вылетевший.. собрать с --assume-clean и сразу фейльнуть тот диск, который был фейльнут в начале операции (ну или собрать сразу указав вместо жтого диска missing). почистить на вылетевшем метаданные и воткнуть в массив, чтобы он снова собрался.. но т.к. непонятно что там всетаки делалось, и одно или тоже "Crystal Disk" и "CrystalDiskInfo" или был "CrystalDiskMark" и было тестирование на скороть записи, или хто ж его знает что там так названо еще. (идея с КристалДиск Инфо вообще не понятна, смартктл выводит абсолютно теже самые буквы без снятия дисков.) то шансы не велики.. да и не факт что ктото помнит с какими параметрами собирался массив изначально. вариантов там есть. как назывался массив в системе ? mdХ . Х-что ? не 127 ли? надо было результат mdadm --detail --scan вписать в /etc/mdadm.conf если таблица была, то создать еще раз и пробовать пересобрать массив.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 4 июня, 2021 (изменено) · Жалоба 1 час назад, st_re сказал: как назывался массив в системе ? mdХ . Х-что ? не 127 ли? Припоминается, что именно так он и назывался, хотя создавался как md1. А что означает, если он был 127? Сейчас снял с диска копию суперблока командой dd if=/dev/sdb of=/root/backup.img skip=4 bs=1024 count=1 ([href=https://www.linux.org.ru/forum/general/12739189]отсюда[/href]) там нули. Как сейчас правильнее поступить: gdisk'ом создать раздел типа LinuxRAID и на весь диск (как рейд и создавался) и посмотреть его testdisk'ом или попробовать заново собрать весь рейд теми же средствами, какими он создавался (там на самом деле вариантов было немного: ничего мудреного я не делал, просто создал разделы на все 4 диска, указал тип и mdadm --create) Изменено 4 июня, 2021 пользователем metalsoft Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 4 июня, 2021 · Жалоба Создавать разделы не надо. Сразу пробовать testdisk на посекторной копии каждого диска или на оригинале. Хотя, если разделы были один на весь диск - быстрее ручками создать и уже потом mdadm --assemble --scan 3 часа назад, metalsoft сказал: просто создал разделы на все 4 диска, указал тип и mdadm --create) metadata явно задавали? /etc/mdadm.conf после этого создали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 4 июня, 2021 · Жалоба 4 hours ago, st_re said: @rm_ Вам не кажется что Ваша первая часть противоречит Вашей же второй ? Если тесты не деструктивные то там даже ничего собирать не надо было бы, они бы сами бы увиделись бы на той же системе где и были ранее, если на диск ничего не писалось, то в общем пофиг втыкали ли их там куда то или нет в промежутке от выключения до включения.. Нет не кажется, из вводных мы имеем максимум "неизвестно что произошло", а никак не "ну всё понятно, это CrystalDisk(???) всё стёр", как вы написали. 4 hours ago, st_re said: если действительно диски были без разделов и винда их проинитила, то раделов то там не появится, если их не создавать, а будет пустая таблица разделов При инициализации в GPT она создаёт Microsoft Reserved раздел объёмом ~128 МБ. 4 hours ago, st_re said: идея с КристалДиск Инфо вообще не понятна, смартктл выводит абсолютно теже самые буквы без снятия дисков Ясное дело, ну автор был незнаком со smartctl и решил воспользоваться виндовым аналогом. 3 hours ago, metalsoft said: dd if=/dev/sdb of=/root/backup.img skip=4 bs=1024 count=1 ([href=https://www.linux.org.ru/forum/general/12739189]отсюда[/href]) там нули. А почему делаете отступ 4 килобайта, если на диске были разделы и RAID делался из них, то 4 килобайта нужно отсчитывать от начала раздела, а не начала всего диска. При создании современными инструментами первый раздел обычно начинается с 2048-го сектора (1 мегабайт). Если старыми, то с 63-го сектора (32256 байт). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 4 июня, 2021 · Жалоба 1 час назад, passer сказал: metadata явно задавали? /etc/mdadm.conf после этого создали? metadata не задавал. Создал mdadm.conf командой %# echo "DEVICE partitions" > /etc/mdadm/mdadm.conf %# mdadm --detail --scan --verbose | awk '/ARRAY/ {print}' >> /etc/mdadm/mdadm.conf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 4 июня, 2021 · Жалоба В 03.06.2021 в 16:42, metalsoft сказал: Как раз сейчас провел такую операцию на тестовом диске: создал GPT таблицу, на ней - раздел типа LinuxRAID, удалил его. Запустил testdisk - он нашел какие-то древние ntfs разделы, файлы на них, но ни следа от LinuxRAID :( Завтра попробую на копии боевого диска не помню ищет ли он суперблок mdadm'а, но суперблок файловой системы, которая была на рейде, он должен найти. это может быть отправной точкой, с которой можно начать восстановление Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...