क्या नुकसान के बारे में चेतावनी के बिना हार्ड ड्राइव पर डेटा घट सकता है?

हम सभी अपने डेटा और फ़ाइलों को सुरक्षित और अक्षुण्ण रखने के बारे में चिंता करते हैं, लेकिन क्या डेटा के क्षतिग्रस्त होने और उपयोगकर्ता द्वारा किसी भी प्रकार की अधिसूचना या समस्या के बारे में चेतावनी दिए बिना पहुँचा जा सकता है? आज के SuperUser Q & A पोस्ट में एक चिंतित पाठक के प्रश्न का उत्तर है.

आज का प्रश्न और उत्तर सत्र सुपरयूज़र के सौजन्य से आता है-स्टैक एक्सचेंज का एक उपखंड, क्यू एंड ए वेब साइटों का एक समुदाय-संचालित समूह है।.

सामान्यीकरण के फोटो सौजन्य (फ़्लिकर).

प्रश्न

सुपरयूजर रीडर टोपो मोर्टो यह जानना चाहता है कि हार्ड ड्राइव पर डेटा को नुकसान के बारे में चेतावनी के बिना अस्वीकृत और एक्सेस किया जा सकता है या नहीं:

क्या यह संभव है कि हार्ड ड्राइव का भौतिक क्षरण किसी फाइल की सामग्री में बिट्स को "फ्लिप" करने का कारण बन सकता है, बिना ऑपरेटिंग सिस्टम के परिवर्तन को देखे बिना और फाइल को पढ़ते समय उपयोगकर्ता को इसके बारे में सूचित करना? उदाहरण के लिए, ASCII पाठ फ़ाइल में एक "p" (बाइनरी 01110000) को "q" में बदल सकता है (बाइनरी 01110001), तब जब कोई उपयोगकर्ता फ़ाइल खोलता है, तो वे "q" को देखते हैं बिना यह जाने कि एक विफलता हुई है।?

मुझे FAT, NTFS या ReFS से संबंधित उत्तरों में दिलचस्पी है (यदि इससे कोई फर्क पड़ता है)। मैं जानना चाहता हूं कि क्या ऑपरेटिंग सिस्टम उपयोगकर्ताओं को इससे बचाता है, या यदि हमें समय के साथ प्रतियों के बीच हमारे डेटा की जांच करनी चाहिए.

क्या हार्ड ड्राइव पर डेटा ख़राब हो सकता है और क्षति के बारे में चेतावनी के बिना पहुँचा जा सकता है?

उत्तर

सुपरयूजर योगदानकर्ता गुंट्रम ब्लोहम का जवाब हमारे लिए है:

हां, एक चीज है जिसे बिट रोट कहा जाता है। लेकिन नहीं, यह किसी अनजान व्यक्ति को प्रभावित नहीं करेगा.

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

जब हार्ड ड्राइव सेक्टर को पढ़ता है, तो यह इन ईसीसी कोड की जांच करता है और यदि आवश्यक हो (और यदि संभव हो तो) डेटा की मरम्मत करता है। आगे क्या होता है यह परिस्थितियों और हार्ड ड्राइव के फर्मवेयर पर निर्भर करता है, जो ड्राइव के पदनाम से प्रभावित होता है.

यदि किसी सेक्टर को पढ़ा जा सकता है और उसे ईसीसी कोड की कोई समस्या नहीं है, तो इसे ऑपरेटिंग सिस्टम पर भेज दिया जाता है.

यदि किसी सेक्टर की आसानी से मरम्मत की जा सकती है, तो मरम्मत किए गए संस्करण को डिस्क पर लिखा जा सकता है, वापस पढ़ा जा सकता है, फिर यह निर्धारित करने के लिए सत्यापित किया जाता है कि त्रुटि एक यादृच्छिक (यानी कॉस्मिक किरणें, आदि) थी या यदि मीडिया के साथ कोई व्यवस्थित त्रुटि है।.

यदि हार्ड ड्राइव यह निर्धारित करता है कि मीडिया के साथ कोई त्रुटि है, तो यह इस क्षेत्र को पुनः प्राप्त करता है.

यदि कुछ पढ़ने के प्रयासों के बाद एक सेक्टर को न तो पढ़ा जा सकता है और न ही ठीक किया जा सकता है (हार्ड ड्राइव पर जिसे एक RAID हार्ड ड्राइव के रूप में निर्दिष्ट किया गया है), तो हार्ड ड्राइव सेक्टर को फिर से खोल देगा, और नियंत्रक को बताएगा कि कोई समस्या थी । यह अन्य RAID सदस्यों से सेक्टर को फिर से संगठित करने के लिए RAID नियंत्रक पर निर्भर करता है और इसे असफल हार्ड ड्राइव पर वापस लिखता है, जो तब इसे वास्तविक क्षेत्र में संग्रहीत करता है (उम्मीद है कि समस्या नहीं है).

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

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

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

मैंने खुद कभी एक भी त्रुटि नहीं देखी है, लेकिन मैंने बहुत सारे हार्ड ड्राइव देखे हैं जहां पूरे क्षेत्र में असफलता हुई है.

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

कृपया ध्यान दें कि chkdsk और फ़ाइल सिस्टम जो स्वचालित रूप से स्वयं की मरम्मत करते हैं, फाइलों के भीतर डेटा की मरम्मत का पता नहीं लगाते हैं। ये फ़ाइल सिस्टम की संरचना के भीतर भ्रष्टाचार पर लक्षित होते हैं, जैसे निर्देशिका प्रविष्टि और आवंटित ब्लॉकों की संख्या के बीच फ़ाइल के आकार में अंतर। NTFS की सेल्फ-हीलिंग सुविधा संरचनात्मक नुकसान का पता लगाएगी और इसे आपके डेटा को और अधिक प्रभावित करने से रोकेगी, लेकिन यह किसी भी डेटा की मरम्मत नहीं करेगा जो पहले से ही क्षतिग्रस्त है.

बेशक, अन्य कारण हैं, जिससे डेटा क्षतिग्रस्त हो सकता है। उदाहरण के लिए, नियंत्रक पर खराब रैम डेटा को हार्ड ड्राइव में भेजे जाने से पहले भी बदल सकता है। उस स्थिति में, हार्ड ड्राइव पर कोई भी तंत्र डेटा का पता नहीं लगाएगा या मरम्मत नहीं करेगा, और यह एक कारण हो सकता है कि फ़ाइल सिस्टम की संरचना क्षतिग्रस्त है। अन्य कारणों में सॉफ़्टवेयर बग्स, ब्लैकआउट्स, हार्ड ड्राइव पर लिखते समय (हालाँकि यह फ़ाइल सिस्टम जर्नलिंग द्वारा संबोधित किया गया है), या खराब फ़ाइल सिस्टम ड्राइवर (लिनक्स पर NTFS ड्राइवर केवल पढ़ने के लिए डिफ़ॉल्ट रूप से लंबे समय से NTFS के इंजीनियर थे, क्योंकि प्रलेखित नहीं, और डेवलपर्स को अपने स्वयं के कोड पर भरोसा नहीं था).

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

ये अन्य कारण हैं कि कुछ फ़ाइल सिस्टम, जैसे कि ZFS, त्रुटियों का पता लगाने के लिए अतिरिक्त चेक राशि की जानकारी रखते हैं। वे आपको बहुत अधिक चीजों से बचाने के लिए डिज़ाइन किए गए हैं जो कि केवल बिट रोट की तुलना में गलत हो सकते हैं.

स्पष्टीकरण में कुछ जोड़ना है? टिप्पणियों में विचार व्यक्त करो। अन्य टेक-सेवी स्टैक एक्सचेंज उपयोगकर्ताओं से अधिक उत्तर पढ़ना चाहते हैं? पूरी चर्चा धागा यहाँ देखें.