RAID 5, RAID 6, અથવા ZFS મલ્ટીપલ ડ્રાઇવ ડ્રોપ: ક્રેશ થયેલ સિનોલોજી, QNAP, અથવા TrueNAS એરેને સમાનતાનો નાશ કર્યા વિના પુનઃપ્રાપ્ત કરવું¶

સિનોલોજી ડિસ્કસ્ટેશન, ક્યુએનએપી ટીએસ-સિરીઝ, ટ્રુએનએએસ સર્વર અથવા લિનક્સ સાંભળવું mdadm વોલ્યુમ ક્રેશ્ડ, પૂલ ડીગ્રેડેડ/ફોલ્ટેડ અથવા મલ્ટિપલ ડ્રાઈવ ડિસ્કનેક્ટેડની જાણ કરતી વખતે સ્ટોરેજ સર્વર સતત બીપ વગાડવું એ હાઈ-સ્ટેક સ્ટોરેજ ઈમરજન્સી છે. જ્યારે એક જ ડ્રાઈવ એમાંથી નીકળી જાય છે RAID 5, સિનોલોજી હાઇબ્રિડ RAID (SHR-1), અથવા ZFS RAIDZ1 પૂલ, એરે શૂન્ય રીડન્ડન્સી સાથે ચાલે છે (degraded રાજ્ય), બાકીની દરેક ડિસ્કને સમાંતર વાંચીને ફ્લાય પર ખૂટતા બ્લોકનું પુનઃનિર્માણ. જો કલાકો પછી બીજી ડ્રાઈવ ઓફલાઈન થઈ જાય અથવા રીકવર ન કરી શકાય તેવી રીડ એરર ફેંકે (URE) રિપ્લેસમેન્ટ ડિસ્ક પર પુનઃનિર્માણ દ્વારા અડધા રસ્તે, પેરિટી ગણિત તૂટી જાય છે અને સ્ટોરેજ પૂલ સંપૂર્ણપણે ઑફલાઇન થઈ જાય છે. ગભરાયેલા એડમિનિસ્ટ્રેટરો વારંવાર પ્રારંભ કરો પર ક્લિક કરીને, પુનઃપ્રાપ્તિપાત્ર ડેટાના ટેરાબાઈટનો આગામી સાઠ સેકન્ડમાં નાશ કરે છે mdadm --create, અથવા નિષ્ફળ હાર્ડવેર પર તાત્કાલિક ઑનલાઇન પુનઃનિર્માણની ફરજ પાડવી. જો તમારું હાર્ડવેર RAID નિયંત્રક કાર્ડ ડિસ્કને બદલે મૃત્યુ પામ્યું હોય, તો પર સ્વિચ કરો RAID નિયંત્રક કાર્ડ મૃત્યુ, વિદેશી રૂપરેખાંકન આયાત, અને શા માટે તમારે ક્યારેય ડિસ્ક શરૂ કરવી જોઈએ નહીં; જો કોઈ વ્યક્તિગત હાર્ડ ડ્રાઈવ ક્લિક કરતી હોય અથવા સ્પિન અપ કરવાનો ઇનકાર કરતી હોય, તો સંપર્ક કરો હાર્ડ ડ્રાઈવ નિષ્ફળતા અને ડેટા પુનઃપ્રાપ્તિ અથવા NAS RAID એરે ડિગ્રેડેડ, બહુવિધ ડ્રાઇવ નિષ્ફળતા અને ZFS/Btrfs પુનઃપ્રાપ્તિ. જો આ સ્ટોરેજ નિષ્ફળતા હોસ્પિટલ મેડિકલ ઇમેજિંગને અક્ષમ કરે છે (PACS), ઇમરજન્સી ડિસ્પેચ અથવા જીવન-સુરક્ષા ઇન્ફ્રાસ્ટ્રક્ચર, તમારા સ્થાનિક કટોકટી નંબર પર કૉલ કરો (911 યુનાઇટેડ સ્ટેટ્સ અને કેનેડામાં, 112 સમગ્ર યુરોપિયન યુનિયનમાં, 999 યુનાઇટેડ કિંગડમમાં) અથવા અમારી ડિરેક્ટરી તપાસો કટોકટી નંબરો.

હવે આ કરો¶

1. રોકો અને "પ્રારંભ કરો," "પૂલ બનાવો," "રિપેર કરો" અથવા ચલાવો પર ક્લિક કરશો નહીં mdadm --create ડ્રોપ કરેલી ડ્રાઇવ્સ પર: સિનોલોજી DSM અથવા QNAP QTS માં ઇનિશિયલાઇઝ પર ક્લિક કરવું અથવા ચાલી રહ્યું છે mdadm --create Linux માં, તદ્દન નવા સુપરબ્લોક લખે છે અને તમામ સભ્ય ડિસ્કમાં પેરિટી સ્ટ્રાઈપ્સને શૂન્ય કરવાનું શરૂ કરે છે. એક ડ્રોપ ડ્રાઇવ સામાન્ય રીતે હજુ પણ ધરાવે છે 99.99% તમારી ફાઇલો અકબંધ છે, ફક્ત તેના ઇવેન્ટ કાઉન્ટર દ્વારા આઉટ-ઓફ-સિંક તરીકે ચિહ્નિત થયેલ છે.
2. ઇવેન્ટ કાઉન્ટર્સને ફ્રીઝ કરવા માટે NAS અથવા સર્વરને સ્વચ્છ રીતે પાવર ડાઉન કરો (અથવા પાવર ખેંચો જો તે સક્રિય રીતે ક્લિક કરતી ડ્રાઇવ્સ પર પુનઃનિર્માણ કરતું હોય): દર સેકન્ડે એરે આંશિક રીતે ડિગ્રેડેડ સ્થિતિમાં ઑનલાઇન રહે છે, ઑપરેટિંગ સિસ્ટમ સુપરબ્લોકમાં વધારો કરે છે. Update Time અને Events હયાત ડિસ્ક પર કાઉન્ટર કરો જ્યારે છોડેલી ડિસ્ક જૂની ઇવેન્ટ નંબર પર સ્થિર રહે છે. જો NAS ખરાબ ક્ષેત્રો સાથે ડ્રાઇવમાં સ્વયંસંચાલિત પુનઃનિર્માણનો પ્રયાસ કરી રહ્યું છે, તો તે ડ્રાઇવને વાંચવાનું ચાલુ રાખવાથી ચુંબકીય પ્લેટર કોટિંગ (head crash).
3. દરેક ડ્રાઇવ બે સ્લોટને ભૌતિક માર્કર અથવા ટેપ વડે લેબલ કરો (Bay 1, Bay 2, Bay 3, Bay 4) કોઈપણ ટ્રેને બહાર કાઢતા પહેલા: જ્યારે Linux mdadm, LVM2, અને ZFS દરેક પાર્ટીશન સુપરબ્લોક, જૂના હાર્ડવેર નિયંત્રકો અને મેન્યુઅલની અંદર UUID દ્વારા ટ્રૅક ડ્રાઇવ ઓર્ડર dmsetup કોષ્ટક પુનઃનિર્માણ માટે ચોક્કસ ભૌતિક સ્લોટ ઓર્ડરની જરૂર છે (0, 1, 2, 3...).
4. પુનઃપ્રાપ્તિ, ફોર્સ-એસેમ્બલી અથવા ક્યારેય પ્રયાસ કરશો નહીં fsck સીધા મૂળ સભ્ય ડ્રાઈવો પર; બીટ-બૉર-બીટનો ઉપયોગ કરીને દરેક ડ્રાઇવને ક્લોન કરો ddrescue પ્રથમ: દોડતા પહેલા mdadm --assemble --force અથવા zpool import -F, દરેક સભ્ય ડિસ્કને લિનક્સ વર્કસ્ટેશન સાથે ડાયરેક્ટ SATA/SAS દ્વારા જોડો (ક્યારેય સસ્તો યુએસબી બ્રિજ છુપાવતો નથી SMART અથવા SCT ERC સમયસમાપ્તિ) અને તેની સાથે ક્લોન કરો ddrescue તંદુરસ્ત ફાજલ ડ્રાઈવો અથવા ઈમેજ ફાઈલો પર.
5. ફક્ત વાંચવા મોડમાં સખત રીતે ક્લોન કરેલ એરેને ફોર્સ-એસેમ્બલ કરો (--readonly અથવા -o readonly=on): એસેમ્બલ કરતી વખતે mdadm એરે જેના ઇવેન્ટ કાઉન્ટર્સ એક સાથે મલ્ટિ-ડ્રાઈવ ડ્રોપ દરમિયાન અલગ થઈ ગયા હતા, હંમેશા પસાર થાય છે --readonly (mdadm --assemble --force --readonly /dev/md0 ...). ફક્ત-વાંચવા માટેના મોડમાં પણ નહીં mdadm, LVM2, ext4, Btrfs, કે ZFS પેરિટી પટ્ટાઓ પર ફરીથી લખી શકે છે અથવા વિનાશક જર્નલને ફરીથી ચલાવી શકે છે.
6. તમારા સૌથી મહત્વપૂર્ણ ડેટાને સ્વતંત્ર બાહ્ય બેકઅપ ડ્રાઇવમાં કૉપિ કરો, એકવાર ફક્ત વાંચવા માટે જ માઉન્ટ કરો: તમારા દસ્તાવેજો, ડેટાબેસેસ, વર્ચ્યુઅલ મશીનો અને ફોટાઓને પહેલા એક અલગ ડ્રાઇવમાં ખાલી કરો, પછી શરૂઆતથી ડિસ્કને સાફ કરો અને પરીક્ષણ કરો.

નિર્ણય વૃક્ષ: મલ્ટિ-ડ્રાઈવ RAID અને ZFS પૂલ ઈમરજન્સી ટ્રાયજ¶

તમારા એરેમાં તાર્કિક સમયસમાપ્તિ ઘટાડો થયો છે કે કેમ તે નિર્ધારિત કરવા માટે આ ફ્લોચાર્ટનો ઉપયોગ કરો (TLER / ERC મિસમેચ), પુનઃનિર્માણ દરમિયાન સાચી મલ્ટી-ડિસ્ક બેડ-સેક્ટર નિષ્ફળતા, અથવા ZFS ટ્રાન્ઝેક્શન જૂથ (TXG) દોષ:

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS પૂલ 2+ ડ્રાઇવ્સ છોડ્યા પછી ક્રેશ થયો"] --> StopIO["તમામ પુનઃનિર્માણ બંધ કરો અને NAS ને તરત જ પાવર ડાઉન કરો"]
    StopIO --> Label["દરેક ડ્રાઇવ ટ્રેને બે નંબર દ્વારા લેબલ કરો (બે 1 થી બે એન)"]
    Label --> ConnectLinux["ડાયરેક્ટ SATA / HBA દ્વારા ઉબુન્ટુ લિનક્સ રેસ્ક્યુ હોસ્ટ સાથે મેમ્બર ડ્રાઇવ્સને કનેક્ટ કરો"]

    ConnectLinux --> CheckSmart["SMART અને મેટાડેટા ફક્ત વાંચવા માટે તપાસો: smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"શું કોઈપણ ડ્રાઇવ્સ ક્લિક કરી રહી છે, સ્પિન કરવાનો ઇનકાર કરી રહી છે અથવા dmesg માં ઑફલાઇન છોડી રહી છે?"}

    PhysicalHealth -->|"હા: RAID 5 માં 2+ ડ્રાઇવ્સ પર યાંત્રિક / માથામાં નિષ્ફળતા"| Cleanroom["પાવરિંગ ડિસ્કને રોકો -> ક્લીનરૂમ ડેટા રિકવરી લેબમાં મોકલો"]
    PhysicalHealth -->|"ના: બધી ડ્રાઇવ્સ સ્પિન અપ (બેડ સેક્ટર અથવા ટાઈમઆઉટ ડ્રોપ્સ બાકી હોઈ શકે છે)"| CloneAll["GNU ddrescue નો ઉપયોગ કરીને દરેક સભ્ય ડ્રાઇવને ક્લોન કરો (ફોરવર્ડ પાસ -> રિવર્સ સ્ક્રેપ)"]

    CloneAll --> DisconnectOrig["મૂળ ડ્રાઇવ્સને ડિસ્કનેક્ટ કરો અને ક્લોન કરેલી ડિસ્ક / છબીઓ પર સખત રીતે કાર્ય કરો"]
    DisconnectOrig --> ArrayType{"કયા સ્ટોરેજ આર્કિટેક્ચરનો ઉપયોગ થાય છે?"}

    ArrayType -->|"સિનોલોજી DSM (SHR / ક્લાસિક RAID)"| SynologyFlow["mdadm --examine -> ફોર્સ-એસેમ્બલ રીડ-ઓનલી -> LVM2 / Btrfs ફક્ત વાંચવા માટે સક્રિય કરો"]
    ArrayType -->|"QNAP QTS (HAL LVM પાતળો / જાડા RAID)"| QnapFlow["માત્ર વાંચવા માટે mdadm એસેમ્બલ કરો -> જો હાજર હોય તો DRBD લેયરને સક્રિય કરો -> કસ્ટમ QNAP LVM2 સુપરબ્લોક સ્કેન કરો"]
    ArrayType -->|"ટ્રુએનએએસ / ઝેડએફએસ (RAIDZ1 / RAIDZ2 / મિરર)"| ZfsFlow["zpool import -d /dev/disk/by-id -> રોલબેક સાથે ફક્ત વાંચવા માટે આયાત કરો: zpool import -f -o readonly=on -F"]
    ArrayType -->|"સ્ટાન્ડર્ડ લિનક્સ mdadm"| LinuxFlow["ઇવેન્ટ કાઉન્ટર્સની તુલના કરો -> mdadm --assemble --force --readonly -> માઉન્ટ ફાઇલસિસ્ટમ -o ro, noload સાથે ચલાવો"]

તબક્કો 1: શા માટે પુનઃનિર્માણ માટે દબાણ કરવું ડેટાનો નાશ કરે છે (ધ URE અને સમાન-બેચ કાસ્કેડ)¶

શા માટે સમારકામ/પુનઃબીલ્ડ પર ક્લિક કરવાથી અથવા એક ડ્રાઇવને બદલવાથી અને 36 કલાક રાહ જોવાથી ઘણી વખત કુલ એરે ક્રેશ થાય છે તે સમજવા માટે, તમારે સમજવું જોઈએ કે પેરિટી પુનઃનિર્માણ કેવી રીતે વૃદ્ધ ચુંબકીય મીડિયા પર ભાર મૂકે છે અને શા માટે કન્ઝ્યુમર ડેસ્કટોપ ડ્રાઇવ્સ NAS એન્ક્લોઝરમાંથી બહાર નીકળી જાય છે.

1. પુનઃપ્રાપ્ત ન કરી શકાય તેવી વાંચન ભૂલોની ગાણિતિક વાસ્તવિકતા (UREs) RAID 5 અથવા RAIDZ1 પુનઃબીલ્ડ દરમિયાન¶

4-ડ્રાઈવમાં RAID 5 અથવા ZFS RAIDZ1 પૂલ, ડેટા અને પેરિટી બ્લોક્સ (P) એક્સક્લુઝિવ અથવા (XOR) ગણતરી (D1 XOR D2 XOR D3 = P). જો ડ્રાઇવ 2 સંપૂર્ણપણે મૃત્યુ પામે છે, તો એરેમાં શૂન્ય બાકી રીડન્ડન્સી છે. એકદમ નવી રિપ્લેસમેન્ટ ડિસ્ક પર ડ્રાઇવ 2ને ફરીથી બનાવવા માટે, NAS એ ડ્રાઇવ 1, ડ્રાઇવ 3, અને ડ્રાઇવ 4 પર એકસાથે **બાઇટ 0 થી ડિસ્કના અંત સુધી દરેક એક સેક્ટર વાંચવું આવશ્યક છે (Reconstructed D2 = D1 XOR D3 XOR P).

જ્યારે તે ડ્રાઈવો ચાર વર્ષ પહેલાં સમાન ઉત્પાદન બેચમાંથી ખરીદેલી ચાર 12 ટેરાબાઈટ (12,000 ગીગાબાઈટ) હાર્ડ ડ્રાઈવો હોય ત્યારે શું થાય છે તે ધ્યાનમાં લો: - 12 ટેરાબાઈટના પુનઃનિર્માણ માટે વાંચન જરૂરી છે 36 terabytes (2.88 x 1014 વ્યક્તિગત બિટ્સ) મહત્તમ થર્મલ અને મિકેનિકલ લોડ પર સતત 24 થી 48 કલાક સુધી. - ઉપભોક્તા હાર્ડ ડ્રાઈવો સામાન્ય રીતે પુનઃપ્રાપ્ત ન કરી શકાય તેવી રીડ એરર ધરાવે છે (URE) નું સ્પષ્ટીકરણ 1 error in 1014 bits (12.5 terabytes), અને વૃદ્ધત્વની ડ્રાઈવો શાંત સુપ્ત ક્ષેત્રની ભૂલો વિકસાવે છે (Current_Pending_Sector) ડિસ્કના ઠંડા વિસ્તારોમાં કે જે વર્ષોથી વાંચવામાં આવ્યા નથી. - જે ક્ષણે ડ્રાઇવ 3 એક જ વાંચી ન શકાય તેવા 4 કિલોબાઇટ (0.004 મેગાબાઇટ) ખરાબ સેક્ટરને હિટ કરે છે જ્યારે ડ્રાઇવ 2 હજી ખૂટે છે અથવા અર્ધ-પુનઃબિલ્ટ છે, XOR સમીકરણમાં બે અજાણ્યા છે (D2 અને D3).

2. શા માટે ડેસ્કટોપ ડ્રાઇવ્સ વિના TLER / SCT ERC 1 ખરાબ ક્ષેત્રને સંપૂર્ણપણે બહાર કાઢો¶

અહીં તે છટકું છે જે સિનોલોજી, ક્યુએનએપી અને લિનક્સ પર વિનાશક મલ્ટી-ડ્રાઇવ ડ્રોપ્સનું કારણ બને છે mdadm:

+-------------------------------------------------------------------------+
| WHY A SINGLE BAD SECTOR DROPS AN ENTIRE DRIVE DURING REBUILD            |
|                                                                         |
| 1. Drive 2 is dead/rebuilding. NAS reads Sector 849,102,400 on Drive 3. |
| 2. Drive 3 hits a weak magnetic spot (Current_Pending_Sector).          |
| 3. Consumer Drive Behavior (No TLER / SCT ERC):                         |
|    - Drive 3 enters deep internal error recovery for 30 to 120 seconds, |
|      stopping all SATA responses while retrying head positioning.       |
| 4. Linux Kernel / NAS Controller Timeout (Default 7 to 30 seconds):     |
|    - Kernel sees Drive 3 unresponsive for >30s -> Issues SATA bus reset |
|    - mdadm assumes Drive 3 is COMPLETELY DEAD and kicks it from array   |
| 5. RESULT: Both Drive 2 and Drive 3 are now marked FAULTY/REMOVED.      |
|    The entire RAID 5 array crashes offline immediately.                 |
+-------------------------------------------------------------------------+

નોંધ લો કે ખરેખર શું થયું: ડ્રાઇવ 3 ડેડ નથી. તેની પાસે છે 99.999999% તંદુરસ્ત ક્ષેત્રો અને માત્ર 1 અથવા 2 વાંચી ન શકાય તેવા 4 કિલોબાઈટ ક્ષેત્રો (8 kilobytes ની બહાર 12 terabytes). છતાં કારણ કે mdadm 30-સેકન્ડના આદેશ સમયસમાપ્તિને કારણે ડ્રાઇવ 3 ને એરેમાંથી બહાર કાઢ્યું, સમગ્ર વોલ્યુમ ક્રેશ્ડ તરીકે બતાવે છે. જો તમે ડ્રાઇવ 3 સાથે ક્લોન કરો છો ddrescue (જે 8 કિલોબાઈટ્સના ખરાબ સેક્ટરને આકર્ષક રીતે છોડી દે છે અને અન્ય 12 ટેરાબાઈટ્સની નકલ કરે છે) અને એરેને ફક્ત વાંચવા માટે જબરદસ્તીથી એસેમ્બલ કરો, તમે તમારી ફાઇલોના વર્ચ્યુઅલ રીતે 100 ટકા પુનઃપ્રાપ્ત કરો છો.

3. શા માટે તમારે ક્યારેય દોડવું જોઈએ નહીં mdadm --create અથવા "પ્રારંભ કરો" ક્લિક કરો¶

જ્યારે એરે ક્રેશ થાય છે, ત્યારે બે વિનાશક દંતકથાઓ ઑનલાઇન પ્રસારિત થાય છે: - ** માન્યતા 1: "એરેને બરાબર એ જ ડ્રાઇવ ઓર્ડર સાથે ફરીથી બનાવો mdadm --create."** સાથે પણ --assume-cleanની આધુનિક આવૃત્તિઓ mdadm ડિફોલ્ટથી અલગ Data Offset કર્નલ પર આધાર રાખીને મૂલ્યો અને mdadm રિલીઝ (2048 sectors વિ 262144 sectors). જ્યારે mdadm --create નવી આવૃત્તિ લખે છે 1.2 ખોટા ઓફસેટ પર સુપરબ્લોક અથવા મેળ ખાતી ન હોય તેવા ચંક કદ સાથે, તે ઓવરરાઈટ કરે છે LVM2 ભૌતિક વોલ્યુમ હેડર અથવા ext4 વોલ્યુમના આગળના ભાગમાં સુપરબ્લોક. - મીથ 2: "હમણાં જ પડી ગયેલી બીજી ડ્રાઇવને ખેંચો, તેને ફરીથી પ્લગ ઇન કરો અને સમારકામ પર ક્લિક કરો." જો ડ્રાઈવ 1 ત્રણ દિવસ પહેલા ડ્રોપ આઉટ થઈ ગઈ હોય (જેથી તેનો ડેટા 3 દિવસ જૂનો છે) અને ડ્રાઈવ 3 10 મિનિટ પહેલા ડ્રોપ આઉટ થઈ ગઈ હોય (જેથી તેનો ડેટા વર્તમાન છે), તો ખોટી ડ્રાઈવને ખેંચીને ફરીથી દાખલ કરવી અથવા ડ્રાઈવ 1ને "સક્રિય" તરીકે ચિહ્નિત કરીને પુનઃનિર્માણ કરવાની ફરજ પાડવામાં આવે છે અને ડ્રાઈવ 3 ને "એએસપી" ** ચિહ્નિત કરવામાં આવે છે. 3-દિવસ-જૂની વાસી પેરિટી સ્ટ્રાઇપ્સ સાથે અપ-ટુ-ડેટ એરે**, છેલ્લા 72 કલાકમાં સંશોધિત દરેક ડિરેક્ટરી અને ફાઇલને બગાડે છે.

તબક્કો 2: સુપરબ્લોકનું નિરીક્ષણ અને Event Linux રેસ્ક્યૂ હોસ્ટ પર સુરક્ષિત રીતે કાઉન્ટર્સ¶

ક્રેશ થયેલ સિનોલોજી, QNAP, TrueNAS, અથવા Linux એરેને સુરક્ષિત રીતે બચાવવા માટે, તમામ સભ્ય ડ્રાઈવો દૂર કરો (તેમના બે નંબરને લેબલ કર્યા પછી) અને તેમને ડેસ્કટોપ પીસી અથવા Ubuntu 22.04 LTS / 24.04 LTS પર ચાલતા સર્વર સાથે જોડો (લાઇવ USB સ્ટિકમાંથી પણ બુટ કરેલ).

પગલું 1: ઉબુન્ટુમાં ફોરેન્સિક રેસ્ક્યૂ ટૂલકિટ ઇન્સ્ટોલ કરો¶

તમારા ઉબુન્ટુ રેસ્ક્યુ મશીન પર ટર્મિનલ ખોલો અને જરૂરી ઉપયોગિતાઓ ઇન્સ્ટોલ કરો:

sudo apt-get update
sudo apt-get install -y gddrescue smartmontools mdadm lvm2 btrfs-progs xfsprogs zfsutils-linux

પગલું 2: દરેક ડ્રાઇવ લેટર, સીરીયલ નંબર અને પાર્ટીશન લેઆઉટનો નકશો બનાવો¶

બધા કનેક્ટેડ બ્લોક ઉપકરણો અને તેમના હાર્ડવેર સીરીયલ નંબરોની યાદી આપો જેથી તમે ક્યારેય સ્ત્રોત NAS ડિસ્ક સાથે રેસ્ક્યૂ ડિસ્કને મૂંઝવશો નહીં:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,TYPE,MOUNTPOINTS

લાક્ષણિક સિનોલોજી DSM, QNAP, અથવા TrueNAS ડ્રાઇવના પાર્ટીશન કોષ્ટકને જુઓ:

પગલું 3: તપાસો mdadm --examine એરે કેમ ક્રેશ થયું તે જોવા માટે (ઇવેન્ટ કાઉન્ટર મેટ્રિક્સ)¶

સિનોલોજી, QNAP અથવા Linux પર mdadm એરે, વપરાશકર્તા ડેટા પાર્ટીશનો પર RAID મેટાડેટાનું પરીક્ષણ કરો (ઉદાહરણ તરીકે, પાર્ટીશન 3 પર /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) કંઈપણ માઉન્ટ કર્યા વિના અથવા સંશોધિત કર્યા વિના:

sudo mdadm --examine /dev/sd[b-e]3 | grep -E "Filename|Magic|Update Time|Events|Array State|Device Role"

તમામ ચાર ડ્રાઈવોમાં આઉટપુટની તુલના કરો:

/dev/sdb3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
    Update Time : Thu Oct 29 03:44:11 2026
         Events : 479012
   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd3:
    Update Time : Sat Oct 31 14:12:04 2026
         Events : 482188
   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

આ ફોરેન્સિક વાર્તા ધ્યાનથી વાંચો: 1. /dev/sdc3 (Device Role 1) પાસે એક છે Events ની ગણતરી 479012 બે દિવસ પહેલા થી (Oct 29). તે ડ્રાઈવ પ્રથમ, બે દિવસ પહેલા છોડી દેવામાં આવી હતી અને ત્યારથી તે ઓફલાઈન છે. 2. /dev/sdb3 (Role 0) અને /dev/sde3 (Role 3) બંને પાસે છે Events : 482190 ખાતે 14:12:09. 3. /dev/sdd3 (Role 2) ધરાવે છે Events : 482188 ખાતે 14:12:04, માત્ર 5 સેકન્ડ અને 2 ઇવેન્ટ પાછળ sdb3 અને sde3. 4. નિષ્કર્ષ: તમારે ** નો ઉપયોગ કરીને એરેનું પુનઃનિર્માણ કરવું આવશ્યક છેsdb3 (Role 0), sdd3 (Role 2), અને sde3 (Role 3)** (જેના ઇવેન્ટ કાઉન્ટર્સ માત્ર 2 ટિકના અંતરે છે), જ્યારે **જતી વખતે sdc3 (Role 1) સંપૂર્ણપણે બહાર **.

તબક્કો 3: દરેક ડ્રાઈવ બીટ-ફોર-બીટ સાથે ક્લોનિંગ GNU ddrescue¶

દોડતા પહેલા mdadm --assemble --force અથવા zpool import -F, દરેક જરૂરી ડ્રાઈવને ક્લોન કરો (ખાસ કરીને ડ્રાઈવ કે જે ખરાબ સેક્ટરને કારણે છેલ્લે છોડી દેવામાં આવી હતી, જેમ કે /dev/sdd ઉપરના ઉદાહરણમાં) સમાન અથવા મોટી ક્ષમતાની તંદુરસ્ત ખાલી ડ્રાઇવ પર અથવા કાચામાં .img મોટા સ્ટોરેજ વોલ્યુમ પર ફાઇલ.

પગલું 1: શા માટે ddrescue મેપફાઈલ સાથે ફરજિયાત છે¶

ધોરણ dd પ્રથમ ખરાબ ક્ષેત્ર પર અથવા તેની સાથે બંધ કરે છે conv=noerror,sync તેના રીડ હેડ્સને ક્ષતિગ્રસ્ત ટ્રેક પર પીસવામાં કલાકો વેડફાય છે જ્યારે નજીકના સારા ડેટાના મેગાબાઇટ્સ શૂન્ય-ફિલિંગ કરે છે. GNU ddrescue બુદ્ધિશાળી મલ્ટિ-સ્ટેજ પાસમાં કામ કરે છે: 1. પાસ 1 (કૉપી કરવાનો તબક્કો): ડિસ્કના તમામ સ્વસ્થ, ઝડપી-પ્રતિસાદ આપતા પ્રદેશોને સંપૂર્ણ ક્રમિક ઝડપે કૉપિ કરે છે (150 MB/s થી 250 MB/s), કોઈપણ ધીમા અથવા વાંચી ન શકાય તેવા બ્લોક્સ પર તરત જ કૂદકો મારવો જેથી તમે મેળવતા પહેલા ડ્રાઈવ વધુ ગરમ ન થાય અથવા મૃત્યુ ન પામે. 99.99% સારો ડેટા. 2. પાસ 2 (આનુષંગિક બાબતોનો તબક્કો): આગળ અને પાછળ બંને બાજુથી દરેક ખરાબ બ્લોકની ચોક્કસ ધાર સુધી વાંચે છે (reverse direction) ક્ષતિગ્રસ્ત વિસ્તારને ચોક્કસ 4 કિલોબાઈટ હાર્ડવેર સેક્ટરમાં અલગ કરવા. 3. પાસ 3 (સ્ક્રેપિંગનો તબક્કો): બસને બિનજરૂરી રીતે રીસેટ કર્યા વિના ક્ષતિગ્રસ્ત ક્ષેત્રોને હળવાશથી ફરી પ્રયાસ કરો.

પગલું 2: 2-તબક્કો ચલાવો ddrescue ક્લોન આદેશ¶

હંમેશા મેપફાઈલ નો ઉલ્લેખ કરો (sdd_rescue.map). જો ડાઇંગ સોર્સ ડ્રાઇવ ડિસ્કનેક્ટ થઈ જાય અને તેને પાવર સાયકલની જરૂર હોય, ddrescue મેપફાઈલ વાંચે છે અને તે ચોક્કસ બાઈટ પર ફરી શરૂ થાય છે જ્યાં તેણે પહેલાથી જ કોપી કરેલ સેક્ટરને ફરીથી વાંચ્યા વિના છોડી દીધું હતું:

# Stage 1: Fast forward pass skipping bad/slow blocks immediately (-n = no-scrape)
sudo ddrescue -f -n -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

# Stage 2: Targeted trimming and 3-retry scrape of the skipped bad sectors
sudo ddrescue -f -d -r 3 -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

તબક્કો 4: પુનઃનિર્માણ સિનોલોજી DSM (SHR-1 / SHR-2 / ક્લાસિક RAID), QNAP અને Linux mdadm¶

એકવાર તમારી ક્લોન કરેલી ડ્રાઈવો (અથવા ફક્ત વાંચવા માટેના લૂપ ઉપકરણો) તૈયાર થઈ જાય અને મૂળ NAS ડ્રાઈવ સુરક્ષિત રીતે અનપ્લગ થઈ જાય, તમારા પ્લેટફોર્મ માટે ચોક્કસ બિન-વિનાશક એસેમ્બલી ક્રમને અનુસરો.

દૃશ્ય A: માનક Linux mdadm અથવા સિનોલોજી ક્લાસિક RAID (RAID 5 / RAID 6)¶

1. કોઈપણ આંશિક રોકો md એરે જે ઉબુન્ટુએ શરૂ કરવાનો પ્રયાસ કર્યો હશે:

   cat /proc/mdstat
   sudo mdadm --stop /dev/md127
   

2. ક્લોન કરેલા પાર્ટીશનોને ફોર્સ-એસેમ્બલ કરો (sdb3, sdd3, sde3, લાંબા મૃત અવગણવા sdc3) સખત રીતે વાંચવા માટેના મોડમાં:

   sudo mdadm --assemble --force --readonly --verbose /dev/md2 /dev/sdb3 /dev/sdd3 /dev/sde3
   

   આઉટપુટ જુઓ: mdadm જાણ કરશે forcing event count in /dev/sdd3(2) from 482188 up to 482190 અને mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. ચકાસો કે એરે સક્રિય છે અને ચિહ્નિત થયેલ છે (auto-read-only) અથવા (read-only):

   cat /proc/mdstat
   

દૃશ્ય B: સિનોલોજી હાઇબ્રિડ RAID (SHR-1 અને SHR-2) સાથે LVM2 અને Btrfs / ext4¶

સિનોલોજી SHR (Synology Hybrid RAID) એ 100 ટકા પ્રમાણભૂત Linux છે mdadm + LVM2 (Logical Volume Manager): - જ્યારે SHR પૂલમાં તમામ ડ્રાઈવો સમાન કદની હોય છે (ઉદાહરણ તરીકે, ચાર 8 ટેરાબાઈટ ડ્રાઈવ), સિનોલોજી એક સિંગલ બનાવે છે mdadm RAID 5 પાર્ટીશન (md2 દરેક ડ્રાઇવના પાર્ટીશન 3 પર) અને મૂકે છે LVM2 વોલ્યુમ જૂથ (vg1000 અથવા vg1) ની ટોચ પર md2. - જ્યારે SHR પૂલમાં ડ્રાઈવો મિશ્રિત કદ ધરાવે છે (ઉદાહરણ તરીકે, બે 8 ટેરાબાઈટ ડ્રાઈવ અને બે 16 ટેરાબાઈટ ડ્રાઈવ), સિનોલોજી બે અલગ-અલગ બનાવે છે. mdadm એરે: md2 સમગ્ર પાર્ટીશન 5 (8 TB RAID 5 માં તમામ 4 ડ્રાઈવો પર સ્લાઈસ કરો) અને md3 સમગ્ર પાર્ટીશન 6 (બાકી 8 TB RAID 1 માં બે 16 TB ડ્રાઇવ પર સ્લાઇસ કરો), પછી જોડાય છે md2 + md3 એક માં LVM2 વોલ્યુમ જૂથ (vg1000).

ફોર્સ-એસેમ્બલિંગ પછી ઉબુન્ટુ પર ફક્ત વાંચવા માટે સિનોલોજી SHR વોલ્યુમ માઉન્ટ કરવા માટે /dev/md2 (અને /dev/md3 જો મિશ્ર-કદ SHR): 1. સિનોલોજી LVM2 ભૌતિક વોલ્યુમો અને વોલ્યુમ જૂથો માટે સ્કેન કરો:

sudo pvscan
sudo vgscan
sudo lvscan

sudo vgchange -ay /dev/vg1000

sudo mkdir -p /mnt/synology_rescue
sudo mount -t ext4 -o ro,noload /dev/vg1000/lv /mnt/synology_rescue

sudo mkdir -p /mnt/synology_rescue
sudo mount -t btrfs -o ro,norecovery /dev/vg1000/lv /mnt/synology_rescue

sudo mount -t btrfs -o ro,norecovery,usebackuproot /dev/vg1000/lv /mnt/synology_rescue

દૃશ્ય C: સિનોલોજી DSM 7+ વોલ્યુમ એન્ક્રિપ્શન અથવા શેર કરેલ ફોલ્ડર એન્ક્રિપ્શન (eCryptfs)¶

• શેર્ડ ફોલ્ડર એન્ક્રિપ્શન (@sharename@ સમાવતી ફોલ્ડર્સ ECRYPTFS_FNEK_ENCRYPTED... ફાઇલનામો): સમગ્ર નકલ કરો @encrypted_share@ ફોલ્ડર બંધ /mnt/synology_rescue પ્રથમ, પછી તમારા સિનોલોજી એન્ક્રિપ્શન પાસવર્ડનો ઉપયોગ કરીને તેને ઉબુન્ટુ પર માઉન્ટ અને ડિક્રિપ્ટ કરો અથવા .key ફાઇલ:

  sudo apt-get install -y ecryptfs-utils
  sudo mkdir -p /mnt/decrypted_share
  sudo mount -t ecryptfs -o ro /mnt/synology_rescue/@encrypted_share@ /mnt/decrypted_share
  

• DSM 7.2+ સંપૂર્ણ વોલ્યુમ એન્ક્રિપ્શન (LUKS): જો /dev/vg1000/lv બતાવે છે TYPE="crypto_LUKS" માં blkid, નો ઉપયોગ કરીને તેને ફક્ત વાંચવા માટે અનલૉક કરો .rkey જ્યારે વોલ્યુમ બનાવવામાં આવ્યું ત્યારે પુનઃપ્રાપ્તિ કી ફાઇલ ડાઉનલોડ થઈ:

  sudo cryptsetup open --readonly --key-file /path/to/Volume1.rkey /dev/vg1000/lv synology_crypt
  sudo mount -o ro,norecovery /dev/mapper/synology_crypt /mnt/synology_rescue
  

દૃશ્ય D: QNAP QTS (LVM2 Thin Provisioning અને DRBD સ્તર)¶

આધુનિક QNAP NAS એકમો (QTS 4.3+ / 5.x) આંતરિક સિંગલ-નોડ દાખલ કરો DRBD ઉપકરણ (/dev/drbd1) વચ્ચે /dev/md1 અને LVM2 વોલ્યુમ જૂથ (vg1). 1. પહેલા QNAP ડેટા પાર્ટીશનોને ફોર્સ-એસેમ્બલ કરો (/dev/sd[b-e]3) ફક્ત વાંચવા માટે /dev/md1:

sudo mdadm --assemble --force --readonly /dev/md1 /dev/sdb3 /dev/sdd3 /dev/sde3

તબક્કો 5: TrueNAS અને Linux ને બચાવવું ZFS પૂલ (RAIDZ1, RAIDZ2, RAIDZ3)¶

જો તમારું સ્ટોરેજ સર્વર TrueNAS CORE, TrueNAS SCALE, Proxmox VE, અથવા Ubuntu ZFS ચલાવે છે, તો પુનઃપ્રાપ્તિનો ઉપયોગ થતો નથી mdadm. તેના બદલે, ZFS વોલ્યુમ મેનેજર અને કોપી-ઓન-રાઈટ (CoW) Uberblocks અને ક્રમિક ટ્રાન્ઝેક્શન જૂથો (TXGs).

પગલું 1: 4 ZFS vdev લેબલોનું નિરીક્ષણ કરો (L0, L1, L2, L3) દરેક ક્લોન કરેલી ડિસ્ક પર¶

દરેક ZFS સભ્ય પાર્ટીશન પૂલ રૂપરેખાંકનની ચાર સરખી નકલો અને છેલ્લા 128 Uberblocks (પાર્ટીશનની આગળના ભાગમાં બે લેબલ, L0 અને L1, અને ખૂબ જ અંતમાં બે લેબલ, L2 અને L3). ચલાવો zdb -l પૂલ સ્થિતિ અને સર્વોચ્ચ પ્રતિબદ્ધ વ્યવહાર જૂથનું નિરીક્ષણ કરવા માટે દરેક ક્લોન કરેલ પાર્ટીશન પર (txg):

sudo zdb -l /dev/sdb2 | grep -E "name:|state:|txg:|guid:" | head -n 20

સરખામણી કરો txg: બધી ક્લોન કરેલી ડ્રાઈવોમાં નંબરો. જેમ જ mdadmની Events કાઉન્ટર, જો પાવર લોસ અથવા બીજી ડિસ્ક ડ્રોપ થવાના 5 મિનિટ પહેલા એક ડિસ્ક ડ્રોપ આઉટ થઈ જાય, તો તેનું txg બાકીની ડિસ્ક કરતાં સહેજ ઓછી હશે.

પગલું 2: ZFS પૂલને સખત રીતે વાંચવા માટેના મોડમાં આયાત કરો (-o readonly=on)¶

પ્રથમ આયાત કરી શકાય તેવા પૂલને કોઈપણ વસ્તુ દ્વારા માઉન્ટ કર્યા વિના તપાસો sudo zpool import -d /dev/disk/by-id. રીડ-રાઇટ મોડમાં ક્યારેય ક્ષતિગ્રસ્ત અથવા મલ્ટી-ડિસ્ક-ડ્રોપ કરાયેલ ZFS પૂલને આયાત કરશો નહીં. જ્યારે સાથે આયાત કરવામાં આવે છે -o readonly=on, ZFS રિસિલ્વર શરૂ કરવાનો પ્રયાસ કરતું નથી, નવા Uberblocks લખતું નથી, અને જો દૂષિત જગ્યા નકશો (spacemapલખવાની ફાળવણી દરમિયાન )નો સામનો કરવો પડે છે:

sudo mkdir -p /mnt/zfs_rescue
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue tank

પગલું 3: જો zpool import સાથે નિષ્ફળ જાય છે I/O error અથવા corrupted data, TXG રોલબેકનો ઉપયોગ કરો (-F અને -T)¶

જો ભારે લખાણના વિસ્ફોટ દરમિયાન બે ડ્રાઈવો એકબીજાની સેકન્ડમાં બહાર નીકળી જાય, તો એકદમ નવીનતમ ટ્રાન્ઝેક્શન ગ્રુપ (TXG N) હયાત પેરિટી પટ્ટાઓમાં અપૂર્ણ હોઈ શકે છે, જ્યારે TXG N-1 અથવા TXG N-2 (5 થી 15 સેકન્ડ પહેલા લખાયેલ) Uberblock રિંગ બફરની અંદર 100 ટકા અકબંધ છે.

1. ** વિનાશક ડ્રાય-રન રોલબેક પૂર્વાવલોકનનું પરીક્ષણ કરો (-F -n)**:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F -n tank
   

   જો ZFS અહેવાલ આપે છે Would be able to return pool to its state as of <timestamp>, વગર ફક્ત વાંચવા માટે રોલબેક આયાત ચલાવો -n:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F tank
   

2. જો -F હજુ પણ નવીનતમ Uberblocks માઉન્ટ કરી શકતા નથી, ઐતિહાસિક Uberblock TXG નંબરો સાથે સૂચિબદ્ધ કરો zdb અને ચોક્કસ જૂની TXG આયાત કરો (-T):

   sudo zdb -e -ul /dev/sdb2 | grep -E "Uberblock|txg =|timestamp ="
   

   એ ચૂંટો txg ક્રેશ પહેલા 30 થી 60 સેકન્ડ સુધીની સંખ્યા (ઉદાહરણ તરીકે, txg = 9481020) અને માત્ર-રીડ-ઓન્લી મોડમાં તે ચોક્કસ સમયે સ્થિર થયેલા પૂલને આયાત કરો:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -T 9481020 tank
   

તબક્કો 6: પુનઃપ્રાપ્તિ પછીની ચકાસણી અને ભાવિ પુનઃનિર્માણ કાસ્કેડને અટકાવવું¶

એકવાર તમે તમારા પુનઃપ્રાપ્ત ડેટાની 100 ટકા નકલ કરી લો /mnt/synology_rescue અથવા /mnt/zfs_rescue સ્વતંત્ર બેકઅપ લક્ષ્ય પર, તમારા NAS ને સેવામાં પાછા મૂકતા પહેલા આ હાર્ડવેર અને રૂપરેખાંકન ચેકલિસ્ટને અનુસરો:

• એક જ દિવસે એક જ રિટેલર પાસેથી બધી NAS ડ્રાઇવ્સ ક્યારેય ખરીદશો નહીં: સમાન ઉત્પાદન ક્ષેત્રની ડ્રાઇવ્સ સમાન હેડ બેચ અને ફર્મવેર શેર કરે છે, જેના કારણે તેઓ પુનઃનિર્માણ દરમિયાન એકબીજાના કલાકોમાં નિષ્ફળ જાય છે. મિક્સ બેચ અથવા ઉત્પાદકો (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• માત્ર NAS/એન્ટરપ્રાઇઝ ડ્રાઇવનો ઉપયોગ કરો TLER / SCT ERC સક્ષમ (અથવા Linux વધારો mdadm ડેસ્કટોપ ડ્રાઈવો માટે SCSI સમયસમાપ્તિ): Linux માં ગ્રાહક ડ્રાઈવો માટે mdadm, a નો ઉપયોગ કરો udev વધારવાનો નિયમ /sys/block/sdX/device/timeout થી 30 સેકન્ડ થી 180 સેકન્ડ તેથી mdadm ડ્રાઇવ છોડવાને બદલે આંતરિક ક્ષેત્રના રિમેપિંગની રાહ જુએ છે.
• ** કરતાં મોટી ડ્રાઈવો સાથે એરેને સ્થાનાંતરિત કરો 8 TB થી RAID 5 / SHR-1 / RAIDZ1 થી RAID 6 / SHR-2 / RAIDZ2**: સાથે 12 TB થી 24 TB ડ્રાઇવ્સ, સિંગલ-પેરિટી પુનઃનિર્માણનો સમય 30 કલાકથી વધુ છે, ડ્યુઅલ-પેરિટી બનાવે છે (RAID 6 / SHR-2 / RAIDZ2) રિસિલ્વરિંગ દરમિયાન ખરાબ ક્ષેત્રને ટકી રહેવા માટે મહત્વપૂર્ણ છે.
• ** માસિક શેડ્યૂલ કરો Data Scrubbing (mdadm check / zpool scrub) અને વિસ્તૃત SMART પરીક્ષણો**: માસિક સ્ક્રબિંગ સમારકામ ગુપ્ત ક્ષેત્રની ભૂલો (Current_Pending_Sector) જ્યારે બધી ડ્રાઈવો ઓનલાઈન હોય.
• યાદ રાખો કે RAID એ ઉચ્ચ ઉપલબ્ધતા છે, ક્યારેય બેકઅપ નથી: અનુસરો 3-2-1 બેકઅપ વ્યૂહરચના ઑફલાઇન નકલ સાથે.

પ્રાદેશિક કટોકટી નંબરો અને એજન્સી પ્રોટોકોલ્સ¶

હેલ્થકેર નેટવર્ક્સ, કટોકટી સંદેશાવ્યવહાર અથવા વૈધાનિક વ્યક્તિગત રેકોર્ડ્સને અસર કરતી સ્ટોરેજ આઉટેજને તાત્કાલિક વૃદ્ધિની જરૂર છે:

• યુનાઈટેડ સ્ટેટ્સ અને કેનેડા: ડાયલ કરો 911 જો સ્ટોરેજ ક્રેશ હોસ્પિટલ ક્લિનિકલ સિસ્ટમ્સને અક્ષમ કરે છે (EHR / PACS) અથવા રવાનગી. NAS-લક્ષિત રેન્સમવેરની જાણ કરો (DeadBolt, LockBit, Akira) થી CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), અથવા કેનેડિયન સેન્ટર ફોર સાયબર સિક્યુરિટી (1-833-CYBER-88).
• યુનાઇટેડ કિંગડમ: ડાયલ કરો 999 જીવન સુરક્ષા અથવા તીવ્ર NHS સંભાળને અસર કરતી કટોકટીઓ માટે. UK GDPR હેઠળ, મૂલ્યાંકન કરો કે શું કાયમી અનબેક-અપ વ્યક્તિગત ડેટા નુકશાન માટે ICO (ને સૂચિત કરવાની જરૂર છે.0303 123 1113) 72 કલાકની અંદર.
• યુરોપિયન યુનિયન: ડાયલ કરો 112 સમગ્ર EU માં. NIS2 ડાયરેક્ટિવ હેઠળની સંસ્થાઓએ 24 કલાકની અંદર તેમના રાષ્ટ્રીય CSIRTને મોટા ઓપરેશનલ આઉટેજની જાણ કરવી જોઈએ અને કાયમી વ્યક્તિગત ડેટાની ઉપલબ્ધતાની ખોટ GDPR કલમ 33 72 કલાકની અંદર જાણ કરવી જોઈએ.
• ઓસ્ટ્રેલિયા અને ન્યુઝીલેન્ડ: ડાયલ કરો 000 ઓસ્ટ્રેલિયામાં અથવા 111 ન્યુઝીલેન્ડમાં; ઈન્ફ્રાસ્ટ્રક્ચર અથવા રેન્સમવેર NAS ઘટનાઓની જાણ ACSC (1300 CYBER1) અથવા CERT NZ (0800 237 869).
• ભારત અને એશિયા-પેસિફિક: ડાયલ કરો 112 કટોકટીના પ્રતિભાવ માટે ભારતમાં; ઈન્ફ્રાસ્ટ્રક્ચર સ્ટોરેજની ઘટનાઓની જાણ CERT-In (ને કરોincident@cert-in.org.in) ફરજિયાત 6-કલાકની વિન્ડોમાં.

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

શા માટે કર્યું mdadm --assemble --force સાથે મારા RAID 5 એરે શરૂ કરવાનો ઇનકાર કરો not enough to start the array?¶

4-ડ્રાઈવમાં RAID 5 એરે, ઓછામાં ઓછું 4 માંથી 3 ડ્રાઇવ માટે પસાર થવું જોઈએ mdadm --assemble --force. ચલાવો sudo mdadm --examine /dev/sd[a-z]3 ત્રીજી ડ્રાઇવ કેમ નકારી કાઢવામાં આવી તે તપાસવા માટે: કાં તો તમે પાર્ટીશનને બદલે આખી ડિસ્ક પસાર કરી છે (/dev/sdd તેના બદલે /dev/sdd3), તેના સુપરબ્લોકને a તરીકે ચિહ્નિત કરવામાં આવ્યું હતું ફાજલ વિક્ષેપિત પુનઃનિર્માણ દ્વારા, અથવા ઉબુન્ટુના ઓટો-એસેમ્બલરે એક ડ્રાઇવને નિષ્ક્રિયમાં લૉક કરી /dev/md127 ઉપકરણ (ચલાવો sudo mdadm --stop --scan પ્રથમ, પછી ફરીથી ચલાવો mdadm --assemble --force --only read).

જો ડ્રાઇવ ફરીથી બનાવવાનું શરૂ કરે તો શું થશે (Recovery = 12%) બીજી ડ્રાઈવ બહાર પડી તે પહેલાં?¶

જો ડ્રાઇવ 2 મૃત્યુ પામી હોય, તો તમે ડ્રાઇવ 2 ને બદલી નાખ્યું છે, અને પર 12% ખરાબ સેક્ટરને કારણે પ્રોગ્રેસનું પુનઃનિર્માણ ડ્રાઇવ 3 ઑફલાઇન પડ્યું, 12%-રિબિલ્ટ રિપ્લેસમેન્ટ ડ્રાઇવ 2 નો ઉપયોગ કરશો નહીં. તેના બદલે, મૂળ ક્લોન કરો ડ્રાઇવ 3 સાથે ddrescue. કારણ કે પુનઃનિર્માણ 12% પર બંધ ન થાય ત્યાં સુધી ડ્રાઇવ 3 સંપૂર્ણપણે ચાલુ હતું, ડ્રાઇવ 1 નો ઉપયોગ કરીને ફક્ત વાંચવા માટેના એરેને બળ-એસેમ્બલ કરી રહ્યું હતું, ddrescue ડ્રાઇવ 3 અને ડ્રાઇવ 4નો ક્લોન (ડ્રાઇવ 2 છોડીને) તમને સુસંગત એરે આપે છે.

જો NAS પાવર સપ્લાય અથવા બોર્ડ મૃત્યુ પામે તો શું હું મારી સિનોલોજી અથવા QNAP ડ્રાઇવને તદ્દન નવી NAS ચેસિસમાં મૂકી શકું?¶

હા, બંને સિનોલોજી (HDD સ્થળાંતર) અને QNAP (ડાયરેક્ટ NAS સ્થળાંતર) RAID રૂપરેખાંકનને ડ્રાઈવો પર જ સંગ્રહિત કરો. જો કે, જો બે કે તેથી વધુ ડ્રાઈવો પહેલાથી જ નીકળી ગઈ હોય (`Volume Crashed`) ચેસિસ મૃત્યુ પામે તે પહેલાં, તેમને નવી NAS ચેસિસની અંદર બુટ કરશો નહીં, કારણ કે સ્થળાંતર વિઝાર્ડ પાર્ટીશનોને ફરીથી લખી શકે છે અથવા વિનાશક પુનઃનિર્માણને ટ્રિગર કરી શકે છે. ઉબુન્ટુ પર ફક્ત વાંચવા માટેના ડેટાને બચાવો.

હું કેવી રીતે જાણી શકું કે ડ્રોપ થયેલ ડ્રાઈવ ક્લોન કરવા માટે સલામત છે કે નહીં ddrescue ક્લીનરૂમ લેબની જરૂર વિરુદ્ધ?¶

ડ્રાઇવને SATA સાથે કનેક્ટ કરો, તેને ચાલુ કરો અને જોતી વખતે 10 સેકન્ડ માટે સાંભળો sudo dmesg -w. જો ડ્રાઇવ લયબદ્ધ ક્લિકિંગ, સ્ક્રેપિંગ, અથવા બઝિંગ અવાજો બનાવે છે, તો ઉપર સ્પિન થાય છે અને પાછા નીચે સ્પિન થાય છે અથવા ક્ષમતાની જાણ કરે છે 0 બી / 4.1 જીબી માં lsblk, રીડ/રાઇટ હેડ્સ શારીરિક રીતે નિષ્ફળ ગયા છે: તરત જ પાવર કાપી નાખો અને ક્લીનરૂમ લેબનો ઉપયોગ કરો. જો ડ્રાઇવ સરળતાથી સ્પિન કરે છે, તો તેની સંપૂર્ણ ક્ષમતા બતાવે છે lsblk, અને માત્ર લોગ Current_Pending_Sector અથવા સમય સમાપ્તિ ભૂલો, તેની સાથે ક્લોન કરો ddrescue.

"RAID 5 રાઈટ હોલ" શું છે અને કેવી રીતે કરે છે ZFS અથવા Btrfs પાવર આઉટેજ દરમિયાન તેને ટાળો?¶

પરંપરાગત માં RAID 5 / RAID 6 જર્નલ વિના, સ્ટ્રાઈપને અપડેટ કરવા માટે ડેટા બ્લોક અને પેરિટી બ્લોકને એકસાથે બે ડિસ્ક પર લખવાની જરૂર છે. જો પાવર મધ્ય-લેખનમાં નિષ્ફળ જાય, તો ડેટા અને પેરિટી હવે મેળ ખાતા નથી (આ હોલ લખો). ZFS (`RAIDZ`) અને Btrfs કોપી-ઓન-રાઈટનો ઉપયોગ કરીને લખવાના છિદ્રને દૂર કરો (`CoW`), દરેક નવી સ્ટ્રાઇપને ન વપરાયેલ બ્લોક્સમાં લખો અને સંપૂર્ણ સ્ટ્રાઇપ ડિસ્ક પર હોય પછી જ Uberblock/રુટ પોઇન્ટરને અપડેટ કરો.

શું હું ઉપયોગ કરી શકું dmsetup ક્લોન કરેલી ડ્રાઈવોમાં ફેરફાર કર્યા વિના RAID પરિમાણોને ચકાસવા માટે ઓવરલે?¶

હા, તમે કોપી-ઓન-રાઈટ બનાવી શકો છો (`CoW`) ફક્ત વાંચવા માટેના લૂપ ઉપકરણોની ટોચ પર ઓવરલે કરે છે (`losetup --read-only`Linux નો ઉપયોગ કરીને dmsetup (`snapshot` લક્ષ્ય) માં સ્પાર્સ ફાઇલો દ્વારા સમર્થિત /tmp. તરફથી કોઈપણ લખે છે mdadm --assemble --force અથવા fsck -y નિકાલજોગ માં જાઓ /tmp ઓવરલે ફાઇલ, જો જરૂરી હોય તો તમને 1 સેકન્ડમાં રીસેટ કરવા દે છે.

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

• NAS RAID એરે ડિગ્રેડેડ, બહુવિધ ડ્રાઇવ નિષ્ફળતા અને ZFS/Btrfs પુનઃપ્રાપ્તિ
• RAID નિયંત્રક કાર્ડ મૃત્યુ, વિદેશી રૂપરેખાંકન આયાત, અને શા માટે તમારે ક્યારેય ડિસ્ક શરૂ કરવી જોઈએ નહીં
• હાર્ડ ડ્રાઈવ નિષ્ફળતા અને ડેટા પુનઃપ્રાપ્તિ
• SSD અને NVMe સડન-ઓન્લી-રીડ મોડ, 0% ફાજલ બ્લોક્સ અને TRIM ડિસેબલ રેસ્ક્યૂ
• Linux, macOS અથવા Windows પર આકસ્મિક rm -rf અથવા Shift+Delete: તાત્કાલિક રીડ-ઓન્લી રીમાઉન્ટ
• કમ્પ્યુટર બેકઅપ, 3-2-1 વ્યૂહરચના અને આપત્તિ પુનઃપ્રાપ્તિ
• દેશ દ્વારા કટોકટી નંબરો

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

• Linux રેઇડ વિકી (raid.wiki.kernel.org(mdadm --assemble --force --readonly અને ઇવેન્ટ કાઉન્ટર મેળ ખાતો નથી)*.
• ફ્રી સોફ્ટવેર ફાઉન્ડેશન (GNU Project): જીએનયુ ddrescue મેન્યુઅલ: ફેઇલિંગ મીડિયામાંથી ફોરેન્સિક ડેટા પુનઃપ્રાપ્તિ.
• OpenZFS દસ્તાવેજીકરણ (openzfs.github.io): ZFS પૂલ આયાત પુનઃપ્રાપ્તિ (zpool import -F, ફક્ત વાંચવા માટે આયાત, અને zdb નિરીક્ષણ).
• Synology Inc.: Synology નોલેજ સેન્ટર: જ્યારે મારી Synology NAS માં ખામી સર્જાય ત્યારે હું ડેટા પુનઃપ્રાપ્ત કરવા માટે PC નો ઉપયોગ કેવી રીતે કરી શકું (mdadm + LVM2 માઉન્ટ કરવાનું).
• નેશનલ ઇન્સ્ટિટ્યુટ ઓફ સ્ટાન્ડર્ડ્સ એન્ડ ટેકનોલોજી (NIST) (યુનાઈટેડ સ્ટેટ્સ): સ્પેશિયલ પબ્લિકેશન 800-209: સ્ટોરેજ ઈન્ફ્રાસ્ટ્રક્ચર માટે સુરક્ષા માર્ગદર્શિકા.