ఉబుంటులో mdadm అర్రేలో విఫలమైన డ్రైవ్‌ను భర్తీ చేయడం
ప్రచురణ: 15 ఫిబ్రవరి, 2025 10:03:20 PM UTCకి
మీరు mdadm RAID శ్రేణిలో డ్రైవ్ వైఫల్యం చెందే భయంకరమైన పరిస్థితిలో ఉంటే, ఉబుంటు సిస్టమ్‌లో దానిని సరిగ్గా ఎలా భర్తీ చేయాలో ఈ వ్యాసం వివరిస్తుంది.
Replacing a Failed Drive in an mdadm Array on Ubuntu
ఈ పోస్ట్‌లోని సమాచారం ఉబుంటు 18.04 మరియు దాని రిపోజిటరీలలో చేర్చబడిన mdadm వెర్షన్ ఆధారంగా రూపొందించబడింది; v4.1-rc1 రాసే సమయంలో. ఇది ఇతర వెర్షన్‌లకు చెల్లుబాటు కావచ్చు లేదా చెల్లకపోవచ్చు.
ఇటీవల నా హోమ్ ఫైల్ సర్వర్‌లో అకస్మాత్తుగా డ్రైవ్ వైఫల్యం సంభవించింది, ఇందులో mdadm RAID-6 శ్రేణిలోని తొమ్మిది డ్రైవ్‌లు ఉంటాయి. అది ఎల్లప్పుడూ భయానకంగా ఉంటుంది, కానీ అదృష్టవశాత్తూ నేను మరుసటి రోజు డెలివరీ చేయబడిన రీప్లేస్‌మెంట్ డ్రైవ్‌ను త్వరగా సోర్స్ చేయగలిగాను, తద్వారా నేను పునర్నిర్మాణాన్ని ప్రారంభించగలిగాను.
నేను మొదట ఫైల్ సర్వర్‌ను సెటప్ చేసినప్పుడు నేను కొంచెం చౌకగా ఉన్నాను; డ్రైవ్‌లలో రెండు మాత్రమే నిజమైన NAS డ్రైవ్‌లు (సీగేట్ ఐరన్‌వోల్ఫ్), మిగిలినవి డెస్క్‌టాప్ డ్రైవ్‌లు (సీగేట్ బార్రాకుడా). ఆశ్చర్యపోనవసరం లేదు, ఇది దాదాపు మూడు సంవత్సరాల సర్వీస్ తర్వాత వదులుకున్న డెస్క్‌టాప్ డ్రైవ్‌లలో ఒకటి. ఇది పూర్తిగా డెడ్ అయింది; దానిని డెస్క్‌టాప్ USB ఎన్‌క్లోజర్‌కి తరలించిన తర్వాత నాకు దాని నుండి వచ్చినదంతా భయానకమైన క్లిక్ సౌండ్ మరియు ఉబుంటు 20.04 లేదా విండోస్ 10 దానిని గుర్తించలేకపోయాయి.
ఓహ్, రీప్లేస్‌మెంట్ పార్ట్‌కి వెళ్తాను (అవును, నేను కొన్న కొత్త డ్రైవ్ ఐరన్‌వోల్ఫ్, నేర్చుకున్న పాఠం) - నడుస్తున్న శ్రేణిలో డ్రైవ్‌ను కోల్పోవడం ఎంత భయానకంగా ఉంటుందో, దానిని భర్తీ చేయడానికి సరైన విధానం మీకు తెలియకపోతే అది మరింత భయానకంగా ఉంటుంది. mdadm శ్రేణిలో విఫలమైన డ్రైవ్‌ను నేను భర్తీ చేయాల్సి రావడం ఇదే మొదటిసారి కాదు, కానీ అదృష్టవశాత్తూ ఇది చాలా అరుదు కాబట్టి నేను సాధారణంగా సరైన ఆదేశాల కోసం వెతకాలి. ఈసారి భవిష్యత్తు సూచన కోసం నా స్వంత చిన్న గైడ్‌ను తయారు చేయాలని నిర్ణయించుకున్నాను.
కాబట్టి, ముందుగా, మీకు mdadm నుండి భయంకరమైన ఫెయిల్ ఈవెంట్ ఈ-మెయిల్ వచ్చినప్పుడు, మీరు ఏ డ్రైవ్ విఫలమైందో గుర్తించాలి. ఖచ్చితంగా, ఇది మీకు పరికరం పేరును తెలియజేస్తుంది (నా విషయంలో /dev/sdf), కానీ మెషిన్ బూట్ అయినప్పుడు ఆ పేర్లు మారవచ్చు కాబట్టి అది వాస్తవానికి ఏ భౌతిక డ్రైవ్ అనేది స్పష్టంగా తెలియకపోవచ్చు.
ఏ పరికరం పేరు విఫలమైందో కూడా మీకు ఖచ్చితంగా తెలియకపోతే, మీరు దానిని కనుగొనడానికి కింది ఆదేశాన్ని ఉపయోగించవచ్చు (/dev/md0ని మీ RAID పరికరంతో భర్తీ చేయండి):
చెప్పినట్లుగా, నా విషయంలో అది /dev/sdf, కాబట్టి దానితో కొనసాగిద్దాం.
అప్పుడు, మీరు ఈ ఆదేశాన్ని జారీ చేయడం ద్వారా విఫలమైన డ్రైవ్ యొక్క సీరియల్ నంబర్‌ను కనుగొనడానికి ప్రయత్నించవచ్చు:
(smartctl కనుగొనబడకపోతే, మీరు ఉబుంటులో smartmontools ప్యాకేజీని ఇన్‌స్టాల్ చేయాలి)
ఆ తరువాత సీరియల్ నంబర్‌ను డ్రైవ్‌లలోని భౌతిక లేబుల్‌పై ఉన్న సీరియల్ నంబర్‌లతో పోల్చి, ఏది విఫలమైందో గుర్తించవచ్చు.
ఈసారి, నేను అంత అదృష్టవంతుడిని కాదు. డ్రైవ్ పూర్తిగా డెడ్ అయింది మరియు సీరియల్ నంబర్‌తో సహా SMART లేదా ఇతర డేటాను అందించడానికి కూడా నిరాకరించింది.
నాకు సర్వర్‌కి భౌతిక యాక్సెస్ ఉంది (మీరు భౌతిక డ్రైవ్‌ను మీరే భర్తీ చేయబోతున్నట్లయితే మీకు ఇది నిజంగా అవసరం అని నేను అనుకుంటున్నాను ;-)) మరియు డిస్క్ విఫలమైనప్పుడు సర్వర్ వాస్తవానికి నడుస్తోంది (మరియు RAID-6 రిడెండెన్సీకి ధన్యవాదాలు బాగానే నడుస్తూనే ఉంది), నేను నిజంగా ప్రాచీనమైన, కానీ వాస్తవానికి చాలా ప్రభావవంతమైన మరియు స్పష్టమైన పద్ధతిని ఎంచుకున్నాను, ఇది సర్వర్‌కు పెద్ద ఫైల్‌ను కాపీ చేసి ఏ HDD లైట్ ఫ్లికర్ చేయలేదని చూడటం. కొన్ని సెకన్లలోనే నేను అపరాధిని గుర్తించాను.
ఇప్పుడు, భౌతిక డ్రైవ్‌ను బయటకు తీసే ముందు, ఈ ఆదేశాన్ని జారీ చేయడం ద్వారా mdadmకి ఈ ఉద్దేశ్యాన్ని అధికారికంగా తెలియజేయడం మంచిది (సముచితంగా పరికర పేర్లను మీ స్వంత వాటితో భర్తీ చేయండి):
విజయవంతమైతే, mdadm డ్రైవ్‌ను "హాట్ రిమూవ్డ్" అని సందేశంతో ప్రత్యుత్తరం ఇస్తుంది, ఎందుకంటే ఆ సమయంలో వర్చువల్ రైడ్ పరికరం వాస్తవానికి రన్ అవుతోంది.
"డివైస్ లేదా రిసోర్స్ బిజీ" లాంటి ఎర్రర్ మెసేజ్ తో అది విఫలమైతే, mdadm డ్రైవ్ పూర్తిగా విఫలమైనట్లు నమోదు చేయకపోవచ్చు. అలా చేయడానికి, ఈ ఆదేశాన్ని జారీ చేయండి (మళ్ళీ, తగిన విధంగా పరికర పేర్లను మీ స్వంత పేర్లతో భర్తీ చేయాలని గుర్తుంచుకోండి):
ఆ తరువాత, మీరు మునుపటి ఆదేశంతో శ్రేణి నుండి పరికరాన్ని తీసివేయగలరు.
ఇప్పుడు డ్రైవ్‌ను నిజంగా మార్చాల్సిన సమయం ఆసన్నమైంది. మీ మెషిన్ మరియు కంట్రోలర్ హాట్ స్వాపింగ్‌కు మద్దతు ఇస్తాయని మీరు నిజంగా, నిజంగా - నిజంగా - ఖచ్చితంగా ఉంటే, మీరు మెషిన్‌ను షట్ డౌన్ చేయకుండానే దీన్ని చేయవచ్చు. నిజమైన, సరైన సర్వర్ హార్డ్‌వేర్‌పై నడుస్తున్న క్లిష్టమైన ఉత్పత్తి వ్యవస్థలను నిర్వహించడానికి అదే మార్గం, అది నిర్వహించగలదని మీకు ఖచ్చితంగా తెలుసు. నా హోమ్ ఫైల్ సర్వర్ PCIe స్లాట్‌లలో రెండు సెమీ-నామ్ SATA కంట్రోలర్‌లతో కూడిన కన్స్యూమర్ గ్రేడ్ డెస్క్‌టాప్ మదర్‌బోర్డ్‌పై ఆధారపడి ఉంటుంది, అయితే మరిన్ని SATA పోర్ట్‌లను అందిస్తుంది.
SATA సాధారణంగా హాట్ స్వాపింగ్‌కు మద్దతు ఇవ్వాలి అయినప్పటికీ, ఈ సెటప్‌లో నేను ఏమీ రిస్క్ చేయబోవడం లేదు, కాబట్టి డ్రైవ్‌ను భర్తీ చేస్తున్నప్పుడు మెషిన్‌ను షట్ డౌన్ చేయాలని ఎంచుకున్నాను.
అలా చేసే ముందు, /etc/fstab ఫైల్‌లో raid పరికరాన్ని వ్యాఖ్యానించడం మంచిది, తద్వారా ఉబుంటు తదుపరి బూట్‌లో దానిని స్వయంచాలకంగా మౌంట్ చేయడానికి ప్రయత్నించదు, ఎందుకంటే అది డీగ్రేడెడ్ RAID శ్రేణి కారణంగా హ్యాంగ్ అయి మిమ్మల్ని రికవరీ మోడ్‌లోకి బలవంతం చేయవచ్చు. ఇది డెస్క్‌టాప్ సిస్టమ్ అయితే అది పెద్ద సమస్య కాకపోవచ్చు, కానీ నేను ఈ సర్వర్‌ను మానిటర్ లేదా కీబోర్డ్ జోడించకుండా హెడ్‌లెస్‌గా నడుపుతున్నాను, కాబట్టి ఇది కొంచెం ఇబ్బందిగా ఉంటుంది.
మెరిసే కొత్త డ్రైవ్ ఇన్‌స్టాల్ చేయబడి మెషీన్‌ను బూట్ చేసిన తర్వాత, దానిని గుర్తించడానికి lsblk లేదా ఇతర మార్గాలను ఉపయోగించండి. మీరు వేరే ఏదైనా మార్చకపోతే, అది బహుశా (కానీ తప్పనిసరిగా కాదు) మీరు భర్తీ చేసిన డ్రైవ్ పేరునే పొందుతుంది. నా విషయంలో అది అలాగే ఉంది, కాబట్టి కొత్తదాన్ని /dev/sdf అని కూడా పిలుస్తారు.
నా శ్రేణి భౌతిక పరికరాలపై కాకుండా విభజనలపై ఆధారపడి ఉంటుంది కాబట్టి, అవి సరిగ్గా ఒకేలా ఉన్నాయని నిర్ధారించుకోవడానికి నేను వర్కింగ్ డ్రైవ్ నుండి కొత్త డ్రైవ్‌కి విభజన పట్టికను కాపీ చేయాల్సి వచ్చింది. బదులుగా మీరు మీ శ్రేణిని భౌతిక పరికరాల్లో అమలు చేస్తే, మీరు ఈ దశను దాటవేయవచ్చు.
నేను ఈ ప్రయోజనం కోసం sgdiskని ఉపయోగించాను, విభజన పట్టికను /dev/sdc నుండి /dev/sdfకి కాపీ చేసాను. తగిన విధంగా మీ స్వంత పేర్లకు సరిపోయేలా పరికర పేర్లను మార్చాలని నిర్ధారించుకోండి.
ఇక్కడ ఆర్డర్ గమనించండి : మీరు ముందుగా "to" డ్రైవ్‌ను జాబితా చేయండి! ఇది నాకు కొంచెం విరుద్ధంగా ఉంది, కానీ మీరు దానిని సరిగ్గా పొందారని నిర్ధారించుకోండి, తద్వారా మీరు శ్రేణిలో మరొక డ్రైవ్ వైఫల్యాన్ని పొందలేరు ;-)
అప్పుడు UUID సంఘర్షణలను నివారించడానికి, కొత్త డ్రైవ్ కోసం కొత్త UUID లను రూపొందించండి:
ఇప్పుడు చివరకు కొత్త డ్రైవ్‌ను శ్రేణికి జోడించి, పునర్నిర్మాణ పార్టీని ప్రారంభించాల్సిన సమయం ఆసన్నమైంది! (సరే, ఇది నిజంగా పార్టీ కాదు, ఇది నిజానికి చాలా నెమ్మదిగా మరియు ఆందోళన కలిగించే ప్రక్రియ, ఎందుకంటే మీరు నిజంగా, ఈ సమయంలో మరొక డ్రైవ్ విఫలమవ్వాలని కోరుకోరు. అయితే, బీర్ సహాయపడవచ్చు)
ఏదేమైనా, శ్రేణికి కొత్త డ్రైవ్‌ను జోడించడానికి, ఈ ఆదేశాన్ని జారీ చేయండి (మళ్ళీ, తగిన విధంగా పరికర పేర్లను మీ స్వంత పేర్లతో భర్తీ చేయాలని నిర్ధారించుకోండి):
అన్నీ సరిగ్గా జరిగితే, డ్రైవ్ ఎటువంటి ఇబ్బంది లేకుండా శ్రేణికి జోడించబడుతుంది. ఇది వాస్తవానికి డిఫాల్ట్‌గా "హాట్ స్పేర్"గా జోడించబడిందని నేను నమ్ముతున్నాను, కానీ ఈ శ్రేణిలో డిస్క్ (విఫలమైన డిస్క్) లేకపోవడంతో, దానిని వెంటనే ఉపయోగంలోకి తెస్తారు మరియు పునర్నిర్మాణ ప్రక్రియ ప్రారంభమవుతుంది.
మీరు దానిపై ఈ క్రింది విధంగా నిఘా ఉంచవచ్చు:
దీనికి బహుశా కొంత సమయం పడుతుంది; నా లోలీ సర్వర్‌లో (ఎక్కువగా కన్స్యూమర్ గ్రేడ్ హార్డ్‌వేర్ మరియు డెస్క్‌టాప్ డ్రైవ్‌ల ఆధారంగా) ఇది 100 MB/సెకను కంటే తక్కువకు చేరుకోగలిగింది. ఇది RAID-6 అని గుర్తుంచుకోండి, కాబట్టి పునర్నిర్మాణంతో చాలా పారిటీ లెక్కలు ఉంటాయి; RAID-10 చాలా వేగంగా ఉండేది. ఈ ప్రత్యేక యంత్రంలో AMD A10 9700E క్వాడ్ కోర్ CPU ("E" అంటే ఇది అండర్-క్లాక్డ్ ఎనర్జీ ఎఫిషియెన్సీ మోడల్, అంటే సూపర్ ఫాస్ట్ కాదు) ఉంది, ఏమి ఆశించాలో మీకు ఒక ఆలోచన ఇవ్వడానికి. నా సెటప్‌లోని తొమ్మిది 8 TB డ్రైవ్‌లతో, పూర్తి పునర్నిర్మాణానికి 24 గంటల కంటే ఎక్కువ సమయం పట్టింది.
పునర్నిర్మాణ సమయంలో, మీరు శ్రేణిపై ఫైల్‌సిస్టమ్‌ను మౌంట్ చేయవచ్చు మరియు మీరు కోరుకుంటే దానిని సాధారణంగా ఉపయోగించవచ్చు, కానీ అది పూర్తయ్యే వరకు దానిని పునర్నిర్మాణానికి వదిలివేయడానికి నేను ఇష్టపడతాను. ఒక డ్రైవ్ విఫలమైతే, మరొక డ్రైవ్ త్వరలో అనుసరించవచ్చని గుర్తుంచుకోండి, కాబట్టి మీరు పునర్నిర్మాణం వీలైనంత త్వరగా పూర్తి చేయాలని కోరుకుంటారు, ఆ సమయంలో మరొక డ్రైవ్ విఫలం కాకూడదని మీరు కోరుకుంటారు. కాబట్టి, ఖచ్చితంగా అవసరం లేని ఇతర IOలతో దానిపై భారం పడకండి.
అది పూర్తయిన తర్వాత, దాన్ని మీ /etc/fstab ఫైల్‌కి తిరిగి జోడించి, రీబూట్ చేసి మీ ఫైల్‌లను ఆస్వాదించండి :-)