mdadm raid10 как восстановить?

cat /proc/mdstat сделай

По тому что написано видно что sdc1 выпал из массива ещё 7 ноября и надо было тогда его уже чинить. Теперь выпал sdb1 и после этого вскоре систему выключили.

Я вот не знаю в каком порядке дики в raid10 идут. Если sdd и sde относятся к разным половинам raid0 то всё вообще хорошо, если же к одинаковым то у тебя на второй половине на полторы минуты дольше что-то делалось и она рассинхронизировалась с первой. Подозреваю что второй вариант т.к. иначе бы он наверно сам запустился.

Personalities : md0 : inactive sdc14 sde13 sdb11 sdd12 937720096 blocks super 1.0

unused devices:

и такое

Personalities : [raid10] md0 : inactive sdd1[2] sde1[3] 468860048 blocks super 1.0

unused devices:

Первое выдает сразу после загрузки. Второе выдало после тогда как делал examine и попытка run.

•   8       49        2      sync set-A   /dev/sdd1
  

•   8       65        3      sync set-B   /dev/sde1
  

Ну вроде же видит их как A и B?

Вобщем я посмотрел, название sync set это название зеркала. То есть у тебя остались два зеркала второй половины страйпа. А первая половина, потеряла один диск 7 ноября и второй сейчас. Теперь она рассинхронизирована. Запустить, я уверен, можно (если sdc живой), но после этого там будет несколько битая фс т.к. последние полторы минуты работы компа записывали только второй страйп. Я бы после такого сделал fsck как минимум.

Проверь что с sdc случилось, он читается нормально? Если есть сомнения в его работоспособности лучше снять образ сразу.

А как мне его проверить? Что нужно сделать? Прочитать dd?

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

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

Вообще, надо было 7 ноября ещё заметить вылет первого диска и исправить ситуацию.

Очень сильно расстроит.

Первое, что нужно сделать:

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

Можно использовать улиту dmsetup для создания snapshot`а где запись изменений будет идти в файл / отдельное блочное устройство и далее пробовать собирать RAID массив на основе полученных составных блочных устройств. С assume-clean или другим способом.

Вообще, надо было 7 ноября ещё заметить вылет первого диска и исправить ситуацию.

mdadm поддерживает настройку отправки уведомлений на почту. Или даже в ТГ можно настроить. Хоть средствами самого mdadm, а так, правильно - должен был быть настроен мониторинг через zabbix и отправка уведомлений.

«Да, человек смертен, но это было бы еще полбеды. Плохо то, что он иногда внезапно смертен, вот в чем фокус!» (c) Воланд. М.А. Булгаков, роман "Мастер и Маргарита"

Перефразируя: SSD быстро выходят из строя, но это ещё полбеды. Плохо, что иногда они выходят из строя внезапно.

Десктопный SSD с небольшим TBW. За ним нужно было следить и делать резервные копии.

Никто не спорит. Но имеем что имеем… Диски новые. Недавно заменили. И не всегда видишь то что должен видеть, по разным причинам…

пробовать форсированно собирать массив на основе копий копий.

единственный вариант пробовать пересобрать массив?

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

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

Но тут всё зависит от наличия у вас относительно немалых денег.

И не всегда видишь то что должен видеть, по разным причинам…

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

И, конечно, практика проверки уведомлений zabbix или почты / ТГ канала с сообщениями от системы мониторинга.

Т.е. у меня сейчас нет абсолютно никакой возможности как-то исправить диск(и) чтобы запустить массив? Только пересобирать массив заново?

Если вам дынные нужны и вы не понимаете, что делаете - обращайтесь в специализированный сервис.

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

Работы по сборке массива для вычитывания данных нужно проводить на копии дисков (образах).

Т.к. вы до сих пор грезите надеждой как-то запустить развалившийся массив на исходных дисках - данные вам не важны.

В этом случае можете просто убрать диски, которые вывались, дополнить нужным количеством дисков и просто собрать пустой новый массив. Далее на нём уже файловую систему или что вам нужно и работайте дальше.

kostik87 очень правильно написал «Десктопный SSD с небольшим TBW. За ним нужно было следить и делать резервные копии.» Но дополню, за любым ssd надо следить и делать резервные копии, к сожалению любой ssd может сдохнуть в моменте не успев сказать «мяу» по смарту. Имхо ваша ошибка в том, что вы загнали в raid несколько модулей из одной партии, т.е. смысл raid в данном случае теряется от слова совсем. Он в принципе в контексте ssd не особо актуален, но если модули разные то есть хоть какой-то шанс, что они все не сдохнут в один день.

• Crusial CT240BX500SSD1 240 Gb - 80 TBW.
• SSD Intel D3-S4510 240 Gb - 900 TBW

https://www.nix.ru/autocatalog/ssd_intel/SSD-240-Gb-SATA-6Gb-s-Intel-DC-D3-S4510-Series-SSDSC2KB240G8-01-25-3D-TLC_364414.html

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

Я тоже не спорю, я вам дал рекомендации на что нужно смотреть и как действовать.

Дальше ваш выбор как поступать.

Спасибо.

Автор, ты увлёкся философскими рассуждениями с kostik87, а всего то надо сделать бекап диска чтобы избежать опасности потери данных. Как сделаешь - сделай массиву принудительное assemble (из трёх дисков - sdb не надо, он точно устаревший), затем проверку массива, затем fsck того что на нём расположено. На этом вроде всё готово будет.

Пересобрать массив это не делать его заново, а прнудительно запустить тот что есть. Повторю - только sdb в него не суй, он всё испортит. Точнее, лучше проверь на каком названии будет диск с last update 7 ноября, а то вдруг он не на sdb окажется.

Ага и цена 5-кратная. Лучше самсунг тогда взять.

Но дополню, за любым ssd надо следить и делать резервные копии,

Дополню, делать резервные копии надо вне зависимости от того на чём хранятся данные.

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

mdadm поддерживает настройку отправки уведомлений на почту

Так и вижу: сдох у тебя массив (всмысле, совсем), начинаешь выяснять в чём дело, вспоминаешь про эти уведомления, заходишь на почту. И правда, год назад приходило уведомление про вылет первой половины миррора! Как жаль, что за этот год никто не позвал в стиле «я тебе на почту что-то там скинул, посмотри», тогда бы уведомление от рейда вовремя было замечено...

Спасибо. Буду пробовать.

А да, в смарте вроде всё хорошо, сбой скорее всего был программный или из-за потери 220В. Но раз данные важны - всё равно образ забекапь перед дальнейшими действиями.

Да, у них там часто такое бывает.

Пересобрать массив это не делать его заново, а прнудительно запустить тот что есть. Повторю - только sdb в него не суй, он всё испортит. Точнее, лучше проверь на каком названии будет диск с last update 7 ноября, а то вдруг он не на sdb окажется.

• dev/sdb1 Sun Dec 28 14:31:11 2025
• dev/sdc1 Fri Nov 7 02:52:14 2025
• dev/sdd1 Sun Dec 28 14:32:44 2025
• dev/sde1 Sun Dec 28 14:32:44 2025

Вот так сейчас у меня. Получается диск sdc Исключить?

Сейчас Intel стоит в два раза дороже того Crucial. Поэтому Intel или другой SSD уровня Enterpise.

• Crusial автора - 6000 р.
• Intel SSD - 12000 р.

Так и вижу: сдох у тебя массив (всмысле, совсем), начинаешь выяснять в чём дело, вспоминаешь про эти уведомления, заходишь на почту.

Почту я проверяю каждый день и уведомления в канале в ТГ от разных систем мониторинга тоже и непосредственно в Zabbix каждое утро.

Но дополню, за любым ssd надо следить и делать резервные копии,

Дополню, делать резервные копии надо вне зависимости от того на чём хранятся данные.

Полностью согласен! Но я акцентировал внимание именно на ssd которые мрут в моменте даже без «объявления войны» в независимости от ынепрайз оно или нет. У энтерпрайзных hdd такое тоже случается, но все-таки реже.

вспоминаешь про эти уведомления

Т.е. уведомления вы таки видели, но забили на них, это эталонное ССЗБ.

заходишь на почту

Что значит выражение «заходишь на почту»? На почту России заходишь?

План действий такой: отключаю sdc Делаю копии трех дисков и делаю пересборку?

Т.е. уведомления вы таки видели, но забили на них, это эталонное ССЗБ.

Нет, я имею ввиду «вспоминаешь что они вообще существуют».

Что значит выражение «заходишь на почту»?

Означает - впервые за прошедший год запускаешь почтовый клиент и смотришь что там во входящих среди гор спама и прочей ненужной графомании наприходило.

Да, тут исключить sdc. Хм, мне казалось что на sdb это было, но сейчас посмотрел всю тему - 7 ноября с самого начала было sdc.

И тут выяснились детали (сейчас напишу) - случайно не тот диск не получится запустить так что можно не переживать.

Можно и копии трёх, вреда не будет.

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

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

А как?

Смотрим «Super Offset» в выводе examine: 468860064.

Подменяем счётчик событий на нужном вылетевшем диске (sdb1 - проверь что на нём декабрь а не ноябрь). Правлиьное число берём с sdd1.

cd /tmp
# читаем суперблоки
dd if=/dev/sdb1 bs=512 skip=468860064 count=1 of=sdb1-super
dd if=/dev/sdd1 bs=512 skip=468860064 count=1 of=sdd1-super
# проверяем - значение счётчика в hex   A1 B4 8A 00
dd if=sdb1-super bs=1 skip=200 count=8 | hexdump -C
# проверяем - значение чексуммы         A9 A6 8E 3F
dd if=sdb1-super bs=1 skip=216 count=4 | hexdump -C
# исправляем счётчик
dd if=sdd1-super bs=1 skip=200 count=8 of=sdb1-super seek=200 conv=notrunc
# пишем суперблок назад
dd of=/dev/sdb1 bs=512 seek=468860064 count=1 if=sdb1-super
mdadm --examine /dev/sdb1

В новом examine видим что events теперь правильное но не сходится контрольная сумма. К счастью он сам пишет какая ему нужна. Допустим, была там 11223344 а правильная 12345678 тогда делаем так (обрати внимание эти 4 байта везде задом наперёд идут):

dd if=sdb1-super bs=1 skip=216 count=4 | hexdump -C
# смотрим старую - должно быть 44 33 22 11
# меняем на новую
printf '\x78\x56\x34\x12' | dd of=sdb1-super bs=1 seek=216 count=4 conv=notrunc
# пишем на дискdd of=/dev/sdb1 bs=512 seek=468860064 count=1 if=sdb1-super
mdadm --examine /dev/sdb1

mdadm пишет половину нужных логов в dmesg вместо консоли, поэтому для удобства можно открыть рядом второе окно терминала и в нём dmesg -TW - будет сразу видно если какие-то ошибки

# останавливаем массив
mdadm --stop /dev/md0
# проверяем что он исчез из списка
cat /proc/mdstat
# собираем его заново (тут raid_name в целом ни на что не влияет но вообще будет файл /dev/md/raid_name)
mdadm --assemble raid_name /dev/loop1 /dev/loop2 /dev/loop3
cat /proc/mdstat
# ^ смотрим что он появился, у меня там почему-то только 2 диска вместо 3 добавились хотя он написал что есть 3 диска
# если так то выполняем сборку второй раз
mdadm --assemble raid_name /dev/loop1 /dev/loop2 /dev/loop3
cat /proc/mdstat
# ^ теперь тут точно 3 диска
# запускаем массив
mdadm --run /dev/md0
# проверяем фс
fsck -f /dev/md0

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

Дальше, вообще, можно добавить четвёртый диск и пользоваться. Но если хочется максимальной уверенности что проблемы проявятся где-то позже - монтируем только что собранный массив как read-only, забираем с него все файлы в другое место, потом создаём новый чистый массив и кладём на него данные. Я не смогу назвать конкретную проблему, которая может случиться если этого не сделать. Возможно, там ничего и не может плохого произойти, но, повторю, для собственного спокойствия можно пересоздать массив и файловую систему на нём.

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

Диски скопирую и буду делать. Замысел понятен, выравнять счетчик. Из из-за него, наверное не стартует.

Не стартует из-за счётчика, но не надо думать, что «выровнять счётчик и всё» это универсальное исправление ситуации. Оно годится конкретно тут - только потому, что вылетевший диск отстал всего на полторы минуты и скорее всего почти правильный. Если же то же самое делать с диском, который вылетел в ноябре - массив тоже запустится, но файловая система на нём скорее всего будет безнадёжно побита.

Т.е. уведомления вы таки видели, но забили на них, это эталонное ССЗБ.

Нет, я имею ввиду «вспоминаешь что они вообще существуют».

А, ну это почти старое доброе «кто не делает бэкапы и уже делает бэкапы», в том смысле что да, я тоже когда-то на уведомления смарта клал болт.

Я на Хабре читал статью как у модного и молодежного датацентра так целая партия SSD посыпалась, причем из замены - тоже. Вся партия сдохла чуть ли не в один день.

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

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

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

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

Значит у тебя либо нет корпоративной почты, либо тебе никто не пишет.

Мне, как и некоторой части других специалистов здесь на форуме приходится проверять корпоративную почту по несколько раз в день.

Более того, я уверен, что не только я использую почтовый клиент, который выводит уведомления о появлении новых писем.