Skip to content

RAID 5 અથવા RAID 6 ડિગ્રેડેડ એરે પુનઃનિર્માણ દરમિયાન બીજી ડ્રાઇવ નિષ્ફળતા સાથે (શા માટે ક્યારેય CHKDSK અથવા fsck, ddrescue સેક્ટર ક્લોનિંગ, અને mdadm રીડ-ઓનલી એસેમ્બલી ચલાવશો નહીં)

Emergency numbers differ by country. This page uses 911, the number for the United States and Canada. Many other countries use 112, 999, or another number. Find the number for your country.

નિષ્ફળ હાર્ડ ડ્રાઈવને ડીગ્રેડેડમાં બદલવી RAID 5 અથવા RAID 6 સ્ટોરેજ સર્વર, સિનોલોજી ડિસ્કસ્ટેશન, QNAP NAS, Linux mdadm એરે, અથવા ડેલ PERC / એચપી Smart Array / LSI MegaRAID હાર્ડવેર કંટ્રોલર માત્ર બીજા બાકી મેમ્બર ડ્રાઈવ થ્રો જોવા માટે UNC (અયોગ્ય વાંચવામાં ભૂલ) ખરાબ ક્ષેત્રો, Pending Sectors, અથવા પર ઑફલાઇન છોડો 42% પેરિટી પુનઃનિર્માણ એ એન્ટરપ્રાઇઝ અને હોમ-લેબ કમ્પ્યુટિંગમાં સૌથી ખતરનાક સ્ટોરેજ કટોકટી પૈકીની એક છે. સિંગલ-પેરિટીમાં RAID 5 એરે (N - 1 ફોલ્ટ ટોલરન્સ), રિપ્લેસમેન્ટ ડિસ્કના ગાણિતિક XOR પુનઃનિર્માણ માટે દરેક એક સેક્ટરને વાંચવાની જરૂર છે (LBA 0 અંતિમ LBA સુધી) બાકીના 100 ટકા સુધી N - 1 સભ્ય એક સાથે ડ્રાઇવ કરે છે. જ્યારે આધુનિક ઉચ્ચ ક્ષમતા 8 TB થી 24 TB હિલીયમ ડ્રાઈવો (સમાન મેન્યુફેક્ચરિંગ બેચમાંથી ખરીદેલી અને સમાન થર્મલ અને વાઈબ્રેશન કલાકોને આધિન) મલ્ટિ-ટેરાબાઈટ સિક્વન્શિયલ રિબિલ્ડ રીડમાંથી પસાર થાય છે, એક જ સુપ્ત મીડિયા ખામી (URE) અથવા બીજી ડ્રાઇવ પર નબળા રીડ હેડને કારણે RAID નિયંત્રક પુનઃનિર્માણને અટકાવે છે, બીજી ડ્રાઇવને ** તરીકે બહાર કાઢે છે.Faulty / Crashed**, અને સમગ્ર સ્ટોરેજ પૂલને ચિહ્નિત કરો Offline / Crashed / Superblock Event Count Mismatch

ગભરાશો નહીં, અને ફાઇલસિસ્ટમ રિપેર યુટિલિટીઝને બીજા પુનઃનિર્માણ અથવા ચલાવવા માટે દબાણ કરશો નહીં (fsck, e2fsck, xfs_repair, અથવા વિન્ડોઝ CHKDSK). જ્યારે બીજી ડ્રાઇવ ઇન કરો ત્યારે પણ RAID 5 (અથવા ત્રીજી ડ્રાઇવ ઇન કરો RAID 6) વિકાસ પામે છે 50 થી 5,000 ખરાબ ક્ષેત્રો અને એરેમાંથી બહાર કાઢવામાં આવે છે, તે "નિષ્ફળ" સેકન્ડ ડ્રાઇવ પરના 99.9999 ટકા સેક્ટર હજુ પણ 100 ટકા વાંચી શકાય છે. એરેને તરત જ અટકાવીને, દરેક અસ્થિર સભ્ય ડિસ્કને સેક્ટર-બાય-સેક્ટર કલોનીંગ કરીને ** નો ઉપયોગ કરીને તંદુરસ્ત ફાજલ ડ્રાઈવો પરGNU ddrescue, અને ** માં ક્લોન કરેલી છબીઓને એસેમ્બલ કરવીRead-Only / --assume-clean ઓવરલે મોડ (mdadm + dmsetup કૉપિ-ઑન-રાઇટ લૂપ ઓવરલે), તમે ફાઇલસિસ્ટમને સુરક્ષિત રીતે માઉન્ટ કરી શકો છો અને વર્ચ્યુઅલ રીતે દરેક ફાઇલને અકબંધ કૉપિ કરી શકો છો. NAS એપ્લાયન્સ વિશિષ્ટતાઓ અને હાર્ડવેર નિયંત્રક નિષ્ફળતાઓ માટે, અમારા સાથી માર્ગદર્શિકાઓ વાંચો RAID 5 અથવા RAID 6 સિનોલોજી, QNAP, અથવા TrueNAS મલ્ટીપલ ડ્રાઇવ ડ્રોપ, RAID નિયંત્રક કાર્ડ મૃત્યુ અને વિદેશી રૂપરેખાંકન આયાત, અને NAS RAID એરે ડિગ્રેડેડ અને ZFS/Btrfs પુનઃપ્રાપ્તિ. જો તમારી સર્વર નિષ્ફળતા જીવન-સુરક્ષા પ્રણાલી અથવા તબીબી માળખાને અસર કરે છે, તો તમારા સ્થાનિક કટોકટી નંબરનો સંપર્ક કરો (911 યુનાઇટેડ સ્ટેટ્સ અને કેનેડામાં, 112 સમગ્ર યુરોપિયન યુનિયનમાં, 999 યુનાઇટેડ કિંગડમમાં) અથવા અમારી ડિરેક્ટરી તપાસો કટોકટી નંબરો.

હવે આ કરો

  1. કોઈપણ સક્રિય પેરિટી રિબિલ્ડ અથવા સ્ક્રબ તરત જ બંધ કરો અને એરેને સ્વચ્છ રીતે પાવર ડાઉન કરો (અથવા જો ડ્રાઇવ યાંત્રિક ક્લિક અથવા સ્ક્રેપિંગ અવાજો કરતી હોય તો SATA/SAS બેકપ્લેન પાવરને ડિસ્કનેક્ટ કરો):
  2. શા માટે સ્ટોલિંગ પુનઃનિર્માણ ચાલુ રાખવા દેવાથી એરેનો નાશ થાય છે: જ્યારે સભ્ય ડ્રાઇવ ખરાબ સેક્ટર પેચને હિટ કરે છે (LBA વાંચવાનો સમય સમાપ્ત થયો છે) અથવા તેનું વાંચન/લેખવાનું હેડ છે (media scratch, RAID કંટ્રોલરને કલાકો સુધી સેક્ટરમાં પુનઃપ્રયાસ કરતા છોડીને સમગ્ર ટ્રેક સિલિન્ડર પર માઇક્રોસ્કોપિક મેગ્નેટિક પ્લેટર કોટિંગને ધૂળમાં પીસીને પુનઃપ્રાપ્ત કરી શકાય છે. 20-sector આપત્તિજનક ફુલ-પ્લેટર હેડ ક્રેશમાં ખામી.
  3. ક્યારેય દોડશો નહીં CHKDSK /f, fsck -y, e2fsck, btrfs check --repair, અથવા xfs_repair ડિગ્રેડેડ, આઉટ-ઓફ-સિંક, અથવા અર્ધ-રિબિલ્ટ RAID એરે પર:
  4. શા માટે CHKDSK અને fsck આઉટ-ઓફ-સિંક RAID પર 100% કાયમી ડેટા વિનાશનું કારણ બને છે: જો ડ્રાઇવ 2 મંગળવારના રોજ ડ્રોપ આઉટ થઈ જાય અને ગુરુવારના પુનઃનિર્માણ દરમિયાન ડ્રાઇવ 3 છોડી દેવામાં આવે, mdadm અથવા હાર્ડવેર RAID Event Counter (Update Time) તે બે ડ્રાઇવ પર હજારો વ્યવહારો દ્વારા અલગ પડે છે. જો તમે મેળ ન ખાતી ડ્રાઇવ જનરેશન અથવા ગુમ થયેલ પટ્ટાઓ સાથે એરેને ફોર્સ-એસેમ્બલ કરો અને મંજૂરી આપો fsck અથવા CHKDSK એરે પર લખવા માટે, ફાઇલસિસ્ટમ તપાસનાર ખોટી રીતે સંલગ્ન RAID પટ્ટાઓને કારણે તૂટેલા આઇનોડ વૃક્ષો જુએ છે, જેમાં લાખો માન્ય ડિરેક્ટરી એન્ટ્રીઓ કાઢી નાખે છે. lost+found, અને એરેમાં દરેક ડિસ્ક પર દૂષિત સમાનતા સાથે સારી ડેટા સ્ટ્રાઇપ્સ પર ફરીથી લખે છે.
  5. ક્યારેય ક્લિક કરશો નહીં "Create Array", "Initialize", અથવા "Clear Configuration" હાર્ડવેર RAID BIOS માં, અને ક્યારેય ચલાવશો નહીં mdadm --create વગર --assume-clean અને કોપી-ઓન-રાઈટ (COW) લૂપ ઓવરલે:
  6. ધોરણ ચલાવવું mdadm --create (વિના --assume-clean અને ચોક્કસ ચંક સાઈઝ, લેઆઉટ અને ડેટા ઓફસેટ સાથે મેળ ખાતા) તરત જ બધી ડિસ્ક પર નવી પેરિટી સ્ટ્રાઈપ્સ લખવાનું શરૂ કરે છે, જો કોઈ એક પેરામીટર (512K વિ. 64K ભાગ left-symmetric વિ. left-asymmetric, અથવા 2048s વિ. 262144s ડેટા ઓફસેટ) એક સેક્ટર દ્વારા પણ ખોટું છે.
  7. દરેક ભૌતિક હાર્ડ ડ્રાઈવ સ્લોટને લેબલ કરો (Bay 0 / Bay 1 / Bay 2 / Bay 3 અને સીરીયલ નંબર) ચેસીસમાંથી એક ડ્રાઇવને બહાર કાઢતા પહેલા કાયમી માર્કર અથવા ટેપ સાથે:
  8. દરેક ડ્રાઇવના ટોચના લેબલ પર ચોક્કસ બે નંબર અને સીરીયલ નંબર લખો. ભૌતિક ઉઘાડી હુકમ જાણીને અને ચકાસણી mdadm --examine મેટાડેટા પાછળથી સ્ટ્રાઇપ-ઓર્ડર પુનઃનિર્માણના કલાકો બચાવે છે.
  9. **નિષ્ફળ ડ્રાઇવ(ઓ)ને સેક્ટર-બાય-સેક્ટરનો ઉપયોગ કરીને તંદુરસ્ત નવી ડ્રાઇવ માટે ક્લોન કરો GNU ddrescue કોઈપણ RAID એસેમ્બલીનો પ્રયાસ કરતા પહેલા સીધા મધરબોર્ડ SATA/HBA પોર્ટ પર (મેપફાઈલ સાથે) **:
  10. શારીરિક રીતે ડાઇંગ ડ્રાઇવનો ઉપયોગ કરીને RAID એરેને એસેમ્બલ અથવા માઉન્ટ કરવાનો ક્યારેય પ્રયાસ કરશો નહીં. નિષ્ફળ ડ્રાઇવને નોન-RAID SATA/AHCI અથવા LSI સાથે કનેક્ટ કરો IT-Mode Linux રેસ્ક્યૂ વર્કસ્ટેશન પર HBA પોર્ટ, OS ઑટો-માઉન્ટિંગને અક્ષમ કરો અને ચલાવો ddrescue -f -n /dev/sdX /dev/sdY rescue_driveX.map તેથી ખરાબ સેક્ટર ઝોનને સ્પર્શતા પહેલા સ્વસ્થ ઝડપી ક્ષેત્રોને પાસ વનમાં ખાલી કરવામાં આવે છે.
  11. ક્લોન કરેલી ડ્રાઇવને એસેમ્બલ કરો Read-Only મોડ (mdadm --assemble --readonly અથવા ઉપયોગ કરીને dmsetup / losetup રેમ/ફાઇલ ઓવરલે):
  12. નિકાલજોગ કોપી-ઓન-રાઈટ મૂકીને (COW) દરેક ક્લોન કરેલ સભ્ય ડિસ્કની ટોચ પર ફાઇલને ઓવરલે કરો, તમે એરેને ટેસ્ટ-માઉન્ટ કરી શકો છો, ફરીથી ચલાવી શકો છો ext4 અથવા XFS જર્નલ, અથવા વર્ચ્યુઅલ પુનઃનિર્માણનું પણ પરીક્ષણ કરો જ્યારે ખાતરી આપે છે કે તમારા અંતર્ગત ડિસ્ક ક્લોન્સ પર શૂન્ય બાઇટ્સ ક્યારેય સંશોધિત થાય છે.

Danger

** "આઉટ-ઓફ-ઓર્ડર ડ્રાઇવ ફોર્સ" ટ્રેપ (Stale Drive Overwriting Fresh Drives): ધારો કે તમારી પાસે 4-ડ્રાઈવ છે RAID 5 (Disk 1, Disk 2, Disk 3, Disk 4). Disk 3 6 મહિના પહેલા નિષ્ફળ થયું, અને તમે તેને ક્યારેય બદલ્યું નથી (6 મહિના માટે ડિગ્રેડેડ ચાલી રહ્યું છે). આજે, Disk 2 100 ખરાબ ક્ષેત્રોનો વિકાસ કરે છે અને ડ્રોપ આઉટ કરે છે. ** 6 મહિનાના બાળકને ક્યારેય દબાણ કરશો નહીં Disk 3 પુનઃનિર્માણ માટે પાછા ઑનલાઇન Disk 2. જો તમે ઉપયોગ કરો છો Disk 1 + Disk 3 (6 months stale) + Disk 4 એરેને ફરીથી બનાવવા અથવા માઉન્ટ કરવા માટે, છેલ્લા 6 મહિનામાં બનાવેલ અથવા સંશોધિત દરેક ફાઇલ વાંચી ન શકાય તેવા બાઈનરી ગાર્બેજમાં દૂષિત થઈ જશે. તમારે *ક્લોન કરવું પડશે Disk 2 (ડ્રાઇવ જે નિષ્ફળ આજે) સાથે ddrescue અને એસેમ્બલ Disk 1 + Cloned Disk 2 + Disk 4


ડિસિઝન ટ્રી: RAID 5 અથવા RAID 6 એરેને બચાવવા જ્યારે બીજી ડ્રાઈવ પુનઃનિર્માણ દરમિયાન નિષ્ફળ જાય

આ ફોરેન્સિક સ્ટોરેજ પુનઃપ્રાપ્તિ વર્કફ્લોને અનુસરો એક પણ હયાત પટ્ટા ગુમાવ્યા વિના તમારા એરેને પુનઃપ્રાપ્ત કરવા માટે:

flowchart TD
    Start["RAID 5 (2જી ડ્રાઇવ) અથવા RAID 6 (3જી ડ્રાઇવ) નિષ્ફળ / પુનઃનિર્માણ દરમિયાન ઑફલાઇન ડ્રોપ"] --> StopNow["પગલું 1: તાત્કાલિક પુનઃનિર્માણને બંધ કરો અને પાવર ડાઉન એરે (નિષ્ફળ ડ્રાઇવ પર પ્લેટર સ્કોરિંગ અટકાવો)"]

    StopNow --> SoundCheck{"શું ફેઇલિંગ ડ્રાઇવથી મોટેથી ક્લિકિંગ, બીપિંગ અથવા ગ્રાઇન્ડીંગ અવાજો આવે છે?"}

    SoundCheck -->|"હા: મિકેનિકલ હેડ ક્રેશ / સ્ટિક્શન"| CleanRoom["સ્ટોપ: ફરીથી ચાલુ કરવા માટે પાવર ન કરો. ક્લોન પર ઇમેજ બનાવવા માટે ક્લીનરૂમ લેબને માત્ર મિકેનિકલી ફેઈલ ડ્રાઈવ (પ્લસ 1 હેલ્ધી ડ્રાઈવ ફોર સ્ટ્રાઈપ રેફરન્સ) મોકલો"]

    SoundCheck -->|"ના: સરળતાથી સ્પિન કરે છે, ખરાબ ક્ષેત્રોને કારણે નિષ્ફળ (UNC / બાકી / સમયસમાપ્ત)"| LabelDrives["પગલું 2: દરેક ડ્રાઇવને તેના ચોક્કસ બે નંબર અને સીરીયલ નંબર સાથે લેબલ કરો -> ડાયરેક્ટ SATA / IT-મોડ HBA દ્વારા Linux વર્કસ્ટેશન સાથે કનેક્ટ કરો"]

    LabelDrives --> InspectMeta["બધી ડ્રાઇવ્સ પર 'mdadm --examine /dev/sd*' અને 'smartctl -a /dev/sd*' ચલાવો (રેકોર્ડ અપડેટ સમય, ઇવેન્ટ્સ કાઉન્ટર, ભૂમિકા, ભાગનું કદ, લેઆઉટ, ડેટા ઑફસેટ)"]

    InspectMeta --> CloneDrives["પગલું 3: 'ddrescue -f -n' (પહેલા ફાસ્ટ પાસ, પછી મેપફાઈલ સાથે સ્ક્રેપ પાસ) નો ઉપયોગ કરીને દરેક ડિગ્રેડેડ / બેડ-સેક્ટર ડ્રાઇવને તંદુરસ્ત સ્પેર ડ્રાઇવ પર ક્લોન કરો."]

    CloneDrives --> PickFreshest["N-1 (RAID 5) અથવા N-2 (RAID 6) ડ્રાઇવ્સને સૌથી વધુ / સૌથી તાજેતરના 'ઇવેન્ટ્સ' કાઉન્ટર સાથે ઓળખો (ફ્રેશ ડ્રાઇવ સાથે જૂની જૂની ડ્રોપ કરેલી ડ્રાઇવને ક્યારેય મિક્સ કરશો નહીં)"]

    PickFreshest --> CowOverlay["પગલું 4: ક્લોન કરેલી ડ્રાઇવ્સ પર ફક્ત વાંચવા માટે લૂપ / 'dmsetup' કૉપિ-ઑન-રાઇટ (COW) ઓવરલે બનાવો જેથી મૂળ ક્લોન્સમાં ફેરફાર કરી શકાય નહીં"]

    CowOverlay --> AssembleRO["ઓવરલે ઉપકરણો પર 'mdadm --assemble --force --readonly' ચલાવો -> માઉન્ટ ફાઇલસિસ્ટમ રીડ-ઓન્લી ('mount -o ro,noload') -> બધા જટિલ ડેટાને બાહ્ય સ્ટોરેજમાં કૉપિ કરો"]

તબક્કો 1: RAID પુનઃનિર્માણ દરમિયાન શા માટે બીજી ડ્રાઇવ નિષ્ફળ થાય છે તે સમજવું (XOR Parity Math અને Event Counters)

શા માટે તમારું અરે મધ્ય પુનઃનિર્માણમાં ક્રેશ થયું અને શા માટે તમારો ડેટા હજી પણ પુનઃપ્રાપ્ત કરી શકાય તેવો છે તે સમજવા માટે, કેવી રીતે તપાસો RAID 5 અને RAID 6 ખરેખર ડિસ્ક પર કામ કરે છે.

1. કેવી રીતે XOR સમાનતા પુનઃનિર્માણ કામ કરે છે અને શા માટે 1 ખરાબ ક્ષેત્ર સમગ્ર પુનઃનિર્માણને અટકાવે છે

4-ડ્રાઈવમાં RAID 5 એરે (Drive A, Drive B, Drive C, Drive D), ડેટાને નિશ્ચિત-કદના **ભાગોમાં ** (સામાન્ય રીતે 64 KB અથવા 512 KB) સમગ્ર ડિસ્કમાં પટ્ટાવાળી, જ્યાં દરેક હરોળમાં એક ભાગ XOR પેરિટી (P): $\(\text{Parity } P = A \oplus B \oplus C\)$ જો Drive C સંપૂર્ણપણે નિષ્ફળ જાય છે અને તમે ખાલી દાખલ કરો છો Replacement Drive C_new, RAID નિયંત્રકએ દરેક પટ્ટીઓનું પુનઃનિર્માણ કરવું આવશ્યક છે C_new ગણતરી કરીને: $\(C_{\text{reconstructed}} = A \oplus B \oplus P\)$ - ** જ્યારે શું થાય છે Drive B એક વાંચી ન શકાય તેવી હિટ 4 KB ક્ષેત્ર (UNC ભૂલ) પર 42% પુનઃનિર્માણ *: - કે સિંગલની ગણતરી કરવી 4 KB પર અવરોધિત કરો C_new, નિયંત્રક એ માન્ય વાંચ્યું હોવું આવશ્યક છે Drive A, Drive B, અને Drive D. - જ્યારે Drive B હાર્ડવેર પરત કરે છે Read Error (Sense Key 03h / 11h Unrecovered Read Error) 7 સેકન્ડ પ (TLER / ERC સમયસમાપ્ત), ઉપભોક્તા અને એન્ટરપ્રાઇઝ RAID નિયંત્રકો ઘણીવાર આપત્તિજનક ડિફોલ્ટ વર્તણૂક સાથે પ્રોગ્રામ કરવામાં આવે છે: **તે સિંગલને છોડવાને બદલે 4 KB સેક્ટર, એક શૂન્ય બ્લોક લોગિંગ, અને અન્ય સપ્ત 99.9999% પુનઃનિર્માણમાં, RAID નિયંત્રક ચિહ્નિત કરે છે Drive B તરીકે FAILED / OFFLINE અને સમગ્ર પુનઃનિર્માણને રદ કરે છે. - તે ક્ષણે, તમારી એરેમાં "નિષ્ફળ" તરીકે ચિહ્નિત થયેલ બે ડ્રાઈવો છે (Drive C જે માત્ર હતી 42% પુનઃબીલ્ડ, અને Drive B જે વાસ્તવમાં છે 99.99998% તંદુરસ્ત ક્ષેત્રો અને માત્ર 12 ખરાબ ક્ષેત્રો).

2. શા માટે Event Counters (Update Time) નક્કી કરો કે તમારે પુનઃપ્રાપ્તિ માટે કઈ ડ્રાઈવનો ઉપયોગ કરવો જોઈએ

દર વખતે એ RAID 5 અથવા RAID 6 એરે ડેટા લખે છે અથવા સ્થિતિમાં ફેરફાર કરે છે (જેમ કે ડ્રાઇવ ડ્રોપ આઉટ થાય છે), RAID મેટાડેટા (mdadm સુપરબ્લોક અથવા હાર્ડવેર DDF મેટાડેટા) 64-બીટમાં વધારો કરે છે Events કાઉન્ટર હાલમાં તમામ સક્રિય ડ્રાઈવો પર.

સરખામણી કરો mdadm --examine લાક્ષણિક 4-ડ્રાઈવનું આઉટપુટ RAID 5 આપત્તિ જ્યાં sdb ગઈકાલે નિષ્ફળ (Events: 10450) અને sdc આજના પુનઃનિર્માણ દરમિયાન છોડી દીધું (Events: 10892):

ભૌતિક ડ્રાઈવ અરેમાં ભૂમિકા Update Time Events કાઉન્ટર શારીરિક સ્વાસ્થ્ય અને તેમાં શું છે
/dev/sda (ખાડી 1) Active device 0 Today 14:22:10 10892 100% સ્વસ્થ અને વર્તમાન: આજે પુનઃનિર્માણ ક્રેશ થયું તે ચોક્કસ સેકન્ડ સુધીના દરેક લખાણ સમાવે છે.
/dev/sdb (ખાડી 2) spare / faulty (નવી ડિસ્ક દ્વારા બદલી) Yesterday 09:15:00 10450 (વાસી) ગઈકાલે નિષ્ફળ: ડેટાબેઝ લખવાના 29 કલાક ખૂટે છે, અથવા નવી ડિસ્ક દ્વારા બદલવામાં આવે છે જે ફક્ત 42% પુનઃનિર્માણ (Reshape/Rebuild Pos).
/dev/sdc (Bay 3) faulty (Dropped at 42% rebuild) Today 14:22:09 10890 (Off by 2) 99.999% Healthy & Current: Only kicked out 1 second before /dev/sda અને /dev/sdd because it hit 8 bad sectors during the rebuild read.
/dev/sdd (Bay 4) Active device 3 Today 14:22:10 10892 100% સ્વસ્થ અને વર્તમાન: આજે પુનઃનિર્માણ ક્રેશ થયું તે ચોક્કસ સેકન્ડ સુધીના દરેક લખાણ સમાવે છે.
  • The Golden Rule of RAID Recovery from the table above:
  • Notice that /dev/sda (10892), /dev/sdc (10890), and /dev/sdd (10892) all have virtually identical Events counters from Today 14:22.
  • Once we clone /dev/sdc onto a healthy drive using ddrescue (recovering 99.9999% of its sectors and zero-filling the 8 unreadable sectors), we can force-assemble /dev/sda + Cloned /dev/sdc + /dev/sdd (ignoring the half-rebuilt /dev/sdb completely). That 3-drive combination gives us a 100 percent consistent, up-to-the-second degraded RAID 5 array with zero stripe tearing.

Phase 2: Step-by-step sector cloning of the failing drive with GNU ddrescue

Before you touch mdadm or any RAID assembly tool, you must clone the drive(s) that threw read errors onto healthy replacement drives of equal or larger byte capacity.

Step 1: Prepare the Linux rescue environment and disable auto-assembly

  1. Boot a Linux workstation (or boot your server from a live USB stick such as SystemRescue system-rescue.org or Ubuntu Live Server) with the drives connected to standard motherboard SATA ports or an LSI HBA in IT Mode (Non-RAID pass-through).
  2. Prevent Linux from automatically trying to assemble or mount your broken RAID array on boot:
  3. When booting SystemRescue or Ubuntu Live, check cat /proc/mdstat. If Linux auto-assembled a partial md device in the background, stop it immediately in read-only safe mode before imaging:
    mdadm --stop /dev/md*
    
  4. Identify every drive by exact model, serial number, and byte size (never guess /dev/sdX letters, because Linux reassigns drive letters across reboots):
    lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE
    
    Write down which /dev/sdX corresponds to your Failing Source Drive (for example, /dev/sdc, serial WCC4E12345) and which /dev/sdY is your Brand-New Blank Target Drive (for example, /dev/sdf, serial ZGG9988776).

Step 2: Run the 2-Stage GNU ddrescue cloning protocol (Always use a Mapfile)

Never use standard dd (dd if=/dev/sdc of=/dev/sdf) on a failing RAID drive: standard dd either aborts on the first bad sector or shifts output offsets if sync is misconfigured, and it has no memory of which sectors succeeded. GNU ddrescue (gddrescue package) uses an intelligent multi-pass state mapfile:

  1. Pass 1: Fast Non-Scraping Clone (-n flag) to Rescue 99.99% of Healthy Sectors First:
    ddrescue -f -n -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
    
  2. -f: Allows writing directly to block device /dev/sdf (triple-check that /dev/sdc is the source and /dev/sdf is the blank target).
  3. -n (--no-scrape): Tells ddrescue to immediately jump over any slow or bad sector region without grinding the read head, rescuing all healthy gigabytes at maximum speed (150 to 250 MB/s) before the drive's health worsens.
  4. /root/raid_bay3_sdc.map: Saves the exact sector progress every 30 seconds. Even if the failing drive locks up and requires a power cycle, re-running the exact same command with the .map file resumes at the exact sector where it stopped.
  5. Pass 2: Targeted Reverse/Trimming Scrape (-d -r1) to Recover Marginal Bad Sectors:
  6. Once Pass 1 finishes (pct rescued: 99.99%), lower the kernel SCSI command timeout so each bad sector fails fast (5 seconds instead of waiting 30 to 180 seconds per sector):
    echo 5 > /sys/block/sdc/device/timeout
    
  7. Run Pass 2 with direct disk access (-d) and 1 retry (-r 1):
    ddrescue -f -d -r 1 -b 4096 /dev/sdc /dev/sdf /root/raid_bay3_sdc.map
    
  8. શટ ડાઉન કરો, અસલ નિષ્ફળતાને ડિસ્કનેક્ટ કરો /dev/sdc ચલાવો, અને તેને શેલ્ફ પર સુરક્ષિત રીતે સેટ કરો: આ બિંદુથી આગળ, તમે ફક્ત તમારા તંદુરસ્ત ક્લોન સાથે કામ કરશો (/dev/sdf) અને તમારા અન્ય સ્વસ્થ સભ્ય ડ્રાઇવ.

તબક્કો 3: કોપી-ઓન-રાઈટનો ઉપયોગ કરીને સુરક્ષિત ફક્ત વાંચવા માટે RAID એસેમ્બલી (COW) ઓવરલે અને mdadm

હવે જ્યારે તમારી પાસે તંદુરસ્ત ડિસ્ક ક્લોન્સ છે, ક્યારેય દોડશો નહીં mdadm --assemble --force રક્ષણાત્મક કોપી-ઓન-રાઈટ વિના સીધી કાચી ડ્રાઈવો પર (COW) ઓવરલે અથવા --readonly ધ્વજ. શા માટે? કારણ કે --force ડ્રાઈવો પર RAID સુપરબ્લોકને ફરીથી લખે છે, અને જો ફાઈલસિસ્ટમ જર્નલ (ext4 / XFS) ખોટા ડ્રાઈવ કોમ્બિનેશનનો ઉપયોગ કરીને માઉન્ટ પર આપમેળે રિપ્લે થાય છે, તે તમારા ક્લોન્સને કાયમ માટે બદલી નાખે છે.

પગલું 1: તમામ સભ્ય ડ્રાઈવોમાં RAID મેટાડેટાનું નિરીક્ષણ કરો (mdadm --examine)

ચલાવો mdadm --examine દરેક સભ્ય ડ્રાઇવ પર (અથવા પાર્ટીશન, દા.ત., /dev/sda1 અથવા /dev/sda3 Synology/QNAP NAS ડ્રાઇવ્સ પર) અને આઉટપુટને ટેક્સ્ટ ફાઇલમાં સાચવો:

mdadm --examine /dev/sd[a,b,d,f]* > /root/raid_metadata_audit.txt
cat /root/raid_metadata_audit.txt
દરેક ડ્રાઇવ માટે ચાર નિર્ણાયક ક્ષેત્રો જુઓ: 1. Array UUID: ચકાસો કે બધી ડ્રાઈવો એ જ RAID પૂલની છે. 2. Device Role: ચોક્કસ સ્ટ્રાઇપ ઇન્ડેક્સ બતાવે છે (Active device 0, Active device 1, Active device 2, Active device 3). 3. Update Time અને Events: ઓળખો N - 1 ડ્રાઇવ્સ (માટે RAID 5) અથવા N - 2 ડ્રાઇવ્સ (માટે RAID 6) જે સૌથી વધુ/નજીક શેર કરે છે Events ગણતરી 4. Raid Level, Layout, Chunk Size, અને Data Offset: આ ચોક્કસ સંખ્યાઓ રેકોર્ડ કરો (દા.ત., Raid Level : raid5, Layout : left-symmetric, Chunk Size : 512K, Data Offset : 262144 sectors).

પગલું 2: બિન-વિનાશક કોપી-ઓન-રાઈટ બનાવો (COW) ઉપકરણ-મેપર ઓવરલે (overlay-create)

100 ટકા સલામતીની બાંયધરી આપવા માટે જેથી કરીને જો તમે એરેને ફોર્સ-એસેમ્બલ કરો અને ચલાવો mount, શૂન્ય બાઇટ્સ હંમેશા તમારી ભૌતિક હાર્ડ ડ્રાઇવ્સ પર લખવામાં આવે છે, લૂપ-બેક્ડ બનાવો dm-snapshot માં કોપી-ઓન-રાઈટ ઓવરલે /tmp (અથવા બાહ્ય સ્ક્રેચ ડ્રાઇવ પર):

# Create a small sparse COW file + loop device for each member partition (e.g., sda3, sdf3, sdd3)
mkdir -p /root/cow
for dev in sda3 sdf3 sdd3; do
    truncate -s 20G /root/cow/${dev}.cow
    loop_base=$(losetup --find --show --read-only /dev/${dev})
    loop_cow=$(losetup --find --show /root/cow/${dev}.cow)
    sz=$(blockdev --getsz /dev/${dev})
    echo "0 $sz snapshot $loop_base $loop_cow P 8" | dmsetup create ovl_${dev}
done
- આ શું કરે છે: તમારી પાસે હવે વર્ચ્યુઅલ બ્લોક ઉપકરણો છે /dev/mapper/ovl_sda3, /dev/mapper/ovl_sdf3, અને /dev/mapper/ovl_sdd3. અંતર્ગત ભૌતિક ડ્રાઈવો (sda3, sdf3, sdd3) લૉક કરેલ છે --read-only કર્નલ બ્લોક સ્તર પર. દ્વારા કરવામાં આવેલ કોઈપણ લખાણો mdadm --force, LVM, અથવા ફાઇલસિસ્ટમ જર્નલ રિપ્લે નિકાલજોગમાં હાનિકારક રીતે જાય છે /root/cow/*.cow ફાઇલો. જો કંઈપણ ખોટું થાય, તો તમે ફક્ત ઓવરલેને કાઢી નાખો અને તેને 2 સેકન્ડમાં ફરીથી બનાવો.

પગલું 3: ઓવરલે ઉપકરણો પર એરેને ફોર્સ-એસેમ્બલ કરો અને ફક્ત વાંચવા માટે માઉન્ટ કરો

  1. સૌથી તાજી એસેમ્બલ કરો N - 1 મદદથી ઉપકરણો ઓવરલે --assemble --force:
    mdadm --assemble --force --verbose /dev/md99 /dev/mapper/ovl_sda3 /dev/mapper/ovl_sdf3 /dev/mapper/ovl_sdd3
    
  2. શા માટે આપણે વાસી/અર્ધ-રીબિલ્ટ ડ્રાઇવ છોડીએ છીએ (sdb3): બળજબરી mdadm 3 અપ-ટુ-ડેટ ડ્રાઈવો સાથે એસેમ્બલ કરવા માટે (sda3, ક્લોન કરેલ sdf3, અને sdd3) લાવે છે /dev/md99 online in clean degraded mode ([U_UU]) using the exact latest Events state, while ddrescue already rescued the data from sdf3.
  3. Activate LVM (vgchange) if your NAS or server uses LVM on top of RAID (Synology SHR, QNAP, Proxmox, Ubuntu):
    pvscan
    vgscan
    vgchange -ay
    lvs
    
    (If your Synology NAS uses Btrfs on LVM or Synology Hybrid RAID, you will now see /dev/vg1000/lv અથવા /dev/vg1/volume_1 appear.)
  4. Mount the filesystem in strict Read-Only mode and evacuate your critical files immediately:
    mkdir -p /mnt/raid_rescue
    # For ext4:
    mount -o ro,noload /dev/md99 /mnt/raid_rescue
    # (Or if noload refuses due to dirty journal, mount the COW overlay normally so the journal replays into the disposable COW file)
    mount -o ro /dev/md99 /mnt/raid_rescue
    # For Btrfs (Synology NAS):
    mount -t btrfs -o ro,usebackuproot,nologreplay /dev/vg1000/lv /mnt/raid_rescue
    
  5. Copy your most critical folders first using rsync to an external backup drive:
    rsync -avP --ignore-errors /mnt/raid_rescue/ /mnt/external_backup_usb/
    

Phase 4: Rescuing Hardware RAID Controllers (Dell PERC, LSI MegaRAID, HP Smart Array, Adaptec) and ZFS / Btrfs Pools

What if your array was managed not by Linux mdadm, but by a Hardware RAID Controller Card (Dell PERC H730/H740/H755, Broadcom / LSI MegaRAID, અથવા HP Smart Array) that now reports Virtual Disk Offline અથવા Foreign Configuration Found after a second drive hiccupped during rebuild?

1. Hardware RAID Cards (Dell PERC, LSI MegaRAID, HP Smart Array)

  1. ક્યારેય ક્લિક કરશો નહીં "Clear Foreign Configuration" અથવા "Initialize Virtual Disk":
  2. In Dell PERC / LSI MegaRAID BIOS (Ctrl+R અથવા HII UEFI Configuration Utility), Clear wipes the RAID metadata from the drives, and Initialize overwrites the data stripes.
  3. If a healthy drive briefly dropped offline due to a loose backplane cable or timeout, Import Foreign Configuration attempts to bring the drive back in; however, if one drive dropped weeks ago and a second dropped today, importing both or forcing the stale drive online via the controller BIOS can corrupt the array.
  4. The Safe Software Reconstruction Method for Hardware RAID (DDF Metadata / dmraid / R-Studio / UFS Explorer):
  5. Hardware RAID cards store standard SNIA DDF (Disk Data Format) metadata in the final sectors at the end of each hard drive, and stripe data across the drives starting at sector 0 (or after a small header offset) using standard 64 KB, 128 KB, 256 KB, અથવા 512 KB chunk sizes (Left-Asymmetric અથવા Left-Symmetric).
  6. Instead of gambling with a destructive hardware RAID card BIOS:
    1. Label all drives by slot number and connect them to a standard SATA / non-RAID IT-Mode HBA પુનઃપ્રાપ્તિ વર્કસ્ટેશન પર.
    2. ** નો ઉપયોગ કરીને ખરાબ-સેક્ટર ડ્રાઇવને ક્લોન કરોGNU ddrescue** તબક્કા 2 માં બતાવ્યા પ્રમાણે.
    3. ** માં ક્લોન કરેલી ડ્રાઈવો ખોલોUFS Explorer RAID Recovery** અથવા R-Studio Technician, અથવા ઉપયોગ કરીને તેમને ફક્ત વાંચવા માટે Linux માં એસેમ્બલ કરો dmsetup / mdadm --build: આ સાધનો આપમેળે શોધે છે LSI / PERC / HP પટ્ટાનો ક્રમ, ભાગનું કદ (64K/512K), અને હાર્ડવેર RAID કાર્ડને તમારી ડ્રાઈવો પર એક પણ બાઈટ લખવા દીધા વગર 100 ટકા ફક્ત વાંચવા માટેની મેમરીમાં પેરિટી રોટેશન.

2. ટ્રુએનએએસ / ઝેડએફએસ (RAID-Z1 / RAID-Z2) અને સિનોલોજી Btrfs સ્ક્રબ/રિસિલ્વર નિષ્ફળતાઓ

જો તમારો પૂલ OpenZFS (RAID-Z1 અથવા RAID-Z2) TrueNAS અથવા Proxmox પર અને બીજી ડ્રાઇવ થ્રો CKSUM / READ એ દરમિયાન ભૂલો zpool replace રિસિલ્વર 1. ** શા માટે ZFS હાર્ડવેર RAID કરતાં વધુ સારી રીતે રિસિલ્વરિંગ દરમિયાન ખરાબ ક્ષેત્રોને હેન્ડલ કરે છે અને જ્યારે તે હજુ પણ લૉક થાય છે : - નિષ્કપટ હાર્ડવેર RAID કાર્ડ્સથી વિપરીત કે જે એક જ ખરાબ સેક્ટર પર આખી ડિસ્કને ડ્રોપ કરે છે, ZFS સ્થાનિકીકરણને ભૂતકાળમાં રિસિલ્વર કરવાનું ચાલુ રાખે છે. READ ભૂલો અને લૉગ માત્ર ચોક્કસ ક્ષતિગ્રસ્ત ફાઇલ પાથ ** માંzpool status -v - જો કે, જો બીજી નિષ્ફળ ડ્રાઇવ SATA/SAS બસ અટકી જાય (I/O timeout / હેડ થ્રેશિંગ) અથવા સંપૂર્ણપણે ઑફલાઇન ડ્રોપ્સ (UNAVAIL / FAULTED), પૂલ પ્રવેશે છે SUSPENDED રાજ્ય (pool I/O is currently suspended). 2. કેવી રીતે બચાવવું એ SUSPENDED અથવા FAULTED ZFS RAID-Z1 / RAID-Z2 પૂલ: - ** નો ઉપયોગ કરીને સ્વસ્થ રિપ્લેસમેન્ટ ડિસ્ક પર નિષ્ફળ ડ્રાઇવને સ્વચ્છ રીતે બંધ કરો.GNU ddrescue -f -n** (ZFS પાર્ટીશન લેબલમાં ચોક્કસ શામેલ છે vdev ડિસ્કની શરૂઆતમાં અને અંતમાં GUID, તેથી કાચા સેક્ટર ક્લોનને ZFS દ્વારા મૂળ તરીકે આપમેળે ઓળખવામાં આવે છે. vdev સભ્ય). - શારીરિક રીતે મૃત્યુ પામેલ ડ્રાઇવને ડિસ્કનેક્ટ કરો, છોડી દો ddrescue ક્લોન કનેક્ટેડ છે, અને ZFS પૂલને કડક વાંચવા માટેના મોડમાં આયાત કરો (readonly=on) લેખિત વ્યવહાર શરૂ કર્યા વિના અથવા રિસિલ્વર ફરી શરૂ કર્યા વિના:

zpool import -o readonly=on -f -R /mnt/zfs_rescue tank
- સાથે આયાત કરી રહ્યું છે -o readonly=on ZFS ને નવા ઉબરબ્લોક લખવાથી અથવા બેકગ્રાઉન્ડ હીલિંગ રાઇટ્સનો પ્રયાસ કરવાથી અટકાવે છે, જેનાથી તમે દરેક ડેટાસેટને સુરક્ષિત રીતે નકલ કરી શકો છો zfs send અથવા rsync શરૂઆતથી પૂલનું પુનઃનિર્માણ કરતા પહેલા.


વારંવાર પૂછાતા પ્રશ્નો

તમે ક્યારેય દોડવાનું કેમ કહ્યું CHKDSK અથવા fsck જ્યારે મારી RAID એરે ડ્રાઇવ ડ્રોપ પછી ફાઇલસિસ્ટમ ભૂલો સાથે માઉન્ટ થાય છે?

એક એકલ હાર્ડ ડ્રાઈવ પર, ચાલી રહ્યું છે CHKDSK અથવા fsck નાની ડિરેક્ટરી અસંગતતાઓનું સમારકામ. પર એ મલ્ટી-ડ્રાઈવ RAID 5 અથવા RAID 6 એરે કે જે ડબલ-ડ્રાઈવ ડ્રોપ અથવા વિક્ષેપિત પુનઃનિર્માણનો ભોગ બને છે, ફાઇલસિસ્ટમ ભૂલો લગભગ હંમેશા કારણે થાય છે RAID સ્ટ્રાઈપ મિસલાઈનમેન્ટ અથવા વાસી મેમ્બર ડ્રાઈવને ઓનલાઈન ફરજ પાડવામાં આવી રહી છે (જેનો અર્થ દરેક 3જી અથવા 4થી 64 KB ડેટાનો હિસ્સો ખોટી ડ્રાઇવ જનરેશનમાંથી વાંચવામાં આવી રહ્યો છે). જો તમે દો CHKDSK /f અથવા fsck -y ખોટી રીતે સંલગ્ન અથવા આઉટ-ઓફ-સિંક RAID એરે પર ચલાવો, તે દૂષિત મેટાડેટા તરીકે લાખો માન્ય ફાઈલોનું ખોટું અર્થઘટન કરે છે, ડિરેક્ટરી વૃક્ષોને કાપી નાખે છે, નામ વગરના ટુકડાઓને ડમ્પ કરે છે ખોવાયેલ+મળ્યું, અને તમામ ડ્રાઈવોમાં નવા પેરિટી બ્લોક્સ લખે છે, જે પછીથી યોગ્ય ડ્રાઈવ સંયોજનને ફરીથી એસેમ્બલ કરવાનું ગાણિતિક રીતે અશક્ય બનાવે છે. હંમેશા મારફતે માઉન્ટ Read-Only Copy-on-Write (ગાય) ઓવરલે પ્રથમ

What if the partially rebuilt replacement drive (42% complete) AND the second drive that failed at 42% BOTH have needed data? Can I combine them?

Yes. This is a classic "Split-Horizon / Hybrid Clone" RAID rescue. ધારો ડ્રાઇવ 2 સોમવારે સંપૂર્ણપણે મૃત્યુ પામ્યા, તમે દાખલ કરો New Drive 2, and the rebuild made it to 42% (LBA 3,500,000,000) before Drive 3 suffered a fatal head crash at LBA 3,500,000,000. Notice what you actually have: for the first 42% of the array (0% થી 42%), New Drive 2 has already been 100 percent reconstructed. So for the first 42% of the LBA range, you have a complete set of stripes using Drive 1 + New Drive 2 + Drive 4 (સારવાર તૂટી પડી Drive 3 ગુમ થયેલ ડિસ્ક તરીકે). અને જો Drive 3 ખાતે માત્ર સ્થાનિક બેડ-સેક્ટર પેચ હતો 42% (અને તેમાંથી વાંચી શકાય છે 43% થી 100% મારફતે ddrescue), તમે ઉપયોગ કરો છો ડ્રાઇવ 1 + ક્લોન કરેલી ડ્રાઇવ 3 + ડ્રાઇવ 4 બાકીના માટે 58% એરે ના.

શા માટે RAID 5 પુનઃનિર્માણની મધ્યમાં બીજી ડ્રાઈવો વારંવાર નિષ્ફળ જાય છે?

બે ઇજનેરી વાસ્તવિકતાઓ ભેગા થાય છે RAID 5 ડબલ-ડ્રાઇવ નિષ્ફળતાઓ માટે કુખ્યાત પુનઃનિર્માણ: (1) સમાન બેચ વૃદ્ધત્વ: મોટાભાગના વપરાશકર્તાઓ તે જ દિવસે એક જ રિટેલર પાસેથી 4 થી 8 સરખા હાર્ડ ડ્રાઈવો ખરીદે છે (સમાન ફર્મવેર, સમાન ફેક્ટરી લોટ, સમાન સ્પિન્ડલ મોટર બેચ) અને તેમને 35,000 કલાક માટે ચોક્કસ સમાન તાપમાને બાજુ-બાજુ ચલાવો; જ્યારે ડ્રાઇવ 1 ખતમ થઈ જાય છે, ત્યારે ડ્રાઇવ 2 અને ડ્રાઇવ 3 સમાન યાંત્રિક વસ્ત્રો થ્રેશોલ્ડથી દિવસો દૂર હોય છે. (2) સુપ્ત અસુધારી વાંચવામાં ભૂલો (UREs): સામાન્ય દૈનિક કામગીરી હેઠળ, 95% હાર્ડ ડ્રાઈવના કોલ્ડ આર્કાઇવલ સેક્ટર એક સમયે મહિનાઓ સુધી વાંચવામાં આવતા નથી, તેથી ગુપ્ત ખરાબ ક્ષેત્રો શોધ્યા વિના બેસી જાય છે. એ RAID 5 સતત દળોનું પુનઃનિર્માણ 100% દરેક હયાત ડ્રાઇવમાં દરેક એક ક્ષેત્રનું સપાટી વાંચન (40 થી 100 ટેરાબાઇટ સતત વાંચન), પાછલા વર્ષમાં એકઠા થયેલા કોઈપણ ગુપ્ત ખરાબ ક્ષેત્રને તરત જ બહાર કાઢવું.

હું કેવી રીતે જાણી શકું કે કઈ ફાઇલો થોડા વાંચી ન શકાય તેવા ખરાબ ક્ષેત્રો દ્વારા પ્રભાવિત થઈ હતી ddrescue શૂન્ય ભરવું હતું?

GNU ddrescue નામની બિલ્ટ-ઇન ફોરેન્સિક યુટિલિટીનો સમાવેશ થાય છે ddrescuelog અને ddru_ntfsfindbad / ડિબગ્સ જે તમારી પાસેથી ચોક્કસ વણવાયેલી સેક્ટર LBA રેન્જને મેપ કરે છે .નકશો ફાઇલ (સ્થિતિ = '-' ખરાબ ક્ષેત્રો) RAID સ્ટ્રાઇપ ગણિત દ્વારા સીધા ફાઇલસિસ્ટમ ઇનોડ ટેબલ પર. એકવાર તમે જાણો છો કે જે 4 KB ક્લોનિંગ દરમિયાન બ્લોક શૂન્યથી ભરેલા હતા, તમે ક્વેરી કરી શકો છો ડિબગ્સ (આઇચેક અને ચેક ચાલુ ext4) અથવા btrfs inspect-internal logical-resolve 2 અથવા 3 ફાઇલનામોની ચોક્કસ સૂચિ છાપવા માટે કે જે તે ખરાબ ક્ષેત્રોને ઓવરલેપ કરે છે, 100 ટકા ગાણિતિક નિશ્ચિતતા સાથે પુષ્ટિ કરે છે કે તમારા મલ્ટી-ટેરાબાઇટ સર્વર પરની દરેક અન્ય ફાઇલ સંપૂર્ણપણે અનકરપ્ટેડ છે.


સંબંધિત માર્ગદર્શિકાઓ


સ્ત્રોતો અને સત્તાવાર માર્ગદર્શન

  • Linux રેઇડ વિકી (raid.wiki.kernel.org/index.php/Linux_Raid અને Recovering_a_failed_software_RAID): સત્તાવાર કર્નલ mdadm રિકવરી પ્રોટોકોલ, ડિવાઈસ-મેપર કોપી-ઓન-રાઈટ (dm-snapshot) ઓવરલે, અને Events કાઉન્ટર સમાધાન.
  • જીએનયુ ddrescue અધિકૃત ઇજનેરી માર્ગદર્શિકા (gnu.org/software/ddrescue/manual/ddrescue_manual.html): મલ્ટી-ફેઝ નોન-સ્ક્રેપિંગ (-n) અને ડાયરેક્ટ એક્સેસ (-d) નિષ્ફળ મેગ્નેટિક મીડિયા માટે સેક્ટર રિકવરી અલ્ગોરિધમ.
  • સિનોલોજી ઓફિશિયલ નોલેજ બેઝ (kb.synology.com/en-global/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC): માઉન્ટિંગ mdadm + LVM2 + Btrfs / ext4 ઉબુન્ટુ રેસ્ક્યુ સિસ્ટમ્સ પર એનએએસ વોલ્યુમ્સ ફક્ત વાંચવા માટે.
  • સ્ટોરેજ નેટવર્કિંગ ઇન્ડસ્ટ્રી એસોસિએશન (SNIA): સામાન્ય RAID ડિસ્ક ડેટા ફોર્મેટ (DDF) હાર્ડવેર RAID કંટ્રોલર મેટાડેટા પોર્ટેબિલિટી માટે સ્પષ્ટીકરણ.