एक अपमानित 5 वीं छापे से चरम डेटा वसूली

वास्तविक घटनाओं पर लिखा।

क्रियाओं और दाने के निर्णयों के किसी भी पुनरावृत्ति से डेटा का पूर्ण नुकसान हो सकता है। हॉव्टो-शिकोव के लिए नहीं, यह सामग्री केवल डिस्क मीडिया पर डेटा की प्रस्तुति की तस्वीर को फिर से बनाने के लिए है।

तो चलिए शुरू करते हैं। इनपुट डेटा:

• प्रत्येक पर 7 डिस्क, 2 प्राथमिक विभाजन;
• 1 विभाजन 7 और कई मिररिंग (RAID1);
• दूसरा विभाजन RAID5, जिसके तहत LVM कताई है।

बिजली में उछाल और लोहे के साथ कुछ अन्य समस्याओं के कारण दो ड्राइव रातोंरात विफल हो जाते हैं। डिस्क को वापस लेने का प्रयास असफल रहा, जैसे कि सिस्टम ने दो घंटे के लिए मृतक छापे पर ऑटोपायलट में काम किया, सब कुछ के अलावा, डिस्क या तो जीवन में आ गई या फिर से मर गई, कर्नेल ने उस समय किस डिस्क पर काम नहीं किया, अर्थात्। उन पर क्या लिखा गया था और यह कैसे हुआ - कोई केवल अनुमान लगा सकता है।
सामान्य तौर पर, हमारे पास पूरी तरह से मृत छापे होते हैं। और mdadm यहाँ शक्तिहीन है।

पहले से ही क्या किया गया है, आप वापस नहीं आएंगे, आपको किसी तरह डेटा को पुनर्स्थापित करने की आवश्यकता है। क्योंकि बैकअप, हमेशा की तरह, नहीं। कार्य योजना:

1. जीवित डेटा को नई डिस्क (नों) में कॉपी करें;
2. मूल डिस्क क्रम को पुनर्स्थापित करें;
3. मारे गए डिस्क को अलग करने के लिए (बिंदु 1 देखें);
4. छापे प्रारूप (मेटा) की गणना करें, जैसा कि यह निकला, नरम-छापे, कुछ संस्करण से शुरू होकर, डिस्क के हेडर में इस डेटा को संग्रहीत करने से पहले, अपने लिए डिस्क की शुरुआत में 1 केबी आवंटित करता है;
5. चंक / पट्टी के आकार की गणना करें, इसे 64k से 512k में भी बदल दिया गया था;
6. डिस्क को एक साथ इकट्ठा करें
7. LVM पुनर्प्राप्त करें और तार्किक संस्करणों को फिर से लिखें

अनुच्छेद 1 के अनुसार।

सब कुछ तुच्छ है, हम एक बड़ी मात्रा के नए डिस्क खरीदते हैं, उन पर LVM बनाते हैं, प्रत्येक डिस्क के लिए एक अलग LV का चयन करते हैं, और dd का उपयोग करके 2 विभाजन को कॉपी करते हैं। हमें डेटा के साथ लंबे समय तक खेलना होगा।

अब बाकी वस्तुओं के लिए।

सिद्धांत निम्नानुसार है: डिस्क के क्रम और विखंडू के आकार को निर्धारित करने के लिए, आपको कुछ प्रकार की लॉग फ़ाइल खोजने की आवश्यकता है जिसमें घटना की तारीख और समय नीचे रखा जाएगा। जल्दी से नहीं कहा। मेरे मामले में, लॉग फ़ाइलें एक अलग lv अनुभाग में थीं। काम के लिए, हमें पर्याप्त आकार की एक निर्देशिका की भी आवश्यकता है (मेरे मामले में, मैंने अपने काम के लिए 200 जीबी आवंटित किया है)। अध्ययन के लिए हो रही है। प्रत्येक ड्राइव से पहले 64k लें:
for i in abcdefg; do dd if=/dev/jbod/sd${i} bs=64 count=1024 of=/mnt/recover/${i}; done

हमें 64 केबी की 7 फाइलें मिलती हैं। यहां हम तुरंत समझ सकते हैं कि किस मेटा-डेटा प्रारूप का उपयोग किया जाता है। उदाहरण के लिए, मेटाडेटा 1, 1.0, 1.1, 1.2 के लिए - यह इस तरह दिखता है:
mega@megabook ~ $ dd if=/dev/gentoo/a bs=1024 count=64 | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 fc 4e 2b a9 01 00 00 00 00 00 00 00 00 00 00 00 |.N+.............|
00001010 ee 6f de dc c3 94 9c 58 47 d0 cc 91 9c f7 c5 35 |.o.....XG......5|
00001020 6d 65 67 61 62 6f 6f 6b 3a 30 00 00 00 00 00 00 |megabook:0......|
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001040 96 e2 6c 4e 00 00 00 00 05 00 00 00 02 00 00 00 |..lN............|
00001050 00 5c 00 00 00 00 00 00 00 04 00 00 07 00 00 00 |.\..............|
00001060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001080 00 04 00 00 00 00 00 00 00 5c 00 00 00 00 00 00 |.........\......|
00001090 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000010a0 00 00 00 00 00 00 00 00 64 23 f5 c9 5f 2a 64 68 |........d#.._*dh|
000010b0 e8 92 f2 1a 8c ca ad 98 00 00 00 00 00 00 00 00 |................|
000010c0 9a e2 6c 4e 00 00 00 00 12 00 00 00 00 00 00 00 |..lN............|
000010d0 ff ff ff ff ff ff ff ff f6 51 38 f5 80 01 00 00 |.........Q8.....|
000010e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001100 00 00 01 00 02 00 03 00 04 00 05 00 fe ff 06 00 |................|
00001110 fe ff fe ff fe ff fe ff fe ff fe ff fe ff fe ff |................|
*
00001400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
64+0
64+0
65536 (66 kB)00010000
, 0,000822058 c, 79,7 MB/c

mega@megabook ~ $ mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Sep 11 20:32:22 2011
Raid Level : raid5
Array Size : 70656 (69.01 MiB 72.35 MB)
Used Dev Size : 11776 (11.50 MiB 12.06 MB)
Raid Devices : 7
Total Devices : 7
Persistence : Superblock is persistent

Update Time : Sun Sep 11 20:32:26 2011
State : clean
Active Devices : 7
Working Devices : 7
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : megabook:0 (local to host megabook)
UUID : ee6fdedc:c3949c58:47d0cc91:9cf7c535
Events : 18

Number Major Minor RaidDevice State
0 253 21 0 active sync /dev/dm-21
1 253 22 1 active sync /dev/dm-22
2 253 23 2 active sync /dev/dm-23
3 253 24 3 active sync /dev/dm-24
4 253 25 4 active sync /dev/dm-25
5 253 26 5 active sync /dev/dm-26
7 253 27 6 active sync /dev/dm-27

यह मेटाडेटा 1.2 का एक उदाहरण है। एक विशिष्ट विशेषता यह है कि ब्लॉक लगभग समान सामग्री (डिस्क संख्या को छोड़कर) के होंगे, जबकि शेष स्थान NULLs से भरा होगा। छापे की जानकारी निम्नलिखित पते पर स्थित है: 0x00001000-0x00001ffff।
मेटाडेटा के पुराने संस्करणों के लिए, छापे की जानकारी डिस्क लेआउट क्षेत्र में दर्ज की गई थी, और उपकरणों पर तुरंत डेटा शुरू हो गया था। यह मेटाडेटा 0.9 के लिए कुछ इस तरह दिखता है:
~ # dd if=/dev/jbod/sdb bs=1024 count=1 | hexdump -C
1+0
1+0
1024 (1,0 kB), 0,0200084 c, 51,2 kB/c
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 4c 41 42 45 4c 4f 4e 45 01 00 00 00 00 00 00 00 |LABELONE........|
00000210 1b 72 36 1f 20 00 00 00 4c 56 4d 32 20 30 30 31 |.r6. ...LVM2 001|
00000220 66 6d 59 33 4a 35 6b 72 46 73 6d 52 51 41 47 66 |fmY3J5krFsmRQAGf|
00000230 4c 30 72 53 6b 69 59 6e 31 43 6c 72 66 61 66 70 |L0rSkiYn1Clrfafp|
00000240 00 00 fa ff ed 02 00 00 00 00 06 00 00 00 00 00 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 |................|
00000270 00 f0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400


डिस्क से पहले 64kb के आगे के अध्ययन के बाद एक उत्सुक विशेषता सामने आई। जैसा कि यह निकला, LVM स्पष्ट पाठ में LV मार्कअप जानकारी संग्रहीत करता है। यह इस तरह दिखता है:
vg0 {
id = "xxxx"
seqno = 64
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "xxxxx"
device = "/dev/md2" # Hint only

status = ["ALLOCATABLE"]
dev_size = 5848847616 # 2,72358 Terabytes
pe_start = 384
pe_count = 713970 # 2,72358 Terabytes
}
}

logical_volumes {
--//--
log {
id = "l8OVMc-BUAj-YrIT-w8mh-YkvH-riS3-p1h6OY"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 2

segment1 {
start_extent = 0
extent_count = 12800 # 50 Gigabytes

type = "striped"
stripe_count = 1 # linear

stripes = [
"pv0", 410817
]
}
segment2 {
start_extent = 12800
extent_count = 5120 # 20 Gigabytes

type = "striped"
stripe_count = 1 # linear

stripes = [
"pv0", 205456
]
}
}
--//--
}

सुपर! हमें इससे क्या चाहिए। मुख्य आंकड़े जिन्हें निर्देशित किया जाना चाहिए वे हैं:

• limit_size = 8192 # 4 मेगाबाइट
• pe_start = 384
• धारियां = [pv0, 410817]
• हद_काउंट = 5120

ये नंबर क्या हैं ...

• कुछ हद तक क्लस्टर आकार जैसा है। न्यूनतम इकाई जिसे पूरे वीजी स्पेस में विभाजित किया गया है। क्यों 4 मेगाबाइट और क्या तोते में मापा जाता है? मैंने यह प्रश्न तब भी पूछा जब मैंने इसे देखा था, लेकिन जैसा कि यह निकला, सब कुछ सरल है - क्लस्टर आकार 512 बाइट्स है * 8192 = 4 एमबी
• pe_start - LVM हेडर कहाँ समाप्त होता है और डेटा कहाँ शुरू होता है।
• limit_count - अनुभाग के लिए आवंटित किए गए ब्लॉकों की संख्या।
• धारियों = [pv0, xxxx] - जहां से और जिस पर पीवी स्थित है।

मत भूलो कि हमारे पास 7 ड्राइव पर 5 वीं छापे हैं, सभी संख्याओं को 6 से विभाजित करें (क्योंकि 7 वीं समता है)
कम से कम किसी तरह के लॉग को खोजने की कोशिश करें। देखने के लिए हाथ / आंखें - यूटोपिया, एक स्क्रिप्ट लिखें:
dd if=/dev/recover/sda bs=512 skip=$[(8192*410817+384)/6] | hexdump -C | grep 'Aug 28' | head

जहां:
skip=(extent_size*stripes+pe_start)/6
bs=512 --

डिस्क की एक संक्षिप्त सरसराहट के बाद, हमें आउटपुट पर कुछ इस तरह मिलता है:
02d08100 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 36 20 |Aug 28 00:06:06 |
02d081c0 3d 0a 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 |=.Aug 28 00:06:0|
02d08410 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 37 20 |Aug 28 00:06:07 |
02d08570 70 0a 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 |p.Aug 28 00:06:0|
02d085d0 65 78 74 3d 0a 41 75 67 20 32 38 20 30 30 3a 30 |ext=.Aug 28 00:0|
02d086b0 64 3d 2a 29 29 22 0a 41 75 67 20 32 38 20 30 30 |d=*))".Aug 28 00|
02d08710 65 73 74 61 6d 70 0a 41 75 67 20 32 38 20 30 30 |estamp.Aug 28 00|
02d08770 73 3d 30 20 74 65 78 74 3d 0a 41 75 67 20 32 38 |s=0 text=.Aug 28|
02d089c0 6f 72 64 3d 2a 29 29 22 0a 41 75 67 20 32 38 20 |ord=*))".Aug 28 |
02d08a20 6d 65 73 74 61 6d 70 0a 41 75 67 20 32 38 20 30 |mestamp.Aug 28 0|

हम पते लेते हैं: 02d08770, शेष के साथ 512 से विभाजित करें, हमें मिलता है:
mega@megabook ~ $ echo $[0x02d08770/512]
92227
mega@megabook ~ $ echo $[0x02d08770/512/2048]
45

मेगाबाइट की एक जोड़ी रखो और देखो कि वहाँ क्या होता है:
for i in abcdefg; do dd if=/dev/recover/sd${i} of=/mnt/recover/${i} bs=512 count=1024 skip=$[(8192*410817+384)/6+(48*2048)] ; done

हमें 512kb की 7 फाइलें मिलती हैं। हम इसे एक पाठ संपादक के साथ खोलते हैं और तिथियों को देखते हैं, कौन सी फाइलें चेकसम (समता) से पढ़ी जाती हैं। हम डिस्क के क्रम की व्यवस्था करते हैं, साथ ही देखते हैं कि किस आकार का हिस्सा है। यदि 64kb के बाद चेकसम शुरू होता है, तो 64kb, यदि नहीं, तो 512 या उससे अधिक होने की संभावना है। 1 ब्लॉक की भरपाई के साथ कार्रवाई दोहराएं:
for i in abcdefg; do dd if=/dev/recover/sd${i} of=/mnt/recover/${i}.1 bs=512 count=1024 skip=$[(8192*410817+384)/6+(48*2048)+1] ; done

कागज पर एक तालिका बनाएँ। कौन सा ड्राइव पहला है, समता ब्लॉक कहां है। यह कहना गलत नहीं होगा कि 5 RAID के 4 ऑर्डर हैं: लेफ्ट एसिंक्रोनस, लेफ्ट सिंक्रोनस, राइट एसिंक्रोनस और राइट सिंक्रोनस। विवरण यहाँ वर्णित हैं: www.accs.com/p_and_p/RAID/LinuxRAID.html ।

एक पीटा डिस्क की अस्वीकृति के लिए, रचनात्मक कार्य और उपरोक्त सामग्री पर्याप्त होनी चाहिए।

अब, विखंडू के आकार, मेटाडेटा तालिका के प्रकार और वर्गों के क्रम को जानकर, आप छापे को फिर से बनाने के लिए mdadm के साथ खेलने का प्रयास कर सकते हैं। रणनीतिक चाल यह है कि यदि आप एक वास्तविक डिस्क के बजाय गायब शब्द लिखते हैं तो mdadm अपमानित छापे बना सकते हैं। ज्ञान का उपयोग करके हम छापे बनाने की कोशिश कर रहे हैं। मेटाडेटा के प्रकार को निर्दिष्ट करना सुनिश्चित करें! और किसी भी मामले में उपरोक्त सामग्री के गहन अध्ययन के बिना निम्नलिखित आदेश को दोहराएं नहीं! । सरणी की सही विधानसभा को सत्यापित करने के लिए, मैंने 2 जीबी वर्चुअल मशीन विभाजन का उपयोग किया।
lvcreate -L2G -nnagios recover
mdadm -C /dev/md0 -l 5 -n 7 --metadata 0.9 -c 64 /dev/recover/[af] missing
dd if=/dev/md0 bs=512 skip=$[8192*XXXX+384] count=$[8192*512] | dd of=/dev/recover/nagios
cfdisk /dev/recover/nagios

यदि cfdisk कहता है कि डिस्क लेआउट तालिका सही नहीं है, तो हम सरणी को नष्ट कर देते हैं और डिस्क के विस्थापन के साथ सरणी के निर्माण को दोहराते हैं ... पहले वाले को अंत में फेंक दिया जाता है। यानी
mdadm -S /dev/md0
mdadm -C /dev/md0 -l 5 -n 7 --metadata 0.9 -c 64 /dev/recover/[bf] missing /dev/recover/a

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

आपके द्वारा यह पता लगाने के बाद कि आपके पास कौन सा अनुभाग है, छोटे LV अनुभाग का चयन करें और इसे छवि और समानता में कॉपी करें, जैसा कि मैंने नागों की नकल की है। माउंट करने की कोशिश करो। यदि आपने गलत ड्राइव (लापता) को फेंक दिया है, तो सबसे अधिक संभावना dmesg रिपोर्ट करेगी कि ड्राइव के लॉग के साथ समस्याएं हैं (जैसा कि ड्राइव में से एक डेटा कर्व्स के रूप में योगदान देता है)। ब्रेकपॉइंट्स को दोहराएं, लापता स्थिति के प्रतिस्थापन के साथ डिस्क बनाएं और कॉपी करें। यानी उदाहरण के लिए, sdg ड्राइव जोड़ें, जिसे मैंने गायब होने के स्थान पर जोड़ा था, और sdf ड्राइव के बजाय, लापता लिखें:
mdadm -C /dev/md0 -l 5 -n 7 --metadata 0.9 -c 64 /dev/recover/[be] missing /dev/recover/sdg /dev/recover/a

और इसलिए जब तक प्राप्त डेटा संभव के रूप में प्रासंगिक नहीं है।
सिम पर, मुझे लगता है कि कहानी खत्म हो गई है।
मैं LVM पुनर्प्राप्ति पर कुछ शब्द जोड़ूंगा (ताकि इन पतों से पीड़ित न हो)।
यहाँ सब कुछ सरल है। यदि आप प्रासंगिकता प्राप्त करते हैं - यह स्वयं को सक्रिय करने में सक्षम होगा, यदि नहीं, तो बैकअप प्राप्त करें, आमतौर पर / etc / lvm / backup / VG-NAME में। मैंने, यह देखते हुए कि मेरा रूट विभाजन उसी LVM पर था, इस निर्देशिका को / boot / lvm में स्थानांतरित कर दिया और इस पर सहानुभूति बना दी। और फिर सब कुछ सरल है:
vgcfgrestore -f /path/to/backup-file vg-name

यदि यह मदद नहीं करता है, तो कहना है, चेकसम में शपथ लेना शुरू कर देता है, आप इस चीज़ को थोड़ा हैक कर सकते हैं:
dd if=/dev/zero of=/dev/md0 bs=512 count=10
pvcreate /dev/md0
pvdisplay /dev/md0 | grep 'PV UUID'

अगला, बैकअप फ़ाइल को संपादित करें, वहां UUID बदलें, उसी नाम से एक वीजी बनाएं जैसा कि इस खंड में पहले था
vgcreate vg0 /dev/md0
vgcfgrestore -f /path/to/backup-file vg0

इन धोखाधड़ी के बाद सब कुछ बहाल किया जाना चाहिए और वीजी बैकअप फ़ाइल बनाने के समय प्रासंगिक होगा।

सामान्य तौर पर, सिम पर, मुझे लगता है कि सामग्री पर्याप्त रूप से बताई गई है, मैं एक आरक्षण करूंगा कि ये सभी चरम उपाय हैं और कम से कम आपके पास डिस्क की पूरी प्रतिलिपि होनी चाहिए, अर्थात। स्रोत डिस्क पर नहीं , बल्कि उनके कलाकारों पर काम किया जाता है।

यह भी देखें:

• www.accs.com/p_and_p/RAID/LinuxRAID.html
• www.chiark.greenend.org.uk/~peterb/linux/raidextract
• code.google.com/p/pyraid/wiki/HOWTO
• www.chiark.greenend.org.uk/~peterb/linux/raidextract/stripesize#lvm1
• खैर, लेखक के बारे में मत भूलना