क्या Git डेटा गिरावट को रोकता है

Question

मैंने पढ़ा कि ZFS और Btrfs डेटा की गिरावट को रोकने के लिए चेकसम का उपयोग करते हैं और मैंने पढ़ा कि Git में हैशिंग के माध्यम से अखंडता है जो अनिवार्य रूप से प्रत्येक कमिट के साथ है।

मैं भंडारण के लिए Btrfs RAID 1 के साथ लिनक्स एनएएस पर एक Git सर्वर का उपयोग करने जा रहा था, लेकिन अगर Git में अखंडता है तो मुझे लगता है कि यह आवश्यक नहीं होगा (कम से कम नहीं तो डेटा गिरावट को रोकने के लिए जो मुझे चाहिए)।

प्रश्न: तो क्या जीआईटी की अखंडता हालांकि अनिवार्य रूप से हैश के साथ सब कुछ रोकती है या बिट-रोट के खिलाफ मदद करती है?

Comments

प्रसिद्ध केडीई 2013 के लगभग एक दुःस्वप्न है यहाँ कुछ हद तक प्रासंगिक।

— इविलनोटिक्सिस्ट इडोनोटेक्सिस्ट

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

— एलो

ध्यान दें कि यदि किसी दिए गए मशीन पर केवल कुछ प्राचीन वस्तुओं के लिए भ्रष्टाचार होता है, तो उन वस्तुओं के रेपो के अन्य क्लोन पर मौजूद होने की अधिक संभावना है, जबकि (कम) अधिक हाल की फाइलें अभी भी उपयोग करने योग्य हो सकती हैं। मुझे नहीं पता कि यह कैसे पैक फ़ाइलों के साथ एकीकृत करता है, हालांकि।

— o11c

Answer 1

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

Comments

fsckहमेशा मेरे लिए एक बुरे शब्द की तरह क्यों दिखता है ... मुझे लगता है कि अगर सकारात्मक हो जाता है और आपके पास एक बैकअप नहीं है जो हालांकि उपयुक्त हो सकता है;)

— CAD97

@ CAD97 प्रोग्रामर इन अपेक्षाकृत लंगड़ी सज़ा के लिए जाने जाते हैं। यह वास्तव में काफी आम है ... मेरे सिर के ऊपर से, आपके पास श (शेल), बीएचएस (बॉर्न शेल) जैसी चीजें हैं, और फिर बैश (बॉर्न फिर से शेल) ... अंतिम एक लंगड़ा सजा है ...

— नेल्सन

@ नेल्सन मछली को मत भूलना

— user253751

@ CAD97 हेल, git के नाम को तब ही माना जा सकता है, जब यह आपके लिए सही काम नहीं कर रहा हो।

— एसजीआर

@ CAD97 - और इससे पहले कि आप इसे fvcctk जैसे झंडे के साथ चलाएं - क्योंकि - यदि आप इसे इस तरह से चला रहे हैं, तो आपका डेटा पहले से ही "fvcctk" एड हो सकता है। ;)

— जो

Answer 2

"रोकथाम" से आपका क्या अर्थ है, इस पर निर्भर करता है।

(सबसे पहले, बिट-रोट एक शब्द है जिसमें कई परिभाषाएँ हैं। यह सवाल रखरखाव के अभाव में कोड के अयोग्य होने के बारे में नहीं है ।)

यदि आप "रोकथाम" से मतलब है कि यह बिट्स के क्षय द्वारा भ्रष्टाचार का पता लगाएगा, हां, यह काम करेगा। हालांकि यह उस भ्रष्टाचार को ठीक करने में मदद नहीं करेगा : हैश केवल त्रुटि का पता लगाता है, सुधार नहीं ।

यह आमतौर पर "अखंडता" से होता है: डेटा के अनधिकृत / अनपेक्षित हेरफेर का पता लगाने की संभावना , न कि इसे रोकने या ठीक करने की संभावना।

आप आम तौर पर अभी भी बैकअप के साथ एक RAID1 चाहते हैं (संभवतः ZFS स्नैपशॉट या समान के साथ लागू किया जाता है, मैं RAID1 + स्नैपशॉट पर ZFS शब्दार्थ से परिचित नहीं हूं), कई कारणों से:

• यदि डिस्क खराब रूप से विफल हो जाती है, तो आपको अपने डेटा को पुनर्स्थापित करने के लिए या तो एक RAID1 (या हाल ही में बैकअप) की आवश्यकता है; कोई भी त्रुटि सुधार पूरी डिस्क विफल होने के लिए सही नहीं हो सकता, जब तक कि इसमें डेटा की पूरी प्रतिलिपि (RAID1) न हो। थोड़े समय के लिए, आपके पास अनिवार्य रूप से RAID1 होना चाहिए।

• यदि आप गलती से पुर्जों या रिपॉजिटरी को पूरी तरह से हटा देते हैं, तो आपको एक बैकअप की आवश्यकता है (RAID1 आपकी रक्षा नहीं करता है क्योंकि यह तुरंत सभी उपकरणों में परिवर्तन को दर्शाता है)

ब्लॉक-लेवल RAID1 (उदाहरण के लिए LVM या इसी तरह के माध्यम से) अपने आप में केवल दो डिस्क के साथ डेटा के मूक क्षय के खिलाफ आपकी रक्षा नहीं करेगा : RAID नियंत्रक को पता नहीं चल सकता है कि दोनों डिस्क में से कौन सा डेटा सही रखता है। आपको इसके लिए अतिरिक्त जानकारी चाहिए, जैसे फाइलों पर एक चेकसम। यह वह जगह है जहां ZSF और btrfs चेकसम में आते हैं: वे इस्तेमाल किया जा सकता है (जो कहना है कि वे नहीं है कर रहे हैं इन मामलों में इस्तेमाल किया, मैं नहीं जानता कि कैसे ZFS या btrfs चीजें वहाँ संभाल) भेद करने के लिए जो दो डिस्क के रखती है सही डेटा।

Comments

यदि आप नहीं करना चाहते हैं तो मिररिंग के साथ जाने की आवश्यकता नहीं है। ZFS समानता के 1, 2 या 3 ड्राइव के साथ स्ट्रिपिंग का समर्थन करता है; और ड्राइव की एक मनमानी संख्या के साथ मिररिंग (एकल ड्राइव = कोई अतिरेक सहित)। मेरा मुख्य बल्क स्टोरेज एक ZZZ2 कॉन्फ़िगरेशन में छह ड्राइव के साथ ZFS है, जो मूल रूप से फाइल सिस्टम स्तर RAID6 (दो ड्राइव के साथ अतिरेक के लायक) है। यह उन ड्राइवों में से किसी एक के नुकसान के साथ ही एक से अधिक अपरिवर्तनीय त्रुटियों का पता लगा सकता है और पुनर्प्राप्त कर सकता है; या दो ड्राइव का नुकसान और रेजिलवर के दौरान कहीं और कोई त्रुटि नहीं; डेटा के किसी भी नुकसान के बिना। बैकअप की अनुशंसा अभी भी की जाती है।

— एक CVn

Answer 3

थोड़ा सड़ांध को रोकें

नहीं, यह बिल्कुल भी नहीं है। Git द्वारा शुरू की गई कोई RAID जैसी अतिरेक नहीं है। यदि आपकी .gitनिर्देशिका की फ़ाइलें बिट-रोट से पीड़ित हैं, तो आप हमेशा की तरह सामान खो देंगे।

बिट-रोट के खिलाफ मदद?

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