लिनक्स के लिए बड़ी फ़ाइलों (बैकअप) के लिए रॉक-स्थिर फाइलसिस्टम


18

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

इसके अलावा, मुझे कौन से माउंट पैरामीटर का उपयोग करना चाहिए?

कर्नेल लिनक्स> = 2.6.34 है।

संपादित करें: मुझे बैकअप विधियाँ नहीं चाहिए। मुझे उन्हें संग्रहीत करने के लिए फाइल सिस्टम की आवश्यकता है।


आप प्रतिदिन, साप्ताहिक, मासिक कितना डेटा बैकअप कर रहे हैं? आप कितने डेटा को बनाए रखने की योजना बनाते हैं, और कितने समय के लिए?
स्टीफन लासिवस्की

क्या यह लिनक्स होना चाहिए? क्या आपने FreeBSD 8.1 पर ZFS (एक पुराना, स्थिर संस्करण 14) पर विचार किया है?
स्टीफन लासवर्स्की

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

जवाबों:


13

आप ext4 का उपयोग कर सकते हैं, लेकिन मैं journal_dataमोड के साथ बढ़ते की सिफारिश करूंगा जो कि डीललोक (विलंबित आवंटन) को बंद कर देगा, जो 'कुछ पहले की समस्याओं का कारण बना। डीललोक के निष्क्रिय होने से नया डेटा धीमा हो जाएगा, लेकिन बिजली की विफलता की स्थिति में लिखने से नुकसान होने की संभावना कम हो जाएगी। मुझे यह भी उल्लेख करना चाहिए कि आप डीललॉक को अक्षम कर सकते हैं, journal_dataजिसके उपयोग से कुछ अन्य लाभ हैं (या कम से कम एक्स 3 में ऐसा किया है), जैसे कि थोड़ा सुधार हुआ है, और मेरा मानना ​​है कि बेहतर वसूली।

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

ext4 भी fsckext3 से तेज है।

एक आखिरी नोट, 2.6.31 की तरह ext4 में बगफिक्स थे? मैं मूल रूप से यह सुनिश्चित करूंगा कि आप 2.6.32 कर्नेल से पहले नहीं चल रहे हैं जो कि LTS कर्नेल है।


यदि "रॉक-सॉलिड" का विकल्प चुना जाए तो ext4यह मर्तिस और इसके साथ जुड़े जोखिमों पर विचार करने के लिए सार्थक हो सकता है on disk layoutऔर इसलिए आराम पर डेटा सुरक्षा (यहां एक पहलू को खारिज कर दिया गया है )
मानवता

5

XFS ठोस है और सदियों से कर्नेल में है। Xfs_freeze जैसे टूल की जाँच करें और देखें कि क्या यह वही है जो आप ढूंढ रहे हैं। मुझे पता है कि यह अत्यधिक व्यक्तिपरक है लेकिन मैंने बिना किसी घटना के वर्षों तक डेटा भंडारण के लिए एक्सएफएस का उपयोग किया है।


2
मेरे जवाब के आधार पर मैं यह नोट करना चाहूंगा कि एक्सएफएस आधारित है और एक्सट 4 के समान ही कई फायदे हैं। हालाँकि, मैं यह उल्लेख करना चाहूंगा कि यह डील 4 के साथ उन्हीं मुद्दों को उठाता है जो ext4 हो सकते हैं, जिसके परिणामस्वरूप प्लग परिदृश्य में डेटा हानि हो सकती है। मुझे नहीं पता कि XFS में डीललॉक को निष्क्रिय किया जा सकता है या नहीं।
xenoterracide

हाँ, मुझे यकीन नहीं है कि आप इस सुविधा को अक्षम कर सकते हैं, लेकिन xfs_freeze उपयोगिता एक स्थिर डिस्क छवि सुनिश्चित करती है। मैन पेज से: -f ध्वज निर्दिष्ट एक्सएफएस फाइलसिस्टम को नए संशोधनों से फ्रीज करने का अनुरोध करता है। जब इसे चुना जाता है, तो फाइलसिस्टम में चल रहे सभी लेनदेन को पूरा करने की अनुमति दी जाती है, नई राइट सिस्टम कॉल को रोक दिया जाता है, अन्य कॉल जो फाइल सिस्टम को संशोधित करती हैं, रुकी हुई हैं, और सभी गंदे डेटा, मेटाडेटा और लॉग जानकारी डिस्क पर लिखी जाती हैं। जमी हुई फाइलसिस्टम को लिखने का प्रयास करने वाली कोई भी प्रक्रिया फाइलसिस्टम के अधूरे होने की प्रतीक्षा कर रही है।
dsp

जब तक फ्लश काम करता है तब तक मैं फाइलों के मध्य-लेखन भ्रष्टाचार से कम चिंतित हूं।
मैकीज पाइचोटका

3

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

बैकअप के लिए आप कुछ ठोस / बहुत स्थिर चाहते हैं। और btrfs या ZFS आज बस तैयार नहीं हैं।


मैं इसे
एक्सटी

0

btrfs में डिस्क पर लिखे गए डेटा के पारदर्शी चेकसमिंग और एक तेज़ ऑर्डर-राइट्स मोड है जो हमेशा (और कई अन्य बैकअप-अनुकूल सुविधाओं) पर होता है जो इसे बैकअप के लिए अपील करता है। अधिक विवरण के लिए https://btrfs.wiki.kernel.org/index.php/Main_Page देखें ।


हम्म। हालांकि यह भविष्य में एक अच्छा जवाब हो सकता है मुझे नहीं लगता कि अभी btrfs या zfs लिनक्स पर स्थिर हैं।
मिकीज पीचोटका

मैंने कर्नेल उपयोगकर्ताओं द्वारा मेरे लिए अनुशंसित btrfs लिया है। पिछले मुझे पता था कि मर्क्यूरियल मेंटेनर इसे कम से कम एक मशीन पर पूरे समय चला रहा था। मैं रोज़ FUSE के माध्यम से ZFS का उपयोग करता हूं और यह ठोस है, अगर FUSE के कारण थोड़ा धीमा है।
Durin42

1
डिस्क प्रारूप पर btrfs अभी तक स्थिर नहीं है ... मैं इसे बदलने की सिफारिश नहीं करूंगा। कर्नेल प्रोग्रामर सभी प्रकार की पागल चीजें चला सकते हैं।
xenoterracide

ZFS स्थिर हो सकता है ... लेकिन FUSE चीज के कारण मैं इससे परेशान नहीं होता।
xenoterracide

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

0

एक imho बहुत महत्वपूर्ण पहलू जो मैंने अन्य उत्तरों में चर्चा नहीं की है, वह फाइलसिस्टम के डिस्क लेआउट की स्थिरता की विशेषताएं हैं (उदाहरण के लिए, संभव कैंडिटेट्स ext4 , btrfs के प्रलेखन से परामर्श करने पर विचार करें )

जबकि कोडबेस फाइलसिस्टम ड्राइवरों के कोडबेस और परीक्षण की मात्रा वास्तव में महत्वपूर्ण है, क्योंकि अन्य जवाबों से पता चलता है, क्योंकि यह उसके पढ़ने और लिखने के दौरान डेटा की सुरक्षा है , डिस्क लेआउट / प्रारूप आपके डेटा के लिए जोखिमों के खिलाफ सुरक्षा है। बाकी जगहों पर, जो हार्डवेयर डेफ़ेक्ट्स जैसे कि अपठनीय सेक्टर, या साइलेंट बिट रॉट हैं

सम्मान के साथ ext4, जिसके बारे में कहा जाता है कि इसमें अच्छी विशेषताएँ होती हैं, लंबे समय तक टेस्ट किए गए कोडबेस ( https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0। पीडीएफ दिखाता है कि अधिक आधुनिक और अधिक जटिल में उदाहरण के लिए, इसमें कीड़े ढूंढने में अधिक समय लगा btrfs), मैंने बाकी हिस्सों में ext4 प्रतिरोध पर ध्यान दिया है और कुछ imho कमियों को पाया है, अन्य प्रशंसा की फाइल सिस्टम।

मैं यह समझदारी (यदि चुना पर विचार करेंगे ext4"के रूप में रॉक-ठोस बैकअप FS ") वसूल न (यद्यपि "यह सख्त") में सुधार करने के का उपयोग करके e2imageउपकरण के डेवलपर्स ext4प्रदान

E2image प्रोग्राम डिवाइस पर स्थित महत्वपूर्ण ext2, ext3, या ext4 फाइल सिस्टम मेटाडेटा को इमेज-फाइल द्वारा निर्दिष्ट फ़ाइल में बचाएगा। उन प्रोग्रामों के लिए -i विकल्प का उपयोग करके डंप फ़ाइल की जांच डम्प 2 एफए और डीबगफ्स द्वारा की जा सकती है। यह भयावह रूप से दूषित फाइल सिस्टम को ठीक करने में एक विशेषज्ञ की सहायता कर सकता है। भविष्य में, e2fsck को एक बुरी तरह से क्षतिग्रस्त फाइल सिस्टम को पुनर्प्राप्त करने में मदद करने के लिए छवि फ़ाइल का उपयोग करने में सक्षम होने के लिए बढ़ाया जाएगा।

और सलाह देते हैं

एक सिस्टम पर सभी फाइलसिस्टम के लिए इमेज फाइल बनाना और पार्टीशन लेआउट (जिसे fdisk -l कमांड का उपयोग करके उत्पन्न किया जा सकता है) को नियमित अंतराल पर --- बूट समय पर, और / या हर हफ्ते में सेव करना एक बहुत अच्छा विचार है। इसलिए। इमेज फाइल को फाइलसिस्टम के अलावा कुछ फाइलसिस्टम पर संग्रहित किया जाना चाहिए, जिसका डेटा इसमें है, यह सुनिश्चित करने के लिए कि यह डेटा उस स्थिति में पहुंच योग्य है जहां फाइल सिस्टम बुरी तरह से क्षतिग्रस्त हो गया है।

यह देखते हुए कि ext4 डिस्क लेआउट पर सभी मेटा-डेटा भी अतिरेक के साथ प्रदान नहीं किए जाते हैं (यानी कॉपी के रूप में सुपरकॉल को कई बार संग्रहीत किया जाता है, इंडो केवल 1 स्थान पर संग्रहीत किए जाते हैं), ext4निश्चित रूप से यह अनुमान है btrfsकि इसके साथ कम से कम चेकसम प्रदान करेगा सभी मेटाडेटा + फ़ाइल सामग्री डेटा

इस "shortcome" की प्रतिक्रिया करने के लिए ext4है और यह एक और अधिक बनाने rock-solidके पहलू में बात पर डिस्क लेआउट यह माध्यम से इस अतिरेक और फ़ाइल की सामग्री के लिए वसूली के पूरक के लिए उचित हो सकता है par2/ parchive

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

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