Подмяна на неуспешно устройство в mdadm масив на Ubuntu
Публикувано: 15 февруари 2025 г. в 22:01:11 ч. UTC
Последна актуализация: 12 януари 2026 г. в 8:49:50 ч. UTC
Ако се намирате в ужасната ситуация на повреда на устройството в RAID масив mdadm, тази статия обяснява как правилно да го смените в Ubuntu система.
Replacing a Failed Drive in an mdadm Array on Ubuntu
Информацията в тази публикация е базирана на Ubuntu 18.04 и версията на mdadm, включена в неговите хранилища; към момента на писане v4.1-rc1. Тя може да е валидна или да не е валидна за други версии.
Наскоро имах внезапна повреда на диск в домашния ми файлов сървър, който се състои от девет диска в mdadm RAID-6 масив. Това винаги е плашещо, но за щастие успях бързо да намеря резервен диск, който беше доставен още на следващия ден, за да мога да започна възстановяването.
Признавам, че бях малко прекалено скъпернически настроен, когато първоначално настроих файловия сървър; само два от дисковете са истински NAS дискове (Seagate IronWolf), докато останалите са настолни дискове (Seagate Barracuda). Не е изненадващо, че това беше един от настолните дискове, който се беше отказал (след почти три години работа). Беше напълно мъртъв; след като го преместих в настолен USB корпус, всичко, което чух от него, беше обезпокоителен щракащ звук и нито Ubuntu 20.04, нито Windows 10 успяха да го открият.
Е, добре, да се спрем на резервната част (и да, новият диск, който купих, беше IronWolf, поука си научих) - колкото и страшно да е да загубиш диск в работещ масив, още по-страшно е, ако не знаеш правилната процедура за подмяната му. Не е първият път, когато ми се налага да подменям повреден диск в mdadm масив, но за щастие е толкова рядко, че обикновено трябва да търся правилните команди. Този път реших да си направя собствено малко ръководство за бъдещи справки.
И така, първо, когато получите ужасния имейл за събитие за повреда от mdadm, трябва да идентифицирате кой диск е отказал. Разбира се, програмата ще ви каже името на устройството (в моя случай /dev/sdf), но вероятно не е очевидно кой физически диск всъщност е, тъй като тези имена могат да се променят при зареждане на машината.
Ако дори не сте сигурни кое име на устройство е неуспешно, можете да използвате следната команда, за да разберете (заменете /dev/md0 с вашето RAID устройство):
Както споменах, в моя случай това беше /dev/sdf, така че нека продължим с това.
След това можете да опитате да намерите серийния номер на повредения диск, като издадете тази команда:
(ако smartctl не е намерен, трябва да инсталирате пакета smartmontools на Ubuntu)
След това серийният номер може да се сравни със серийните номера на физическия етикет на устройствата, за да се определи кой от тях е повреден.
Този път обаче нямах такъв късмет. Дискът беше напълно изключен и дори отказваше да предостави SMART или други данни, включително серийния номер.
Тъй като имах физически достъп до сървъра (който наистина ви е нужен, ако ще сменяте физически диск сами, предполагам ;-)) и сървърът всъщност работеше, когато дискът се повреди (и продължи да работи безпроблемно благодарение на RAID-6 резервирането), избрах наистина примитивния, но всъщност много ефективен и очевиден метод - просто копирах голям файл на сървъра и наблюдавах кой индикатор на твърдия диск не трепти. В рамките на няколко секунди идентифицирах виновника.
Сега, преди да извадите физическия диск, е добра идея официално да информирате mdadm за това намерение, като издадете тази команда (заменете имената на устройствата със свои собствени, ако е необходимо):
При успех, mdadm ще отговори със съобщение, че е „горещо премахнало“ устройството, очевидно защото виртуалното RAID устройство всъщност работи в този момент.
Ако се получи съобщение за грешка, подобно на „устройство или ресурс е зает“, е възможно mdadm всъщност да не е регистрирал устройството като напълно неуспешно. За да го направи, издайте следната команда (отново, не забравяйте да замените имената на устройствата със свои собствени, ако е необходимо):
След това би трябвало да можете да премахнете устройството от масива с предишната команда.
Сега е време да смените устройството. Ако наистина, наистина - наистина - сте сигурни, че вашата машина и контролер поддържат гореща замяна, можете да направите това, без да изключвате машината. Това би бил правилният начин за работа с критични производствени системи, работещи на истински, подходящ сървърен хардуер, за който със сигурност знаете, че може да го обработи. Моят домашен файлов сървър е базиран на потребителска дънна платка за настолен компютър с няколко полу-номинални SATA контролера в PCIe слотовете, за да се осигурят повече SATA портове.
Въпреки че SATA по принцип би трябвало да поддържа гореща смяна, не възнамерявах да рискувам нищо в тази конфигурация, затова реших да изключа машината, докато сменям устройството.
Преди да направите това, е добра идея да коментирате RAID устройството във файла /etc/fstab, така че Ubuntu да не се опитва да го монтира автоматично при следващото зареждане, защото може да се окаже, че системата може да се „забие“ и да ви принуди да влезете в режим на възстановяване поради повредения RAID масив. Това може да не е голям проблем, ако е настолна система, но аз стартирам този сървър без вграден монитор или клавиатура, така че това би било малко затруднено.
След като стартирате машината с инсталираното чисто ново устройство, използвайте lsblk или друг начин, за да го идентифицирате. Ако не сте променили нищо друго, вероятно (но не е задължително) то ще получи същото име като устройството, което сте заменили. В моя случай го направи, така че новото се нарича още /dev/sdf.
Тъй като моят масив е базиран на дялове, а не на физически устройства, трябваше да копирам таблицата на дяловете от работещ диск на новия диск, за да се уверя, че са абсолютно еднакви. Ако вместо това стартирате масива си на физически устройства, можете да пропуснете тази стъпка.
За тази цел използвах sgdisk, копирайки таблицата на дяловете от /dev/sdc в /dev/sdf. Уверете се, че сте заменили имената на устройствата, за да съответстват на вашите собствени, ако е необходимо.
Обърнете внимание на реда тук: първо изброявате устройството „до“! Това е малко нелогично за мен, но просто се уверете, че сте го направили правилно, за да не получите друг отказ на устройството в масива ;-)
След това, за да избегнете конфликти на UUID, генерирайте нови UUID за новото устройство:
И най-накрая дойде време да добавим новия диск към масива и да започнем процеса по възстановяване! (Добре, всъщност не е купон, а по-скоро доста бавен и изнервящ процес, тъй като наистина, наистина не искате друг диск да се повреди в този момент. Бирата може би ще помогне.)
Както и да е, за да добавите новото устройство към масива, издайте тази команда (отново, не забравяйте да замените имената на устройствата със свои собствени, ако е необходимо):
Ако всичко върви добре, устройството ще бъде добавено към масива безпроблемно. Мисля, че всъщност е добавено като „горещ резерв“ по подразбиране, но тъй като на този масив липсва диск (този, който се е отказал), то веднага се използва и процесът на възстановяване ще започне.
Можете да го наблюдавате така:
Това вероятно ще отнеме известно време; на моя слаб сървър (базиран предимно на потребителски хардуер и настолни дискове, имайте предвид) успя да достигне малко под 100 MB/сек. Имайте предвид, че това е RAID-6, така че има много изчисления за паритет, свързани с възстановяването; RAID-10 би бил много по-бърз. Тази конкретна машина има четириядрен процесор AMD A10 9700E („E“ означава, че е енергийно ефективен модел с по-ниска тактова честота, т.е. не е супер бърз), само за да ви дам представа какво да очаквате. С деветте 8 TB диска в моята конфигурация, пълното възстановяване отне малко повече от 24 часа.
По време на възстановяването можете да монтирате файловата система към масива и да я използвате както обикновено, ако желаете, но аз предпочитам да оставя възстановяването на системата, докато то приключи. Имайте предвид, че ако един диск се повреди, скоро може да последва друг, така че е желателно възстановяването да се извърши възможно най-бързо, тъй като наистина не искате друг диск да се повреди по време на това. Затова не го натоварвайте с други входно-изходни операции, които не са абсолютно необходими.
След като е готово, добавете го обратно към файла /etc/fstab, рестартирайте и се насладете на файловете си :-)
