🛌🏽 🤮 👨‍🚒 हम बैकअप साइटों के लिए एक नया फ़ाइल स्वरूप विकसित कर रहे हैं 🔐 🤘🏻 👿

अब मैं एक नई PHP स्क्रिप्ट पर काम कर रहा हूं जो न केवल डेटाबेस, बल्कि सभी साइट फ़ाइलों का बैकअप लेगा।

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

"साइकिल सवारों" का अनुरोध "हमारे लिए पर्याप्त बाइक" की शैली में टिप्पणियों से बचना है। अंत में, "साइकिल" के निर्माण के बिना न तो Google होता, न ही Google Chrome, न ही फेसबुक, न ही WinRAR और 7-ज़िप।

टार क्यों नहीं?

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

सूचकांक का अभाव

TAR में संग्रह सामग्री के साथ कोई निर्देशिका नहीं है। इसलिए, संग्रह की सामग्री को देखने के लिए, आपको सभी फ़ाइल हेडर के माध्यम से संग्रह को स्कैन करने की आवश्यकता है। जिसे बड़े अभिलेखागार में काफी समय लग सकता है।

कंटेनर के अंदर ऑफसेट (fseek) का उपयोग नहीं कर सकते

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

संग्रह को स्ट्रीम नहीं लिख सकते

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

कोई फ़ाइल अखंडता नियंत्रण नहीं

फ़ाइलों के लिए चेकसम संग्रहीत नहीं हैं।

क्यों नहीं जिप?

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

निरंतर (ठोस) अभिलेखागार के लिए कोई समर्थन नहीं

जब बहुत सारी छोटी-छोटी फाइलें होती हैं, तो कंप्रेसिबिलिटी बहुत खराब होती है।

समय को MS-DOS प्रारूप में संग्रहीत किया जाता है

इसका मतलब है कि दिनांक 2 सेकंड की सटीकता के साथ संग्रहीत हैं, PHP के मामले में, यह यूनिक्स टाइमस्टैम्प से एमएस-डॉस प्रारूप और इसके विपरीत में एक अतिरिक्त रूपांतरण है।

संग्रह में फ़ाइल नामों का कोई एन्क्रिप्शन नहीं है

केवल फ़ाइलों की सामग्री, हेडर और केंद्रीय निर्देशिका को स्पष्ट पाठ में एन्क्रिप्ट किया गया है।

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

सामान्य तौर पर, मैंने अन्य विकल्पों पर विचार करने का निर्णय लिया। गुग्लिंग के बाद, मैं RAR, 7Z, DAR, ACE के प्रारूप पर प्रलेखन खोजने में कामयाब रहा, थोड़ा बंद सीबीयू और टीआईबी भी चुना। इस प्रक्रिया में, अपनी खुद की बाइक बनाने के बारे में विचार करें।

बैकअप साइटों के लिए नया फ़ाइल स्वरूप

तो, नया प्रारूप (दो बार बिना सोचे, इसे Sypex बैकअप से SXB कहा गया) विभिन्न स्वरूपों में झाँकने वाले विचारों का संकलन है, साथ ही इसके अपने कई।

SXB प्रारूप के विकास के दौरान मुख्य कार्य जो निर्धारित किए गए थे:

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

इसके अलावा, विकास 2 जीबी से बड़ी फ़ाइलों के साथ काम करने के लिए PHP की बारीकियों को ध्यान में रखता है।
मैं कुछ बिंदुओं का अधिक विस्तार से वर्णन करूंगा।

ब्लॉक डेटा डिडुप्लीकेशन

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

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

संग्रह में धाराएँ सहेजना

यह सुविधा आवश्यक है ताकि अस्थायी फ़ाइलों को बनाए बिना MySQL बैकअप को संग्रह में तुरंत सहेजा जा सके। जो, काम को गति देने के अलावा, खाली स्थान के लिए आवश्यकताओं को कम करता है, और व्यक्तिगत तालिकाओं के स्तर पर भी कटौती की अनुमति देता है, न कि संपूर्ण एसक्यूएल फ़ाइल की।

अतिरिक्त डेटा प्रकार

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

फ़ाइलों और निर्देशिकाओं के अलावा, SXB प्रारूप में डेटाबेस बैकअप (तालिका संरचना, तालिका सामग्री, ट्रिगर, फ़ंक्शन, आदि) के लिए विशेष डेटा प्रकार जोड़े गए हैं। MySQL ऑब्जेक्ट्स की संरचना संबंधित रचना प्रश्नों के रूप में संग्रहीत की जाएगी, और टेबल की सामग्री एक विभाजक के रूप में टैब के साथ पाठ के रूप में होगी (यह प्रारूप अधिक कॉम्पैक्ट है और आपको डेटा को बहुत तेज़ी से डंप / पुनर्स्थापित करने की अनुमति देता है)।

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

और अब लेख के बारे में क्या था

मैं वास्तविक साइटों पर समर्पण की जाँच करना चाहता था। जो बड़े स्थल हाथ में थे, उनमें से एक अपने स्वयं के इंजन (206 एमबी) पर, दूसरा vbulletin (934 एमबी) पर, समर्पण ने बहुत उत्साहजनक परिणाम दिखाए।

WinRAR को एक सतत संग्रह मोड (एक तेज़ और अधिक कॉम्पैक्ट फ़ाइल) में लॉन्च किया गया था। 7-ज़िप के लिए, पुराने LZMA एल्गोरिथ्म का परीक्षण किया गया था, और नया LZMA2 जो सभी 4 प्रोसेसर कोर को लोड करता है। विन 7 x64 के तहत PHP 5.4.10 का उपयोग किया।

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

जो लोग विकास में मदद करना चाहते हैं, और जो सिर्फ आपकी साइट पर कितने डुप्लिकेट हैं, में रुचि रखते हैं, कृपया एक विशेष सरल PHP स्क्रिप्ट का परीक्षण करें।

मैं कटौती, आकार और अधिमानतः अन्य अभिलेखागार (आकार और समय, मोड, सबसे तेजी से पर्याप्त) के साथ तुलना किए गए डेटा की संख्या में दिलचस्पी रखता हूं। परिणामस्वरूप, यह जानकारी यहां जारी की गई है:

dirs         162
files        6811
full_size    206.133
dup_size     28.721
archive_size 152.277
duplicates   3119
bigfiles     477
bf_blocks    5220
bf_dup       316
bf_size      154.426
bf_dup_size  8.027
time         13.53622

, ,
ZIP File Format Specification
TAR File Format Specification
RAR File Format Specification
7Z File Format Specification
DAR File Format Specification
ACE File Format Specification

हम बैकअप साइटों के लिए एक नया फ़ाइल स्वरूप विकसित कर रहे हैं