Устройство / dev / md исчезло в массиве Linux RAID1

Итак, по суперблоку на /dev/sdk, был /dev/md5 и sdj был там с ним, но согласно /dev/sdj, рейдового суперблока нет. Я боюсь, что /dev/sdj был добавлен в массив md5, затем /dev/sdj был добавлен в группу томов (вместо /dev/md5) и в какой-то момент lvm переписал блоки, которые идентифицировали его как член RAID-устройства. Я боюсь этого, потому что я, честно говоря, не могу придумать, как по-другому / dev / sdj в конечном итоге будет назван специально в группе LVM и больше не будет иметь суперблока рейда.

Худший кошмарный сценарий: в LVM были добавлены и / dev / sdj, и / dev / md5. Ваш раздел XFS теперь больше 5,5 ТБ в LVM? Если это так, вы сможете вернуть md5, используя mdadm --assemble но вы должны быть уверены, что он запущен в деградированном режиме без sdj, чтобы он не перезаписывал данные там.

Предполагая, что ваш / dev / md5 никогда не использовался в LVM:

(... ты когда-нибудь смотрел на pvscan до сегодня?)

Если у вас нет резервных копий, самое время начать. Если да, то сейчас самое время их протестировать (а если они не работают, у вас нет резервных копий, см. Шаг 1).

Нет простого выхода из этого беспорядка, и я понятия не имею, что может произойти, если вы перезагрузитесь в этот момент (можете ли вы размонтировать файловую систему?). Если Я был уверен, что на самом деле произошло то, что sdj был добавлен как рейд-драйв и как физический том lvm (поскольку lvm ​​не использовал драйвер raid для записи в sdj, ни один из данных, записанных в sdj, не будет на sdk ... возможно, это можно проверить, сравнив шестнадцатеричные дампы различных фрагментов / dev / sdj и / dev / sdk и кто-то более умный, чем я, который знает хорошие места для поиска вещей, которые могли бы сказать «это XFS» против «это случайная тарабарщина или пустой диск»?), то что бы я сделал, это это :

Начните с попытки получить данные SMART на sdk, чтобы узнать, заслуживают ли они доверия или находятся в процессе выхода.

Если sdk хорош, то я бы поблагодарил своих счастливчиков за то, что бывший администратор потратил впустую 63 ГБ /dev/sdj.

fdisk /dev/sdk

(дважды проверьте ВСЕ, прежде чем нажать клавишу возврата). Попросите fdisk создать таблицу разделов и раздел md (на man-странице mdadm говорится, что нужно использовать 0xDA, но в каждом пошаговом руководстве и моем собственном опыте указано 0xFD для автоматического определения рейда), затем

mdadm --create /dev/md6 --level=1 --raid-devices=2 missing /dev/sdk1

(дважды проверьте ВСЕ, прежде чем нажать клавишу возврата). Это создаст деградированный массив raid1 с именем md6, используя раздел, который мы создали на sdk. Вот почему это потраченное впустую пространство так важно: мы потеряли некоторое пространство из-за суперблока md и из-за таблицы разделов, поэтому наш / dev / md6 немного меньше, чем был / dev / sdj. Мы собираемся добавить / dev / md6 в dedvol группу томов и проинструктируйте LVM переместить 1.82 ТБ логического тома из / dev / sdj в / dev / md6. LVM может обрабатывать активную файловую систему при этом.

pvcreate /dev/md6
vgextend dedvol /dev/md6
pvmove -v /dev/sdj

(перепроверьте ... вы понимаете. Я бы также pvscan после pvcreate и снова после vgextend чтобы убедиться, что все выглядит правильно). Это запустит процесс перемещения всех данных, выделенных на /dev/sdj к /dev/md6 (в частности, команда перемещает все с sdj, и md6 - единственное место, куда она может пойти). Через несколько часов это либо завершится, либо система заблокируется при чтении из sdj. Если система вылетает, можно перезагрузиться и попробовать pvmove без имени устройства для перезапуска на последней контрольной точке или просто откажитесь и переустановите из резервных копий.

Если нам это удается, мы удаляем / dev / sdj из группы томов, а затем удаляем его как физический том:

vgreduce dedvol /dev/sdj
pvremove /dev/sdj

Теперь о проверке коррупции. Инструмент для проверки и исправления xfs есть xfs_repair (fsck будет работать в файловой системе xfs, но вообще ничего не делает). Плохие новости? Он использует гигабайты ОЗУ на терабайт файловой системы, поэтому, надеюсь, у вас есть 64-битный сервер с 64-битным ядром и 64-битным двоичным файлом xfs_repair (который может называться xfs_repair64) и не менее 10 ГБ ОЗУ + своп (вы должны иметь возможность используйте часть оставшегося пустого места в дедволе для создания тома подкачки, затем mkswap этот том, то swapon тот объем). Файловая система должен быть демонтирован перед запуском на нем xfs_repair. Кроме того, xfs_repair может обнаруживать и (пытаться) исправить повреждение самой файловой системы, но он может не обнаруживать повреждение данных (например, что-то перезаписывает часть inode каталога по сравнению с чем-то, перезаписанным в середине текстового файла).

Наконец, нам нужно купить новый /dev/sdj, установите его и добавьте к деградированной /dev/md6, имея в виду, что если мы перезагружаем компьютер без sdj, возможно, что sdk переместится в sdj, и вместо этого новый диск будет sdk (возможно, нет, но лучше быть уверенным):

fdisk /dev/sdj 

убедитесь, что это не тот диск, который мы уже разбили и настроили, затем создайте на нем раздел для md

mdadm /dev/md6 -a /dev/sdj1

(Вполне возможно, что ошибки могут быть связаны с raid и lvm, вычищающими его из-за содержимого sdj, а не из-за фактического отказа диска (обычно неисправные диски генерируют много тарабарщины от драйвера в dmesg а не просто ошибки ввода / вывода), но я не уверен, что рискну.)