लिनक्स पर 10 मिलियन फ़ाइलों को संग्रहीत करना और उनका बैकअप लेना

Question

मैं एक वेबसाइट चलाता हूं जहां लगभग 10 मिलियन फाइलें (बुक कवर) उप-श्रेणियों के 3 स्तरों में संग्रहीत की जाती हैं, जिनमें [0-f] शामिल हैं:

0/0/0/
0/0/1/
...
f/f/f/

यह प्रति निर्देशिका लगभग 2400 फ़ाइलों की ओर जाता है, जो कि बहुत तेज़ है जब हमें एक फ़ाइल को पुनः प्राप्त करने की आवश्यकता होती है। यह कई प्रश्नों द्वारा सुझाया गया अभ्यास है ।

हालाँकि, जब मुझे इन फ़ाइलों का बैकअप लेने की आवश्यकता होती है, तो 10m फ़ाइलों को रखने वाली 4k निर्देशिकाओं को ब्राउज़ करने में कई दिन लगते हैं।

तो मैं सोच रहा था कि क्या मैं इन फ़ाइलों को एक कंटेनर (या 4k कंटेनर) में संग्रहीत कर सकता हूं, जो प्रत्येक एक फाइलसिस्टम (कुछ प्रकार के माउंटेड एक्स 3/4 कंटेनर?) की तरह बिल्कुल कार्य करेगा। मुझे लगता है कि यह लगभग फ़ाइल सिस्टम में सीधे फ़ाइल तक पहुँचने के रूप में कुशल होगा, और यह बहुत कुशलता से किसी अन्य सर्वर पर कॉपी किए जाने का महान लाभ होगा।

यह कैसे करना है पर कोई सुझाव? या कोई व्यवहार्य विकल्प (noSQL, ...)?

Comments

अभी आप किस फाइल सिस्टम का उपयोग कर रहे हैं?

— सेमीकिन्टी

अगर आप कीमतों को कम कर सकते हैं, तो नेटएप एक विकल्प होना चाहिए

— इयान

मैं CentOS 5.6 के तहत ext4 का उपयोग कर रहा हूं

— बेंजामिन

जिज्ञासु क्यों इसे "10 दिनों की फाइलों को पकड़े 4k निर्देशिकाओं को ब्राउज़ करने के लिए कई दिनों का समय लेना चाहिए", जो बहुत धीमी गति से लगता है। प्रति पथनाम 150 बाइट्स मानकर, 10m फ़ाइल नाम 1.5 GB डेटा बनाता है, इसलिए यह उपलब्ध मेमोरी / CPU (परिणाम को सॉर्ट करने सहित) हो सकता है। इसके अलावा, अगर सक्रिय करने के चेक / dir_index अक्षम करने में मदद करता है: lonesysadmin.net/2007/08/17/... प्लस पर विभिन्न सुझावों serverfault.com/questions/183821/...

— RichVel

नोट 5 साल बाद: मैंने अमेज़ॅन एस 3 को सब कुछ माइग्रेट किया है, जो कि इतनी बड़ी मात्रा में फ़ाइलों को संग्रहीत करने के लिए पूरी तरह से अनुकूल है। इसके अलावा, मुझे अब उप-निर्देशिकाओं के 3 स्तरों में फ़ाइलों को विभाजित करने की आवश्यकता नहीं है, क्योंकि एस 3 के लिए यह कोई अंतर नहीं करता है (एक पथ एक पथ है, चाहे इसमें स्लैश हो या कोई फर्क नहीं पड़ता है)। और मैं बेहतर सो सकता हूं, यह जानकर कि मेरा डेटा कई स्थानों पर सुरक्षित रूप से दोहराया गया है।

— बेंजामिन

Answer 1

लाखों फ़ाइलों को जल्दी से एक्सेस करने और बैकअप के लिए विकल्प

समान समस्याओं वाले लोगों से उधार लें

यह एक आसान प्रकार की समस्या की तरह लगता है जो USENET समाचार सर्वर और कैशिंग वेब प्रॉक्सी का सामना करता है: लाखों लाखों छोटी फाइलें जो बेतरतीब ढंग से एक्सेस की जाती हैं। आप उनसे एक संकेत लेना चाह सकते हैं (सिवाय इसके कि उन्हें आमतौर पर बैकअप लेने की जरूरत नहीं है)।

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

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

समर्पित फाइल सिस्टम

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

एलवीएम

मैंने विभाजन के गतिशील आकार को अनुमति देने के लिए उपयोगी होने के रूप में उपरोक्त LVM का उल्लेख किया है ताकि आपको बहुत सारे खाली स्थान का बैकअप लेने की आवश्यकता न हो। लेकिन, निश्चित रूप से, LVM में अन्य विशेषताएं हैं जो बहुत अधिक लागू हो सकती हैं। विशेष रूप से "स्नैपशॉट" कार्यक्षमता जो आपको एक फाइल सिस्टम को एक पल में फ्रीज करने की सुविधा देती है। कोई भी आकस्मिक rm -rfया जो कुछ भी स्नैपशॉट को परेशान नहीं करेगा। आप जो करने की कोशिश कर रहे हैं, उसके आधार पर, यह आपके बैकअप की जरूरत के लिए पर्याप्त हो सकता है।

RAID-1

मुझे यकीन है कि आप पहले से ही RAID से परिचित हैं और शायद पहले से ही इसे विश्वसनीयता के लिए उपयोग करते हैं, लेकिन RAID -1 का उपयोग बैकअप के लिए भी किया जा सकता है, कम से कम यदि आप सॉफ़्टवेयर RAID का उपयोग कर रहे हैं (आप इसे हार्डवेयर RAID के साथ उपयोग कर सकते हैं, लेकिन वास्तव में आपको कम विश्वसनीयता देता है क्योंकि इसे पढ़ने के लिए समान मॉडल / संशोधन नियंत्रक की आवश्यकता हो सकती है)। अवधारणा यह है कि आप एक RAID-1 समूह बनाते हैं जिसमें एक और डिस्क होती है जिसकी आपको वास्तव में आपकी सामान्य विश्वसनीयता की जरूरतों से जुड़ी होती है (उदाहरण के लिए एक तीसरी डिस्क यदि आप दो डिस्क के साथ सॉफ़्टवेयर RAID -1 का उपयोग करते हैं, या शायद एक बड़ी डिस्क और एक हार्डवेयर- RAID5 एक सॉफ्टवेयर के साथ छोटे डिस्क के साथ RAID -1 हार्डवेयर के ऊपर RAID -5)। जब बैकअप लेने का समय आता है, तो एक डिस्क स्थापित करें, mdadm को उस डिस्क को RAID समूह में जोड़ने के लिए कहें, जब तक यह पूर्णता को इंगित नहीं करता है, तब तक प्रतीक्षा करें, वैकल्पिक रूप से सत्यापन स्क्रब के लिए पूछें, और फिर डिस्क को हटा दें। बेशक,

Comments

बहुत पूर्ण उत्तर, जो अच्छे समाधानों का सारांश प्रस्तुत करता है। मुझे लगता है कि मैं अपनी मौजूदा फाइल सिस्टम संरचना रखूँगा, और LVM स्नैपशॉट का उपयोग करूँगा, जो मेरे उपयोग के मामले के लिए एकदम सही है।

— बेंजामिन

Answer 2

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

एक अन्य विकल्प dd का उपयोग करके संपूर्ण डिवाइस का बैकअप लेना है। उदाहरण के लिए, dd if=/dev/my_device of=/path/to/backup.dd।

Comments

+1 डिवाइस का बैकअप लेना एक अच्छा विचार है।

— एएसएम

यदि आप इस दृष्टिकोण का उपयोग करते हैं, तो पुनर्स्थापना का परीक्षण करें (ठीक है, आपको हमेशा ऐसा करना चाहिए), क्योंकि यदि आपका इनपुट डिस्क / dev / sdd की तरह है, तो dd विभाजन sheme और आकारों को संग्रहीत करेगा। यदि आप इसे एक छोटी डिस्क पर पुनर्स्थापित करते हैं, तो आपको त्रुटियाँ मिलेंगी, और यदि आप इसे एक बड़ी डिस्क पर पुनर्स्थापित करते हैं, तो यह छोटा दिखाई देगा। यह सबसे अच्छा काम करेगा, यदि आप डेटा को उसी डिस्क प्रकार के किसी अन्य उदाहरण के लिए पुनर्स्थापित करते हैं। केवल विभाजन (/ dev / sdd1) कम परेशानी वाला होगा।

— उपयोगकर्ता अज्ञात

ध्यान दें कि यदि डिवाइस LVM पर है, तो LVM स्नैपशॉट का उपयोग करके डिस्क को अनमाउंट किए बिना भी एक बैकअप किया जा सकता है।

— bdonlan

मैं LVM स्नैपशॉट बैकअप अप्रोच दूसरा। मैंने लाइव डीआर प्रतिकृति के लिए अतीत में एलवीएम लिया। स्नैपशॉट के साथ संयोजन में dd का उपयोग करना त्वरित ब्लॉक-स्तरीय बैकअप करना आसान बनाता है।

— स्लैशडॉट

मैंने कोशिश की ddअधिक ncहै और इस एक अच्छा काम करता है! हालाँकि मेरे पास असंगत / दूषित डेटा हो सकता है, क्योंकि लाइव विभाजन के बजाय LVM स्नैपशॉट का उपयोग करने का विरोध किया गया है।

— बेंजामिन

Answer 3

जैसा कि आप शायद जानते हैं, आपकी समस्या स्थानीयता है। एक विशिष्ट डिस्क की तलाश में 10ms या तो लगता है। तो बस 10 मिलियन बेतरतीब ढंग से रखी गई फाइलों पर "स्टेट" (या ओपन ()) कॉल करने के लिए 10 मिलियन या लगभग 100000 सेकंड या 30 घंटे की आवश्यकता होती है।

इसलिए आपको अपनी फ़ाइलों को बड़े कंटेनरों में रखना होगा, जैसे कि संबंधित नंबर आपकी ड्राइव बैंडविड्थ (50-100 एमबी / एक डिस्क के लिए सेकंड, आमतौर पर) आपके समय की मांग के बजाय है। इसके अलावा, आप उस पर एक RAID फेंक सकते हैं, जो आपको बैंडविड्थ को क्रैंक करने की सुविधा देता है (लेकिन समय कम न करें)।

मैं शायद आपको कुछ भी नहीं बता रहा हूं जो आप पहले से ही नहीं जानते हैं, लेकिन मेरा कहना यह है कि आपके "कंटेनर" विचार निश्चित रूप से समस्या को हल करेंगे, और बस किसी भी कंटेनर के बारे में करेंगे। लूपबैक माउंट्स के साथ-साथ कुछ भी काम करने की संभावना होगी।

Comments

हाँ, स्थानीयता महत्वपूर्ण है। अपने उपयोग पैटर्न को देखें। अधिकांश समस्याएं पेरेटो सिद्धांत (80% डेटा को हिट करने वाली 80% प्रक्रियाएं) का पालन करती हैं, इसलिए यदि आप यह पता लगा सकते हैं कि किन फ़ाइलों को रैम में कैश करने की आवश्यकता है, या बस एक अलग विभाजन पर निर्देशिकाओं के एक अलग लेआउट के साथ रखा जाए, इसलिए यह कम निर्देशिकाओं को ढूंढता है या ढूंढता है, यह शायद बहुत मदद करेगा। डिस्क्स के विभिन्न स्पिंडल पर अक्सर एक्सेस की गई फ़ाइलों को फैलाना ताकि समानांतर में किया जा सके, मदद भी कर सके। संदर्भ के इलाके को लाने के लिए @ नीमो के लिए +1।

— मार्सिन

Answer 4

विकल्प के एक जोड़े हैं। सबसे सरल, और सभी लिनक्स फाइल सिस्टम के साथ काम करना चाहिए, ddपूरे विभाजन ( /dev/sdb3या /dev/mapper/Data-ImageVol) को एक छवि पर कॉपी करना और उस छवि को संग्रह करना है। एकवचन फ़ाइलों को पुनर्स्थापित करने के मामले में, लूपबैक छवि को माउंट करता है ( mount -o loop /usr/path/to/file /mountpoint) और आपकी ज़रूरत की फ़ाइलों की प्रतिलिपि बनाएँ। एक पूर्ण विभाजन पुनर्स्थापना के लिए, आप प्रारंभिक ddकमांड की दिशा को उल्टा कर सकते हैं , लेकिन आपको वास्तव में समान आकार के विभाजन की आवश्यकता है।

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

वैकल्पिक रूप से, Google वीडियो @ के रूप में @ के माध्यम से आधे रास्ते के बारे में उल्लेख करने के लिए कहा, XFS एक महान फाइल सिस्टम (यदि जटिल है)। एक्सएफएस के साथ अच्छे उपयोगिताओं में से एक xfsdumpउपयोगिता है, जो एक संपूर्ण फाइल सिस्टम को एक फ़ाइल में डंप कर देगा, और आम तौर पर ऐसा करने के लिए तेजी से tarकर सकता है। यह एक फाइलसिस्टम-विशिष्ट उपयोगिता है, इसलिए ऐसे तरीके से एफएस इंटर्न का लाभ उठा सकते हैं जो टार नहीं कर सकते।

Comments

वहाँ बहुत अच्छे जवाब! XFS दिलचस्प लगता है, लेकिन मुझे डर है कि यह मेरी पहुंच से थोड़ा बाहर है।

— बेंजामिन

Answer 5

मेरा सुझाव है कि आप पहले EXT4 में अपग्रेड करने की कोशिश करें, अगर आप इसे पहले से नहीं चला रहे हैं।

Google ने इस बात पर बहुत शोध किया है कि EXT4 एक अच्छा विचार क्यों है ।

उसके बाद आपको वितरित फ़ाइल सिस्टम आर्किटेक्चर को तैनात करना चाहिए। उदाहरण के लिए:

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

Comments

मैं वास्तव में पहले से ही EXT4 चला रहा हूं, जो बहुत अच्छा लग रहा है!

— बेंजामिन

Answer 6

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

एक समस्या यह हो सकती है कि अगर यह हर समय डिस्क से मांग रहा है, तो मोंगो बहुत तेजी से धीमा हो जाता है। 10 मिलियन फ़ाइलों के साथ, मुझे उम्मीद है कि आपका अधिकांश डेटा डिस्क पर होगा। GridFS में फाइलों का हिस्सा 4MB है, जैसा कि मुझे याद है, इसलिए यदि आप फाइलें बड़ी हैं तो आप एक फाइल प्राप्त करने के लिए कई महंगे ऑपरेशन कर रहे होंगे। मुझे लगता है कि कुंजी, आपकी फ़ाइलों को पहले से ही सुव्यवस्थित निर्देशिका संरचना के आधार पर शार्प करने के लिए होगी ताकि आप लोड को हल्का करने के लिए कई बक्से पर मोंगू के कई उदाहरण चला सकें। हालाँकि, मुझे नहीं पता कि आपके प्रदर्शन की आवश्यकताएं क्या हैं या तो मैं इसे अधिक सोच सकता हूं।

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

Comments

निश्चित रूप से GridFS पर एक नज़र होगी, जो मुझे नहीं पता था, लेकिन मुझे लगता है कि मैं सब कुछ पहले से ही काम कर रहा है, काम की मात्रा को कम करने के लिए सब कुछ फाइलसिस्टम-आधारित रखने के लिए खत्म कर दूंगा!

— बेंजामिन

Answer 7

यदि आप अपने डेटा स्टोरेज के लिए एक उपकरण मॉडल से खुश हैं, तो शायद आप NexentaStor पर विचार कर सकते हैं । यह हुड के तहत ओपनसोलारिस पर जेडएफएस चलाता है लेकिन सभी प्रशासन एक वेब जीयूआई के माध्यम से है।

कुछ विशेषताएं हैं जो आपके मुद्दे के साथ मदद करेंगी।

• एंटरप्राइज़ संस्करण स्नैपशॉट के आधार पर दूरस्थ प्रतिकृति के एक रूप का समर्थन करता है जिसे संपूर्ण फाइल सिस्टम के माध्यम से स्कैनिंग की आवश्यकता नहीं होती है।

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

Comments

धन्यवाद, इस पर एक नज़र होगा। हो सकता है कि यह मेरी परियोजना में थोड़ी जटिलता जोड़ देगा!

— बेंजामिन

Answer 8

आप dumpबहुत सी फाइलों के साथ EXT4 फाइल सिस्टम के बैकअप के लिए एक मानक उपयोगिता का उपयोग कर सकते हैं । यह उपयोगिता पहले जाँचती है कि कौन से ब्लॉक फाइलसिस्टम पर उपयोग किए जाते हैं और फिर डिस्क ऑर्डर में उन्हें बैक अप देते हैं, जो सबसे अधिक डिस्क को हटाते हैं।

restoreद्वारा बनाए गए बैकअप को पुनर्स्थापित करने के लिए एक संबंधित उपयोगिता है dump।

यह स्तर का उपयोग करके वृद्धिशील बैकअप का समर्थन करता है - स्तर 1 बैकअप फ़ाइलें पिछले स्तर 0 (पूर्ण) बैकअप, स्तर 2 से संशोधित - स्तर 1 बैकअप और इसी तरह से संशोधित।

Answer 9

वृद्धिशील बैकअप के लिए, एक विकल्प के लिए नए कवर के लिए एक दूसरा, छाया पेड़ होगा। यही है, आपके पास अपना मुख्य पेड़ होगा जो सभी रीड ऑपरेशन के लिए उपयोग किया जाता है। आपके पास एक newfiles/012345.....jpgनिर्देशिका भी होगी ; नए जोड़े गए कवर एक हार्डलिंक के साथ-साथ मुख्य पेड़ में भी बनाते हैं। बैकअप निष्पादित करते समय, आप कभी-कभी मुख्य पेड़ का बैकअप ले सकते हैं, लेकिन newfilesबहुत अधिक नियमित रूप से बैकअप (बहुत छोटा) पेड़।

ध्यान दें कि newfilesमुख्य वृक्ष का नया बैकअप करने से पहले पेड़ को छोटा रखने के लिए , आप नए पेड़ को खाली कर सकते हैं:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

एक बार जब आप ऐसा कर लेते हैं, तो निश्चित रूप से, आप मुख्य पेड़ का एक नया बैकअप बनाने के लिए प्रतिबद्ध हैं।

Comments

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

— बेंजामिन

Answer 10

संक्षिप्त रूप से थोड़ा सा जोड़ने से आमतौर पर मदद मिलती है।

मुझे आपसे भी ऐसी ही समस्या है; मेरे मामले में मुझे लगभग 30 मिलियन फाइलों का बैकअप लेना है, उनमें से ज्यादातर HTML, PHP या JPEG फाइलें हैं। मेरे लिए BackupPC + ss पर rsync ठीक काम करता है; पूर्ण बैकअप लगभग एक दिन लेता है, लेकिन वेतन वृद्धि आमतौर पर कुछ घंटों में समाप्त हो जाएगी।

ट्रैपपीसी में कॉपी करने के लिए एक नए लक्ष्य के रूप में प्रत्येक मुख्य स्तर निर्देशिका (0, 1, 2 ... a, b, c ...) को जोड़ने की चाल है और इसे समानांतर में बैकअप का प्रदर्शन करने दिया जाता है, इसलिए यह एक साथ निर्देशिकाओं का बैकअप लेता है। ए / , बी / , सी / * और इतने पर। आपके डिस्क सबसिस्टम के आधार पर कुछ प्रक्रियाओं से लेकर 10 प्रक्रियाओं तक के बीच कुछ भी संभवत: सबसे तेज़ तरीका है।

LVM स्नैपशॉट और ब्लॉक-स्तर बैकअप भी एक विकल्प है, लेकिन BackuPC और फ़ाइल-स्तर बैकअप के साथ आप अभी भी व्यक्तिगत फ़ाइलों या निर्देशिकाओं को पुनर्स्थापित कर सकते हैं यदि आवश्यक हो।

Comments

मुझे आश्चर्य है कि रूट निर्देशिकाओं का समर्थन करने से आपके लिए समस्या का समाधान हो जाता है, मैं उम्मीद करूंगा कि वास्तव में धीमी गति से हो। क्या सभी निर्देशिका एक ही डिस्क पर हैं? क्या आप SSD का उपयोग कर रहे हैं?

— बेंजामिन

डेटा फ़ाइलों को सैन पर संग्रहीत किया जाता है।

— जने पिक्कारनेन

ठीक है, अब समझ में आता है, आप कई फ़ाइलों को एक साथ एक्सेस करने से दक्षता प्राप्त करते हैं, क्योंकि आपके विभिन्न फ़ोल्डर्स सबसे अधिक शारीरिक रूप से सैन में अलग-अलग ड्राइव पर स्थित हैं, या कम से कम कई ड्राइवों पर दोहराया गया है, जो समवर्ती पहुंच की अनुमति देता है। मैं केवल एक RAID -1 पर आधारित हूं, इसलिए मुझे लगता है कि दो समवर्ती अभिगमों से ऊपर, मेरी गति नीचे जाने की संभावना है।

— बेंजामिन

Answer 11

बेंजामिन,

मुझे लगता है कि आपकी समस्या को निर्देशिका स्तर प्रति फ़ाइलों की संख्या पर संबोधित किया जा सकता है!

यदि आप एक निर्देशिका में 20 000 फ़ाइलों को संग्रहीत करते हैं, तो क्या एक महत्वपूर्ण कारक द्वारा पहुंच का समय बदल जाता है?

हालाँकि आपने एक अलग तेज एक्सेस ड्राइव पर फाइल सिस्टम मेटाडेटा को संचयित किया है? (एक SSD की तरह)।

Answer 12

मैं इसके बजाय एक अच्छे पुराने संबंधपरक डेटाबेस की सिफारिश करूंगा।

मैं PostgreSQL का उपयोग करता हूँ, कहते हैं, 256 पार्टीशन टेबल (cover_00, cover_01, ..., cover_ff) के साथ छवि डेटा के रूप में bytea(बाइनरी) कॉलम बाहरी भंडारण के साथ, प्राथमिक कुंजी के रूप में फ़ाइल पहचानकर्ता के साथ। एक छवि प्राप्त करना तेज़ होगा (प्राथमिक कुंजी पर एक सूचकांक के लिए धन्यवाद), डेटा अखंडता की गारंटी होगी (एसीआईडी ​​आज्ञाकारी डेटाबेस), बैकअप डिस्क क्रम में होगा, इसलिए बहुत अधिक मांग नहीं है।