Развалился soft raid 1

размер слишком мало, хотя по факту тот же

100% нет, смотри в блоках или байтах, если блоки разные.

получил неработающий массив

Странно (нет).

Если сделать mdadm –examine /dev/sdb1: No md superblock detected on /dev/sdb1

Так у тебя он на /dev/sdb, а не /dev/sdb1.

Удали /dev/sdb из массива, запусти массив, и разберись для начала с размерами.

100% нет, смотри в блоках или байтах, если блоки разные.

fdisk -l /dev/sda
Диск /dev/sda: 2,73 TiB, 3000592982016 байт, 5860533168 секторов
Disk model: WDC WD30EFRX-68E
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: gpt
Идентификатор диска: F2603CD4-4E5B-4E9D-A1CC-9038B23E6804

Устр-во    начало      Конец    Секторы Размер Тип
/dev/sda1    2048 5860533134 5860531087   2,7T Linux RAID

fdisk -l /dev/sdb
sudo fdisk -l /dev/sdb
Диск /dev/sdb: 2,73 TiB, 3000592982016 байт, 5860533168 секторов
Disk model: WDC WD30EJRX-89A
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: gpt
Идентификатор диска: 94566B42-1F5E-423C-81E8-BC3AD25DAD3B

Устр-во    начало      Конец    Секторы Размер Тип
/dev/sdb1    2048 5860532223 5860530176   2,7T Linux RAID

А, все. Концы какого-то хрена не совпадают. Почему, вот это загадка. Прошивка на это может влиять если один SMR, а другой - CMR?

Этот mdadm постоянно разваливается. Unix way костыли. Рейд должен быть встроен в фс. Вкатывайся в btrfs. Там raid1 тремя строчками включается и просто работает.

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

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

Ну, видимо уже ничего не поделать, разве что копировать все данные с одного раздела на другой, уменьшать первый и снова собирать. Или взять все же WD Red.

В общем, если верить fdisk, количество секторов и байт на обоих разделах совпадает, однако второй раздел при создании получается на 911 секторов короче.

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

А если там ext4, то вообще не вижу большой проблемы сделать ресайз.

В связи с этим вопрос: как можно добыть недостающие сектора? Ну, или какая альтернатива?

ext4 на массиве, ага.

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

То есть из-под LiveUSB. Делай раз: собираем массив заново, но теперь ведущим будет /dev/sdb. Делай два: Скопировать на него все с /dev/sda. Делай три: на /dev/sda выровнять правую границу на 911 секторов меньше. Делай четыре: новый /dev/sda добавить в новый рейд.

mount -o degraded спасёт файлы отца русской демократии, чтение же манов спасёт его нервы.

Я-то в курсе, но для привыкших к «конвенциональному» RAID1 это будет WTF. Зато не получится, как это часто бывает, когда о выпавшем из массива два года назад диске узнают после смерти второго.

Чего? Удали второй диск из массива и всё заработает. Потом собери нормально уже. Не надо никаких ручных копирований.

Ахаха, мне вот неделю назад тут какой-то аноним (это не ты ли был?) доказывал, что правильный рейд - поверх разделов, потому что иначе у разных моделей разный объём бывает: Современная разбивка диска (комментарий)

И что мы видим? Всё случилось ровно наоборот - объём дисков разных моделей одинаковый, но из-за неправильной разбивки получились разные разделы, и ничего не работает.

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

Удали разметку с /dev/sdb

dd if=/dev/zero of=/dev/sdb bs=512 count=2048
dd if=/dev/zero of=/dev/sdb bs=512 count=2048 seek=5860531168

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

Все, решил. Оно по умолчанию не тот сектор конечным ставило, понадеялся на дефолты. Поменял руками, прокатило. Спасибо за помощь.

sgdisk /dev/sda --replicate=/dev/sdb
sgdisk -G /dev/sdb

Да я уже по рецепту furkax поправил разметку раздела. fdisk почему-то не захотел выставлять ее по самому последнему сектору диска, а отступил чуть ли не на тысячу. Почему- загадка.

Я понял; на будущее просто.

что вам все неймется с этими рейдами, дети 90-х?

забудьте о них, юзайте бэкапилки вроде борга/рестика

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

Это не бэкап (от rm somefile не спасает), а устойчивость системы к выходу из строя одного диска. Чтобы не было offline.

это не ты ли был?

Похож до степени смешения ©

Достал два куска ржавчины из коробки, один Seagate, другой Toshiba, оба 3 Тб. Размер у обоих оказался такой же, как у ТС в точности. Что ж, видимо, «часто» могло оказаться преувеличением.

неправильной разбивки

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

Это и есть бэкапилка

Нет. Более того, поскольку настоящих бэкапов у тебя нет, это скорее факапилка, ждущая своего часа :)

Что ж, видимо, «часто» могло оказаться преувеличением.

Да не, тут дело не в часто а во времени. Когда-то давным давно, с дисками (не SSD) в районе 100гб, один seagate, другой wd, я и сам с подобным столкнулся к своему удивлению. Но с тех пор видимо давно договорились о негласных стандартах размеров и с более новыми дисками такого уже не повторялось.

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

Подозреваю скорее протекло выравнивание по цилиндрам, хоть там и написано что выбранная единица - секторы, да и вообще режим gpt.

Как вариант, данные там ценности не представляют, но надо обеспечить непрерывность просмотра кино. После отказоустойчивого сетапа Plex в Kubernetes на трёх серверах в кластере Proxmox меня такое уже не удивляет.

тут по топику видно как сильно ему важна устойчивость системы, в 5 девяток, очевидно :фейспалм:

По сути да. Оно именно от «накрылся контроллер и привет».

Какой контроллер?

Это не бэкап. Бэкап он в оффлайне и позволяет восстановить удаленные/испорченные файлы. Здесь второй диск это бэкап первого диска как железа, чтобы сервер не грохнулся в оффлайн

О чем я и пишу. А резервную копию где держать - это надо подумать.