पुन: उपयोग करने के बजाय नए सरणी बनाए जाने के बाद RAID 5 डेटा पुनर्प्राप्त करें


35

दोस्तों कृपया मदद करें - मैं हाथ में एक प्रमुख सिरदर्द (आदर्श तूफान की स्थिति) के साथ एक नवाब हूं।

मैं अपने ubuntu 11.04 पर एक 3tb hdd को सॉफ्टवेयर RAID 5 के रूप में कॉन्फ़िगर किया गया है। डेटा को कंप्यूटर हार्ड ड्राइव से साप्ताहिक रूप से कॉपी किया गया था जब तक कि पूरी तरह से विफल नहीं हो गया और फेंक दिया गया। कुछ दिनों पहले हमारे पास एक पावर आउटेज था और मेरे बॉक्स को रिबूट करने के बाद छापे को माउंट नहीं किया गया था। मेरी असीम बुद्धि में मैं प्रवेश कर गया

mdadm --create -f...

के बजाय कमान

mdadm --assemble

और उस ट्रैस्टी को नोटिस नहीं किया जो मैंने बाद में किया था। इसने सरणी को नीचा दिखाना शुरू कर दिया और इसे बनाने और आगे बढ़ाने के लिए आगे बढ़ना शुरू किया जिसमें ~ 10 घंटे लगते थे। वापस जाने के बाद मैंने देखा कि सरणी सफलतापूर्वक ऊपर और चल रही है, लेकिन छापे नहीं है

मेरा मतलब है कि अलग-अलग ड्राइव्स का विभाजन (विभाजन प्रकार f8) होता है, लेकिन md0डिवाइस नहीं है। हॉरर में एहसास कि मैंने क्या किया है मैं कुछ समाधान खोजने की कोशिश कर रहा हूं। मैं बस प्रार्थना करता हूं कि --createहार्ड ड्राइवर की संपूर्ण सामग्री को अधिलेखित न करें।

क्या कोई मुझे इसमें मदद कर सकता है - ड्राइव पर मौजूद डेटा बहुत महत्वपूर्ण और अद्वितीय है ~ 10 साल के फोटो, डॉक्स इत्यादि।

क्या यह संभव है कि गलत क्रम में भाग लेने वाले हार्ड ड्राइव को निर्दिष्ट करके mdadmउन्हें अधिलेखित कर सकते हैं? जब मैं करता हूं

mdadm --examine --scan 

मुझे कुछ ऐसा मिलता है ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

दिलचस्प रूप से पर्याप्त नाम 'छापा' हुआ करता था और न कि मेजबान के साथ: 0 जोड़ा गया था।

यहाँ 'सैनिटाइज़्ड' कॉन्फिगरेशन प्रविष्टियाँ हैं:

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1

CREATE owner=root group=disk mode=0660 auto=yes

HOMEHOST <system>

MAILADDR root


ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b


Here is the output from mdstat

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>


fdisk shows the following:

fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e

Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd

Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687

Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059

Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

मेरे सुझाव के अनुसार मैंने सुपरब्लॉक को साफ किया और --assume-cleanविकल्प के साथ सरणी को फिर से बनाया लेकिन बिना किसी भाग्य के।

क्या कोई उपकरण है जो मुझे कम से कम कुछ डेटा को पुनर्जीवित करने में मदद करेगा? क्या कोई मुझे बता सकता है कि डेटा को नष्ट करने के लिए mdadm --create क्या और कैसे करता है ताकि मैं जो कुछ भी किया गया था, उसे करने के लिए एक उपकरण लिख सकूं?

छापे के फिर से बनाने के बाद मैं fsck.ext4 / dev / md0 चलाता हूं और यहां आउटपुट है

रूट @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: सुपरब्लॉक अमान्य, बैकअप ब्लॉक की कोशिश कर रहा है ...sck.ext4: सुपर में खराब मैजिक नंबर- ब्लॉक करने की कोशिश करते हुए खोलने के लिए / देव / md0

सुपरब्लॉक को पढ़ा नहीं जा सकता है या एक सही ext2 फाइलसिस्टम का वर्णन नहीं करता है। यदि उपकरण मान्य है और इसमें वास्तव में एक ext2 फाइलसिस्टम है (और स्वैप या ufs या कुछ और नहीं), तो सुपरब्लॉक भ्रष्ट है, और आप वैकल्पिक सुपरब्लॉक के साथ e2fsck चलाने का प्रयास कर सकते हैं: e2fsck -b 8193


प्रति शन्स के सुझाव पर मैंने कोशिश की

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

और हर बैकअप ब्लॉक के साथ fsck.ext4 चलाएं, लेकिन सभी ने निम्नलिखित लौटाया:

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

कोई सुझाव?

सादर!


1
शायद एक दिन लोगों को एहसास हो सकता है कि RAID5 एक भयानक विचार क्यों है। तब तक, 1) लोग डेटा खो देंगे। 2) हम इस तरह के सवाल करेंगे।
टॉम ओ'कॉनर

11
@Tom O'Connor ... क्योंकि स्पष्ट रूप से, RAID5 उपयोगकर्ता त्रुटि के लिए दोषी है। : रोली:
रियलिटी एक्सट्रैक्टर

2
उम्मीद है, शेन का जवाब डेटा को बचा सकता है, लेकिन फिर से, सबूत है कि RAID अकेले भंडारण के लिए सबसे अच्छा क्यों नहीं है। बैकअप भी चाहिए। (लेकिन सवाल और महाकाव्य जवाब के लिए +1) जिसके परिणामस्वरूप
tombull89

4
मुझे पता है कि यह अक्सर दोहराया जाता है, लेकिन छापे एक बैकअप समाधान नहीं है । संदेश को वास्तव में घर चलाने की जरूरत है।
सेरेक्स

जवाबों:


89

ठीक है - कुछ मुझे आपके मुद्दे के बारे में गुस्सा आ रहा था, इसलिए मैंने उस व्यवहार में गोता लगाने के लिए एक वीएम को निकाल दिया जिसकी उम्मीद की जानी चाहिए। मुझे मिल जाएगा जो मुझे एक मिनट में गुस्सा दिला रहा था; पहले मुझे यह कहने दो:

कुछ भी प्रयास करने से पहले इन ड्राइव का बैकअप लें !!

आप पहले से ही नुकसान हो सकता है क्या resync से परे है; क्या आप स्पष्ट कर सकते हैं कि आपके कहने का मतलब क्या था:

मेरे सुझाव के अनुसार मैंने सुपरब्लॉक को साफ किया और सरणी को फिर से बनाया - साफ-सुथरे विकल्प के साथ, लेकिन बिना किसी भाग्य के।

यदि आप एक भाग गए mdadm --misc --zero-superblock, तो आपको ठीक होना चाहिए।

वैसे भी, कुछ नए डिस्क को परिमार्जित करें और उनमें से कुछ भी करने से पहले उनमें से कुछ भी लिखने के लिए कुछ भी करने से पहले उनकी सटीक वर्तमान छवियों को पकड़ो।

dd if=/dev/sdd of=/path/to/store/sdd.img

कहा जा रहा है कि .. यह इन चीजों पर संग्रहीत डेटा की तरह लग रहा है चौंकाने वाला स्वच्छंद resyncs के लिए लचीला है। आगे पढ़ें, आशा है, और यह वह दिन हो सकता है कि मैंने उत्तर की लंबाई सीमा को मारा।


सबसे अच्छा मामला परिदृश्य

मैंने आपके परिदृश्य को फिर से बनाने के लिए एक वीएम को एक साथ फेंक दिया। ड्राइव सिर्फ 100 एमबी की हैं इसलिए मैं प्रत्येक रेसक्यूक्स पर हमेशा इंतजार नहीं करूंगा, लेकिन यह एक बहुत सटीक प्रतिनिधित्व होना चाहिए अन्यथा।

सरणी को सामान्य रूप से और डिफ़ॉल्ट रूप में बनाया गया - 512k चंक्स, बाएं-सममित लेआउट, अक्षर क्रम में डिस्क .. कुछ खास नहीं।

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

अब तक सब ठीक है; चलो एक फाइल सिस्टम बनाते हैं, और उस पर कुछ डेटा डालते हैं।

root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

ठीक है। हमें उस पर एक फ़ाइल सिस्टम और कुछ डेटा ("डेटा" datafile, और उस SHA1 हैश के साथ यादृच्छिक डेटा के 5MB मूल्य randomdata) मिल गए हैं; आइए देखें कि जब हम दोबारा निर्माण करते हैं तो क्या होता है।

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

इन छोटे डिस्क के साथ रेसक्यू बहुत जल्दी समाप्त हो गया, लेकिन यह हुआ। तो यहाँ क्या मुझे पहले से गुस्सा था; आपका fdisk -lआउटपुट mdडिवाइस पर कोई पार्टीशन टेबल नहीं होने से यह समस्या नहीं है, यह अपेक्षित है। आपका फ़ाइल सिस्टम बिना किसी विभाजन तालिका के सीधे नकली ब्लॉक डिवाइस पर रहता है।

root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

हाँ, कोई विभाजन तालिका नहीं। परंतु...

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Resync के बाद पूरी तरह से मान्य फाइल सिस्टम। तो यह अच्छा है; आइए हमारी डेटा फ़ाइलों की जाँच करें:

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

ठोस - कोई डेटा भ्रष्टाचार नहीं! लेकिन यह ठीक उसी सेटिंग्स के साथ है, इसलिए दोनों RAID समूहों के बीच अलग से कुछ भी मैप नहीं किया गया था। इससे पहले कि हम इसे तोड़ने की कोशिश करें, इस चीज़ को नीचे गिरा दें।

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

एक कदम पीछे हटना

इससे पहले कि हम इसे तोड़ने की कोशिश करें, चलो बात करते हैं कि इसे तोड़ना क्यों मुश्किल है। RAID 5 एक समता ब्लॉक का उपयोग करके काम करता है जो सरणी में हर दूसरे डिस्क पर ब्लॉक के समान क्षेत्र की सुरक्षा करता है। समता केवल एक विशिष्ट डिस्क पर नहीं है, यह सामान्य ऑपरेशन में डिस्क के पार बेहतर लोड रीड आउट के लिए समान रूप से डिस्क के चारों ओर घुमाया जाता है।

समानता की गणना करने के लिए XOR ऑपरेशन इस तरह दिखता है:

DISK1  DISK2  DISK3  DISK4  PARITY
1      0      1      1    = 1
0      0      1      1    = 0
1      1      1      1    = 0

तो, डिक्स के बीच समानता फैली हुई है।

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

एक मृत या लापता डिस्क को प्रतिस्थापित करते समय आमतौर पर एक रीकंस्ट्रक्शन किया जाता है; यह भी mdadm createआश्वासन दिया है कि डिस्क पर डेटा के साथ संरेखित करता है क्या RAID की ज्यामिति की तरह लग रहा है। उस स्थिति में, सरणी युक्ति में अंतिम डिस्क वह है जो 'सिंक किया गया' है - अन्य डिस्क पर मौजूदा डेटा का सभी सिंक के लिए उपयोग किया जाता है।

तो, 'नई' डिस्क के सभी डेटा मिटा दिए गए हैं और फिर से बनाए गए हैं; या तो क्या होना चाहिए था के लिए समता ब्लॉकों से बाहर ताजा डेटा ब्लॉकों का निर्माण, या फिर ताजा समता ब्लॉकों का निर्माण।

क्या अच्छा है कि उन दोनों चीजों के लिए प्रक्रिया बिल्कुल समान है: बाकी डिस्क से डेटा में एक एक्सओआर ऑपरेशन। इस मामले में resync प्रक्रिया अपने लेआउट में हो सकती है कि एक निश्चित ब्लॉक को एक पैरिटी ब्लॉक होना चाहिए, और सोचें कि यह एक नया समानता ब्लॉक बना रहा है, जब वास्तव में यह एक पुराने डेटा ब्लॉक को फिर से बना रहा है। यहां तक ​​कि अगर यह सोचता है कि यह इसका निर्माण कर रहा है:

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

... यह केवल DISK5ऊपर दिए गए लेआउट से पुनर्निर्माण हो सकता है।

तो, सरणी के गलत होने पर भी डेटा का लगातार बने रहना संभव है।


वर्क्स में एक बंदर को फेंकना

(नहीं एक रिंच, पूरे बंदर)

टेस्ट 1:

चलो सरणी को गलत क्रम में बनाते हैं! sdc, तब sdd, तब sdb।।

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

ठीक है, यह सब अच्छा और अच्छा है। क्या हमारे पास एक फाइल सिस्टम है?

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

नहीं! ऐसा क्यों है? क्योंकि डेटा के सभी वहाँ है, यह गलत क्रम में है; एक बार 512KB का क्या था, फिर बी, ए, बी और आगे के 512KB को अब B, A, B, A. से फेरबदल किया गया है। डिस्क अब फाइल सिस्टम चेकर के लिए जिबरिश जैसा दिखता है, यह नहीं चलेगा। आउटपुट mdadm --misc -D /dev/md1हमें अधिक विस्तार देता है; यह इस तरह दिख रहा है:

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1
   3       8       17        2      active sync   /dev/sdb1

जब यह इस तरह दिखना चाहिए:

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   1       8       33        1      active sync   /dev/sdc1
   3       8       49        2      active sync   /dev/sdd1

तो, यह सब ठीक है और अच्छा है। हमने इस बार नए समता वाले ब्लॉक के साथ डेटा ब्लॉक का एक पूरा समूह ओवरवोट किया। सही क्रम के साथ अब फिर से बनाएं:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

साफ, वहाँ अभी भी एक फाइल सिस्टम है! अभी भी डेटा मिला है?

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

सफलता!

परीक्षण २

ठीक है, चलो चंक आकार बदलते हैं और देखें कि क्या हमें कुछ टूट जाता है।

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

हाँ, हाँ, यह जब इस तरह से स्थापित किया जाता है। लेकिन, क्या हम ठीक हो सकते हैं?

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

सफलता, फिर से!

परीक्षण ३

यह वह है जो मैंने सोचा था कि डेटा को निश्चित रूप से मार देगा - चलो एक अलग लेआउट एल्गोरिथ्म करते हैं!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).

डरावना और बुरा - यह सोचता है कि यह कुछ पाया और कुछ फिक्सिंग करना चाहता है! Ctrl+ C!

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

ठीक है, संकट टल गया। आइए देखें कि क्या गलत लेआउट के साथ पुन: जुड़ने के बाद भी डेटा बरकरार है:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

सफलता!

टेस्ट 4

चलिए यह भी साबित करते हैं कि सुपरब्लॉक शून्य हानिकारक वास्तविक त्वरित नहीं है:

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

हाँ, कोई बड़ी बात नहीं।

परीक्षण ५

चलो बस सब कुछ फेंक दिया है जो हमें मिला है। सभी 4 पिछले परीक्षण, संयुक्त।

  • गलत डिवाइस ऑर्डर
  • गलत चंक आकार
  • गलत लेआउट एल्गोरिथ्म
  • शून्य सुपरब्लॉक (हम दोनों कृतियों के बीच ऐसा करेंगे)

आगे!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1

निर्णय?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

वाह।

इसलिए, ऐसा लगता है कि इनमें से कोई भी कार्रवाई किसी भी तरह से दूषित डेटा नहीं है। मैं इस परिणाम से काफी हैरान था, स्पष्ट रूप से; मुझे चंक आकार परिवर्तन पर डेटा हानि के मध्यम बाधाओं की उम्मीद थी, और लेआउट परिवर्तन पर कुछ निश्चित नुकसान। मैंने आज कुछ सीखा।


तो .. मुझे अपना डेटा कैसे मिलेगा ??

पुरानी प्रणाली के बारे में आपके पास जितनी भी जानकारी है वह आपके लिए अत्यंत उपयोगी होगी। यदि आप फाइलसिस्टम प्रकार जानते हैं, यदि आपके पास /proc/mdstatड्राइव ऑर्डर, एल्गोरिथ्म, चंक आकार और मेटाडेटा संस्करण की जानकारी के साथ आपकी कोई पुरानी प्रतियां हैं । क्या आपके पास mdadm का ईमेल अलर्ट सेट है? यदि ऐसा है, तो एक पुराना खोजें; यदि नहीं, तो जाँच करें /var/spool/mail/root~/.bash_historyअपने मूल निर्माण में है या नहीं यह देखने के लिए अपनी जाँच करें ।

तो, उन चीजों की सूची जो आपको करनी चाहिए:

  1. ddकुछ भी करने से पहले डिस्क का बैकअप लें !!
  2. fsckवर्तमान, सक्रिय md के लिए प्रयास करें - आप पहले की तरह ही उसी क्रम में निर्मित हो सकते हैं। यदि आप फाइलसिस्टम प्रकार जानते हैं, तो यह मददगार है; उस विशिष्ट fsckउपकरण का उपयोग करें । यदि कोई भी उपकरण कुछ भी ठीक करने की पेशकश करता है, तो उन्हें न दें जब तक कि आप सुनिश्चित न हों कि उन्हें वास्तव में वैध फाइल सिस्टम मिल गया है! अगर fsckआपके लिए कुछ तय करने का प्रस्ताव आता है, तो यह पूछने में संकोच न करें कि यह वास्तव में मदद कर रहा है या केवल डेटा के बारे में बात करने के लिए।
  3. विभिन्न मापदंडों के साथ सरणी के निर्माण का प्रयास करें। यदि आपके पास एक पुराना है /proc/mdstat, तो आप बस दिखावा कर सकते हैं कि यह क्या दिखाता है; यदि नहीं, तो आप अंधेरे में थोड़े हैं - सभी अलग-अलग ड्राइव ऑर्डर की कोशिश करना उचित है, लेकिन हर संभव क्रम के साथ हर संभव चंक आकार की जांच करना व्यर्थ है। प्रत्येक के लिए, fsckयह देखने के लिए कि क्या आपको कुछ भी आशाजनक मिलता है।

तो, वह है। उपन्यास के लिए क्षमा करें, यदि आपके कोई प्रश्न हैं, और शुभकामनाएँ देने के लिए स्वतंत्र महसूस करें!

फुटनोट: 22 हजार पात्रों के तहत; लंबाई की 8k + शर्मीली


8
यह एक अद्भुत जवाब है।
एंटोनी बेनकेमॉन

3
मैं यह भी नहीं जानता कि क्या कहना है ... ब्रावो !!! कुदोस टू शेन मैडेन। मैं डिस्क का बैकअप लेने जा रहा हूं और अपने सुझावों के साथ शुरुआत करूंगा। धन्यवाद, वास्तव में कोई बड़ा धन्यवाद नहीं !!!
ब्रिगेडियरिन

3
मैं बस ... वाह। शानदार जवाब। मुझे लगता है कि 30,000 चरित्र की सीमा को तोड़ने का एकमात्र उत्तर इवान एंडर्सन "हाउ डूइंग सबनेटिंग वर्क" निबंध है।
tombull89

3
एस एफ पर सबसे अच्छा जवाब जहां तक ​​मेरा सवाल है।
चॉपर 3

14
आप, सर, इंटरनेट पर जीत हासिल करें।
मार्क हेंडरसन

5

यदि आप भाग्यशाली हैं तो आपको रिकवरी सॉफ़्टवेयर के साथ अपनी फ़ाइलों को वापस पाने में कुछ सफलता मिल सकती है जो एक टूटे हुए RAID -5 सरणी को पढ़ सकते हैं। जीरो असेसमेंट रिकवरी वह है जिसमें मुझे पहले भी सफलता मिली है।

हालांकि, मुझे यकीन नहीं है कि एक नया एरे बनाने की प्रक्रिया चली गई है और सभी डेटा को नष्ट कर दिया है, इसलिए यह एक आखिरी मौका प्रयास हो सकता है।


बहुत बहुत धन्यवाद मार्क। मुझे इसे एक मौका और देना होगा। क्या आपको पता है कि यह ड्राइव को संशोधित करता है? यदि ऐसा है तो मैं एक डिस्क की प्रतिलिपि बनाऊंगा और अन्य उपकरणों के साथ भी प्रयास करूंगा।
ब्रिगेडियरिन

@Brigadieren - नहीं, क्षमा करें, मैं इस बात से परिचित नहीं हूं कि RAID5 कैसे काम करता है।
मार्क हेंडरसन

@Brigadieren mdadm प्रलेखन के अनुसार , बनाने की प्रक्रिया डेटा को नष्ट नहीं करेगी, बस resync - लेकिन अगर इसे एक ज्यामिति चुना जाता है जो आपके मूल के साथ मेल नहीं खाता है, तो हो सकता है कि उसने नई समता के लेखन के साथ डेटा को नष्ट कर दिया हो। अगर बाद में मेरे पास कुछ खाली समय है तो मैं वीएम में आपकी स्थिति को फिर से बनाने के बारे में देख सकता हूं, यह देखने के लिए कि क्या मैं कोई अंतर्दृष्टि जोड़ सकता हूं। मैं डिस्क पर लिखने वाले किसी भी पुनर्प्राप्ति चरण का प्रयास करने से पहले ड्राइव की पूर्ण प्रतियां हथियाने की सलाह दूंगा - आप प्रतियां बनाने के लिए अतिरिक्त ड्राइव प्राप्त करने पर विचार कर सकते हैं।
शेन झुंझलाना

मुझे यकीन नहीं है कि सिंक का क्या कारण है - तथ्य यह है कि सरणी को पहले स्थान पर अपमानित किया गया था (बिजली आउटेज के कारण) या कुछ और? मुझे आश्चर्य है कि अगर mdadm -create कोई भेद करता है कि क्या मैं मूल रूप से दिए गए ड्राइव ऑर्डर को अलग-अलग निर्दिष्ट करता हूं?
ब्रिगेडियरिन

@ ब्रिगेडियरन सिंक हमेशा क्रिएट पर होता है।
शेन झुंझलाना

5

मेरे पास एक समान समस्या थी:
एक सॉफ़्टवेयर RAID5 सरणी की विफलता के बाद मैंने mdadm --createइसे दिए बिना निकाल दिया --assume-clean, और अब सरणी माउंट नहीं कर सका। खुदाई के दो सप्ताह बाद मैंने अंततः सभी डेटा को पुनर्स्थापित कर दिया। मुझे उम्मीद है कि नीचे दी गई प्रक्रिया किसी का समय बचाएगी।

कहानी संक्षिप्त में

समस्या इस तथ्य के कारण थी कि mdadm --createएक नया सरणी बनाया गया था जो दो पहलुओं में मूल से अलग था:

  • विभाजन का अलग क्रम
  • अलग RAID डेटा ऑफ़सेट

जैसा कि शेन मैडेन द्वारा शानदार जवाब में दिखाया गया है , mdadm --createज्यादातर मामलों में डेटा नष्ट नहीं होता है! विभाजन आदेश और डेटा ऑफसेट को खोजने के बाद मैं सरणी को पुनर्स्थापित कर सकता हूं और इसमें से सभी डेटा निकाल सकता हूं।

आवश्यक शर्तें

मेरे पास RAID सुपरब्लॉक का कोई बैकअप नहीं था, इसलिए मुझे पता था कि यह Xubuntu 12.04.0 की स्थापना के दौरान बनाए गए 8 विभाजन पर एक RAID5 सरणी था। इसमें एक ext4 फाइल सिस्टम था। ज्ञान का एक और महत्वपूर्ण टुकड़ा एक फ़ाइल की एक प्रति थी जिसे RAID सरणी पर भी संग्रहीत किया गया था।

उपकरण

Xubuntu 12.04.1 लाइव सीडी का उपयोग सभी काम करने के लिए किया गया था। आपकी स्थिति के आधार पर, आपको निम्नलिखित कुछ साधनों की आवश्यकता हो सकती है:

mdadm का संस्करण जो डेटा ऑफ़सेट को निर्दिष्ट करने की अनुमति देता है

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep - द्विआधारी डेटा की खोज

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, माउंट और एक हेक्साडेसिमल कैलकुलेटर - रेपो से मानक उपकरण

पूर्ण बैकअप के साथ प्रारंभ करें

डिवाइस फ़ाइलों का नामकरण, जैसे /dev/sda2 /dev/sdb2आदि, लगातार नहीं है, इसलिए आपके द्वारा दिए गए ड्राइव के सीरियल नंबर को लिखना बेहतर है

sudo hdparm -I /dev/sda

फिर एक बाहरी एचडीडी को हुक करें और अपने RAID सरणी के हर विभाजन का बैक अप लें:

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

मूल RAID5 लेआउट निर्धारित करें

विभिन्न लेआउट यहां वर्णित हैं: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
यह जानने के लिए कि मूल सरणी पर डेटा की स्ट्रिप्स का आयोजन कैसे किया गया था, आपको एक यादृच्छिक-दिखने वाली फ़ाइल की एक प्रतिलिपि की आवश्यकता होती है जिसे आप जानते थे। सरणी पर संग्रहीत। वर्तमान में उपयोग किया जाने वाला डिफ़ॉल्ट चंक आकार mdadm512KB है। N विभाजन की एक सरणी के लिए, आपको कम से कम आकार की फ़ाइल (N + 1) * 512KB चाहिए। एक jpeg या वीडियो अच्छा है क्योंकि यह बाइनरी डेटा के अपेक्षाकृत अद्वितीय सब्सट्रिंग प्रदान करता है। मान लीजिए हमारी फाइल को कहा जाता है picture.jpg। हम एन + 1 स्थिति में 32 बाइट्स डेटा को 100k से शुरू करते हैं और 512k से बढ़ाते हैं:

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

फिर हम अपने सभी कच्चे विभाजनों पर इन सभी ब्युट्रेट्स की घटनाओं की खोज करते हैं, इसलिए कुल मिलाकर (N + 1) * N कमांड्स, जैसे:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

इन आदेशों को अलग-अलग डिस्क के लिए समानांतर में चलाया जा सकता है। 38GB के विभाजन के स्कैन में लगभग 12 मिनट लगे। मेरे मामले में, प्रत्येक 32-बाइट स्ट्रिंग को सभी आठ ड्राइव के बीच केवल एक बार पाया गया था। Bgrep द्वारा लौटाए गए ऑफ़सेट्स की तुलना करके आप इस तरह की तस्वीर प्राप्त करते हैं:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

हम एक सामान्य बाएं-सममित लेआउट देखते हैं , जो डिफ़ॉल्ट है mdadm। इससे भी महत्वपूर्ण बात, अब हम विभाजन के क्रम को जानते हैं। हालाँकि, हम नहीं जानते कि कौन सा विभाजन सरणी में पहला है, क्योंकि उन्हें चक्रीय रूप से स्थानांतरित किया जा सकता है।

नोट भी पाया ऑफसेट के बीच की दूरी। मेरे मामले में यह 512KB था। चंक का आकार वास्तव में इस दूरी से छोटा हो सकता है, इस मामले में वास्तविक लेआउट अलग होगा।

मूल चंक आकार का पता लगाएं

हम एक picture.jpg-दूसरे से अलग-अलग अंतराल पर 32 बाइट्स डेटा पढ़ने के लिए एक ही फाइल का उपयोग करते हैं । हम ऊपर से जानते हैं कि ऑफसेट 100k पर डेटा /dev/sdh2ऑफसेट 612k पर है /dev/sdb2, और 1124k पर है /dev/sdd2। इससे पता चलता है कि चंक का आकार 512KB से बड़ा नहीं है। हम यह सत्यापित करते हैं कि यह 512KB से छोटा नहीं है। इसके लिए हम ऑफसेट को 356k पर डंप करते हैं और देखते हैं कि यह किस विभाजन पर बैठता है:

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

यह ऑफसेट 612k के समान विभाजन पर है, जो इंगित करता है कि चंक का आकार 256KB नहीं है। हम इसी तरह से छोटे चंक आकारों को समाप्त करते हैं। मैं 512KB विखंडू केवल संभावना होने के साथ समाप्त हुआ।

लेआउट में पहला विभाजन खोजें

अब हम विभाजन के क्रम को जानते हैं, लेकिन हम यह नहीं जानते हैं कि कौन सा विभाजन पहले होना चाहिए, और कौन से RAID डेटा ऑफ़सेट का उपयोग किया गया था। इन दो अज्ञात को खोजने के लिए, हम सही chunk लेआउट और एक छोटे डेटा ऑफसेट के साथ एक RAID5 सरणी बनाएंगे, और इस नए सरणी में हमारी फ़ाइल सिस्टम की शुरुआत के लिए खोज करेंगे।

शुरू करने के लिए, हम विभाजन के सही क्रम के साथ एक सरणी बनाते हैं, जो हमें पहले मिला था:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

हम सत्यापित करते हैं कि आदेश जारी करके पालन किया जाता है

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

अब हम RAID सरणी में N + 1 ज्ञात बीटस्ट्रेस के ऑफसेट का निर्धारण करते हैं। मैं एक रात के लिए एक स्क्रिप्ट चलाता हूं (लाइव सीडी sudo पर पासवर्ड के लिए नहीं पूछता है :):

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

टिप्पणियों के साथ आउटपुट:

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

इस डेटा के आधार पर हम देखते हैं कि तीसरा स्ट्रिंग नहीं मिला। इसका अर्थ है कि चंक /dev/sdd2का उपयोग समता के लिए किया जाता है। यहाँ नए सरणी में समता पदों का चित्रण है:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

हमारा उद्देश्य यह है कि किस विभाजन को सरणी से शुरू करना है, ताकि समता को सही जगह पर स्थानांतरित किया जा सके। चूँकि समता को दो विखंडुओं को बाईं ओर स्थानांतरित किया जाना चाहिए, विभाजन क्रम को दाईं ओर दो चरणों में स्थानांतरित किया जाना चाहिए। इस प्रकार इस डेटा ऑफसेट के लिए सही लेआउट है ahbdcefg:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

इस बिंदु पर हमारे RAID सरणी में सही रूप में डेटा होता है। आप भाग्यशाली हो सकते हैं ताकि RAID डेटा ऑफसेट वही हो जो मूल सरणी में था, और फिर आप संभवतः विभाजन को माउंट करने में सक्षम होंगे। दुर्भाग्य से यह मेरा मामला नहीं था।

डेटा संगति सत्यापित करें

हम यह सत्यापित करते हैं कि picture.jpgसरणी से एक प्रति निकालकर डेटा विखंडू की एक पट्टी के अनुरूप है । इसके लिए हम 100k पर 32-बाइट स्ट्रिंग के लिए ऑफसेट का पता लगाते हैं:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

हम फिर परिणाम से 100 * 1024 को हटाते हैं और प्राप्त दशमलव मान को skip=पैरामीटर में उपयोग करते हैं ddcount=के आकार है picture.jpgबाइट में:

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

जाँच करें कि के extract.jpgरूप में ही है picture.jpg

RAID डेटा ऑफसेट खोजें

एक सिडेन: mdadmसंस्करण 3.2.3 के लिए डिफ़ॉल्ट डेटा ऑफसेट 2048 सेक्टर है। लेकिन समय के साथ इस मूल्य को बदल दिया गया है। यदि मूल सरणी आपके वर्तमान की तुलना में एक छोटे डेटा ऑफ़सेट का उपयोग करती है mdadm, तो mdadm --createबिना --assume-cleanफ़ाइल सिस्टम की शुरुआत को अधिलेखित किए बिना ।

पिछले अनुभाग में हमने एक RAID सरणी बनाई थी। सत्यापित करें कि कुछ अलग-अलग विभाजनों के लिए जारी करके यह RAID डेटा ऑफसेट है:

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 512-बाइट सेक्टर 1MB है। चूंकि चंक का आकार 512KB है, इसलिए वर्तमान डेटा ऑफ़सेट दो हिस्सा है।

यदि इस बिंदु पर आपके पास दो-चंक ऑफसेट है, तो यह संभवतः काफी छोटा है, और आप इस पैराग्राफ को छोड़ सकते हैं।
हम एक 512KB- चंक के डेटा ऑफसेट के साथ एक RAID5 सरणी बनाते हैं। एक हिस्सा शुरू करने से पहले समता को बाईं ओर एक कदम बदल दिया जाता है, इस प्रकार हम विभाजन अनुक्रम को एक कदम बाईं ओर स्थानांतरित करके क्षतिपूर्ति करते हैं। इसलिए 512KB डेटा ऑफसेट के लिए, सही लेआउट है hbdcefga। हम mdadmडेटा ऑफ़सेट (उपकरण अनुभाग देखें) का समर्थन करने वाले संस्करण का उपयोग करते हैं। किलोबाइट में इसकी भरपाई होती है:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

अब हम एक मान्य ext4 सुपरब्लॉक की खोज करते हैं। सुपरब्लॉक संरचना यहां देखी जा सकती है: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
हम उस जादुई नंबर की घटनाओं की शुरुआत को स्कैन करते हैं, s_magicजिसके बाद जादू नंबर आता है s_stateऔर s_errors। देखने के लिए बयाना हैं:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

उदाहरण आदेश:

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

मैजिक नंबर 0x38 बाइट्स सुपरब्लॉक में शुरू होता है, इसलिए हम ऑफसेट की गणना करने और पूरे सुपरस्टार की जांच करने के लिए 0x38 को प्रतिस्थापित करते हैं:

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

यह एक वैध सुपरब्लॉक लगता है। s_log_block_size0x18 पर फ़ील्ड 0002 है, जिसका अर्थ है कि ब्लॉक का आकार 2 ^ (10 + 2) = 4096 बाइट्स है।s_blocks_count_lo0x4 पर 03f81480 ब्लॉक है जो 254GB है। अछा लगता है।

अब हम इसकी प्रतियों को खोजने के लिए सुपरब्लॉक के पहले बाइट्स की घटनाओं के लिए स्कैन करते हैं। हेक्सडम्प आउटपुट की तुलना में बाइट फ़्लिपिंग पर ध्यान दें:

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

यह पूरी तरह से बैकअप सुपरब्लॉक के अपेक्षित पदों के साथ संरेखित करता है:

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

इसलिए फाइल सिस्टम 0xdc80000, यानी 225792KB पर विभाजन प्रारंभ से शुरू होता है। चूंकि हमारे पास 8 विभाजन हैं, जिनमें से एक समानता के लिए है, हम ऑफसेट को 7 से विभाजित करते हैं। यह हर विभाजन पर 33030144 बाइट्स ऑफसेट देता है, जो कि वास्तव में 63 RAID विखंडू है। और चूंकि वर्तमान RAID डेटा ऑफ़सेट एक हिस्सा है, हम यह निष्कर्ष निकालते हैं कि मूल डेटा ऑफ़सेट 64 हिस्सा था, या 32768KB। शिफ्टिंग hbdcefgaसही करने के लिए 63 बार लेआउट देता हैbdcefgah

हम अंत में सही RAID सरणी बनाते हैं:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

देखा!


बहुत बढ़िया चलना। एक नोट - 53EF00000100 EXT4 हेडर के लिए मान्य एंकर नहीं लगता है। Ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block के अनुसार दो बाइट्स 53EF के बाद केवल 0100, 0200 या 0400 हो सकते हैं।
मैट

0

मेरा मुद्दा भी ऐसा ही था। मैंने अपने ओएस / बूट ड्राइव को Ubuntu 12.04 की एक साफ इंस्टॉल के साथ स्वरूपित और पुन: इंस्टॉल किया, फिर mdadm --create ... कमांड को चलाया और इसे माउंट नहीं कर सका।

यह कहा कि यह एक वैध सुपरब्लॉक या विभाजन नहीं था।

इसके अलावा, जब मैंने mdadm छापे को रोका, तो मैं अब नियमित डिवाइस को माउंट नहीं कर सकता था।

मैं mke2fs और e2fsck के साथ सुपरब्लॉक की मरम्मत करने में सक्षम था:

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

फिर भागा:

e2fsck -b 32768 -y /dev/sdc1

उस सुपरब्लॉक को पुनर्स्थापित किया ताकि मैं ड्राइव को माउंट कर सकूं और पढ़ सकूं।

मेरे द्वारा बनाए गए सुपरब्लॉक या विभाजन को नष्ट किए बिना सरणी को काम करने के लिए:

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

डेटा सत्यापित करने के बाद, मैं दूसरी ड्राइव जोड़ूंगा:

mdadm --add /dev/md0 /sdd1

0

मैं पहले दी गई कुछ जानकारी को अपडेट कर रहा हूं। जब मेरी मदरबोर्ड की मृत्यु हुई, तो मैंने 3-डिस्क raid5 सरणी ठीक काम की थी। सरणी / dev / md2 को / होम विभाजन 1.2TB और / dev / md3 के रूप में / var विभाजन 300GB के रूप में आयोजित किया गया।

मेरे पास "महत्वपूर्ण" सामान के दो बैकअप थे और यादृच्छिक चीजों का एक गुच्छा जो मैंने इंटरनेट के विभिन्न हिस्सों से पकड़ा था जो मुझे वास्तव में गुजरना चाहिए था और चुनिंदा रूप से डंप किया गया था। अधिकांश बैकअप 25GB या उससे कम की .tar.gz फ़ाइलों में टूट गए थे, और / etc की एक अलग प्रति भी बैकअप की गई थी।

शेष फाइल सिस्टम 38GB के दो छोटे raid0 डिस्क पर आयोजित किया गया था।

मेरी नई मशीन पुराने हार्डवेयर के समान थी, और मैंने मशीन को सभी पांच डिस्क को प्लग इन करके और पुराने जेनेरिक कर्नेल का चयन करके बस चला दिया। इसलिए मेरे पास स्वच्छ फाइल सिस्टम के साथ पांच डिस्क थे, हालांकि मैं निश्चित नहीं हो सकता था कि डिस्क सही क्रम में हैं, और डेबियन जेसी के एक नए संस्करण को स्थापित करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि मैं जरूरत पड़ने पर मशीन को अपग्रेड कर सकता हूं, और अन्य को छांट सकता हूं समस्या का।

दो RAID0 डिस्क पर स्थापित नई जेनेरिक प्रणाली के साथ, मैंने सरणियों को वापस एक साथ रखना शुरू किया। मैं यह सुनिश्चित करना चाहता था कि मेरे पास सही क्रम में डिस्क हैं। मुझे क्या करना चाहिए था:

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

लेकिन मैंने नहीं किया। ऐसा लगता है कि mdadm बहुत स्मार्ट है और एक uuid दिया गया है, यह पता लगा सकता है कि कौन सी ड्राइव कहाँ जाती है। यहां तक ​​कि अगर बायोस / sdc को sda / sdc के रूप में नामित करता है, तो mdadm इसे सही ढंग से एक साथ रखेगा (YMMV हालांकि)।

इसके बजाय मैंने जारी किया: mdadm --create /dev/md2 without the --assume-cleanऔर resync को पूरा करने के लिए / dev / sde1 पर अनुमति दी। मेरे द्वारा की गई अगली गलती / dev / md2, / sde1 में अंतिम ड्राइव के बजाय / dev / sdc1 पर काम करना था। कभी भी mdadm को लगता है कि एक समस्या है कि यह आखिरी ड्राइव है जिसे किक आउट या फिर से सिंक किया गया है।

उसके बाद, mdadm को कोई सुपरब्लॉक नहीं मिला, और e2fsck -n भी नहीं कर सका।

इस पृष्ठ को प्राप्त करने के बाद, मैं ड्राइव के लिए अनुक्रम को खोजने की कोशिश करने की प्रक्रिया से गुजरा (किया), वैध डेटा की जांच (9MB फ़ाइल का 6MB सत्यापित), सही क्रम में डिस्क मिली, सीडी, uuid को पकड़ा / md2 और / md3 के पुराने /etc/mdadm.conf से और कोडांतरण की कोशिश की।

ठीक है, /dev/md3शुरू किया, और mdadm --misc -D /dev/md3तीन स्वस्थ विभाजन दिखाए, और सही क्रम में डिस्क। /dev/md2यह भी अच्छा लगा, जब तक कि मैंने फाइलसिस्टम माउंट करने की कोशिश नहीं की।

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

फाइलसिस्टम ने माउंट होने से इनकार कर दिया, और e2fsck को कोई सुपरब्लॉक नहीं मिला। इसके अलावा, जब ऊपर वर्णित सुपरब्लॉक की जाँच हो रही है, तो कुल ब्लॉक काउंट a880 0076 या a880 0076 या 5500 1176 के रूप में पाया गया, जो 1199.79 के डिस्क क्षमता आकार से मेल नहीं खाता, मेरे mdadm की सूचना दी। "सुपरब्लॉक" के स्थानों में से कोई भी ऊपर के पदों में डेटा के साथ संरेखित नहीं किया गया है।

मैंने सभी / var का बैकअप लिया, और डिस्क को पोंछने के लिए तैयार किया। यह देखने के लिए कि क्या सिर्फ / md2 पोंछना संभव है, (मेरे पास इस बिंदु पर खोने के लिए और कुछ नहीं था) मैं निम्नलिखित को नापसंद करता हूं:

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 


# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

सब ठीक लग रहा था, सिवाय uid में बदलाव के। इसलिए कुछ और जाँच के बाद, मैंने ६०० जीबी बैकअप डेटा / देव / md2 पर लिखा। फिर, बिना बताए और ड्राइव को फिर से माउंट करने की कोशिश की:

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

क्या आप मेरे साथ मजाक कर रहे हैं? फ़ाइल पर मेरे 600GB के बारे में क्या?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

आह - आसानी से तय। /etc/mdadm.conf में एक पंक्ति को असंबद्ध

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

यिप्पी!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.