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

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

लेकिन वीबीआर वी10 में, अवधारणा को नए कार्यों के साथ पूरक किया गया था - कॉपी मोड, सीलबंद मोड और उच्चारण करने में मुश्किल नाम इम्युटेबिलिटी वाली एक चीज़ दिखाई दी।

ये वो दिलचस्प चीज़ें हैं जिनके बारे में हम आज बात करेंगे। सबसे पहले, यह VBR9.5u4 में कैसे काम करता है, और फिर दसवें संस्करण में हुए परिवर्तनों के बारे में।

और शुद्ध भाषा के समर्थक मुझे क्षमा करें, लेकिन ऐसे बहुत से शब्द हैं जिनका अनुवाद नहीं किया जा सकता।
तो यहाँ ढेर सारा आंग्लवाद होगा।
और बहुत सारे gifs.
और तस्वीरें.

• बिना ज़रा भी पछतावे के. लेख के लेखक.

जैसे थे

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

जैसा कि हम चित्र में देखते हैं, हमारे पास डेटा ब्लॉक के साथ एक प्रकार की बैकअप श्रृंखला है, जो रिपॉजिटरी के प्रदर्शन स्तर एसओबीआर पर स्थित है जिससे क्षमता स्तर जुड़ा हुआ है। हमारी परिचालन बैकअप विंडो तीन दिन की है।

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

लेकिन वास्तव में सीलबंद श्रृंखला का क्या मतलब था और अपडेट 4 में क्षमता शूटिंग रेंज में क्या भेजा जा सकता था?

फॉरवर्ड इंक्रीमेंटल के लिए, चेन को सील करने का एक संकेत एक नए पूर्ण बैकअप का निर्माण है। और इससे कोई फर्क नहीं पड़ता कि यह पूर्ण बैकअप कैसे प्राप्त किया जाता है: सिंथेटिक पूर्ण और सक्रिय पूर्ण बैकअप दोनों पर विचार किया जाता है।

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

रोलबैक के साथ फॉरवर्ड इंक्रीमेंट के मामले में, ये सभी रोलबैक और .vbk हैं, यदि प्रदर्शन सीमा पर कोई अन्य .vbk है

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

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

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

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

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

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

जैसा बन गया

परिचयात्मक भाग के लिए बस इतना ही। यह काफी विस्तृत है, लेकिन जैसा कि ऊपर बताया गया है, इन विवरणों के बिना यह बताना संभव नहीं होगा कि नए फ़ंक्शन कैसे काम करते हैं। इसलिए, बिना किसी देरी के, आइए पहले पर चलते हैं।

कॉपी मोड

यह काफी हद तक मौजूदा प्रौद्योगिकियों पर आधारित है, लेकिन उपयोग का एक बिल्कुल अलग तर्क रखता है। 

इस मोड का उद्देश्य यह सुनिश्चित करना है कि स्थानीय सीमा पर स्थित सभी डेटा की क्षमता डैश में एक प्रति हो।

यदि आप मूव और कॉपी मोड की आमने-सामने तुलना करते हैं, तो यह इस तरह दिखेगा:

• केवल सीलबंद चेन को ही स्थानांतरित किया जा सकता है। कॉपी मोड के मामले में, बैकअप कार्य में चाहे कुछ भी हो, बिल्कुल सब कुछ स्थानांतरित हो जाता है।
• जब फ़ाइलें परिचालन बैकअप विंडो की सीमाओं से परे जाती हैं तो स्थानांतरण चालू हो जाता है, और जैसे ही बैकअप फ़ाइल दिखाई देती है, प्रतिलिपि बनाना चालू हो जाता है।
• कॉपी करने के लिए नए डेटा की निगरानी लगातार होती रहती है, और इसे स्थानांतरित करने के लिए इसे हर 4 घंटे में एक बार चालू किया जाता है।

नई विधा पर विचार करते समय, मैं सरल उदाहरणों से जटिल उदाहरणों की ओर बढ़ने का प्रस्ताव करता हूँ।

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

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

प्रश्न उठता है - यदि आप यूआई को देखें तो एक ही समय में दोनों विकल्पों को चुनने का अवसर मिलता है। ऐसा संयुक्त मोड कैसे काम करेगा?

चलिए इसका पता लगाते हैं।

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

यह सभी आकर्षक तर्क इंटरफ़ेस में सिर्फ एक चेकबॉक्स के लिए ज़िम्मेदार है: जैसे ही वे बनाए जाते हैं, ऑब्जेक्ट स्टोरेज में बैकअप कॉपी करें।

हमें इस कॉपी मोड की आवश्यकता क्यों है?

प्रश्न को इस प्रकार दोबारा प्रस्तुत करना और भी बेहतर है: इसकी सहायता से हम किन जोखिमों से सुरक्षित रहते हैं? यह हमें किस समस्या को हल करने में मदद करता है?

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

तो आइए सबसे सरल से लेकर अधिक जटिल तक, संभावित परिदृश्यों पर नज़र डालें।

सबसे सरल दुर्भाग्य जो हमारे सिर पर आ सकता है वह है बैकअप श्रृंखला में फ़ाइलों में से एक की दुर्गमता।

एक दुखद कहानी यह है कि हमारे एसओबीआर भंडार का एक विस्तार टूट गया।

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

अब आइए प्रत्येक स्थिति को अलग से देखें।

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

अब स्थिति और भी जटिल है. आइए मान लें कि हमारे SOBR में प्रदर्शन मोड में चलने वाले दो विस्तार शामिल हैं, जिसका अर्थ है कि हमारे .vbk और .vib उनके ऊपर एक असमान परत में फैले हुए हैं। और किसी समय, एक सीमा अनुपलब्ध हो जाती है, और उपयोगकर्ता को तत्काल मशीन को पुनर्स्थापित करने की आवश्यकता होती है, जिसका डेटा का कुछ हिस्सा ठीक इसी सीमा पर होता है।

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

इस मामले का एक उपप्रकार यह है कि संपूर्ण एसओबीआर भंडार अप्राप्य हो गया। इस मामले में, हमारे पास स्थानीय भंडारण से कॉपी करने के लिए कुछ भी नहीं है, और सभी ब्लॉक क्लाउड से डाउनलोड किए जाते हैं।

और सबसे दिलचस्प स्थिति यह है कि बैकअप सर्वर मर गया। यहां दो विकल्प हैं: व्यवस्थापक महान है और उसने कॉन्फ़िगरेशन बैकअप बनाया है, और व्यवस्थापक स्वयं एक दुष्ट पिनोच्चियो है और उसने कॉन्फ़िगरेशन बैकअप नहीं बनाया है।

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

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

यह संभवतः कॉपी मोड के बारे में है और हम आगे बढ़ते हैं

सील मोड

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

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

तदनुसार, ऑपरेशन का सिद्धांत काफी सरल है: सभी लिखने के संचालन (नए डेटा की उपस्थिति), पढ़ने (पुनर्स्थापना) और हटाने (प्रतिधारण) को छोड़ना आवश्यक है।

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

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

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

रिवर्स इंक्रीमेंटल के साथ चीजें सरल हैं। इसमें सबसे पुराने बिंदु किसी भी चीज़ पर निर्भर नहीं होते हैं और उन्हें सुरक्षित रूप से हटाया जा सकता है। इसलिए, जैसे ही एक नई सीमा पर एक नया .vbk बनाया जाता है, पुराने .vrbs को एक-एक करके हटा दिया जाएगा।

वैसे, हम हर बार एक नया .vbk क्यों बनाते हैं: यदि हमने इसे नहीं बनाया, लेकिन वेतन वृद्धि की पुरानी श्रृंखला जारी रखी, तो पुराना .vbk किसी भी मोड में असीमित लंबे समय तक स्थिर रहेगा, जिससे इसके विलोपन को रोका जा सकेगा। इसलिए, यह निर्णय लिया गया कि जैसे ही सीमा सील हो जाती है, हम मुक्त सीमा पर एक पूर्ण बैकअप बनाते हैं।

क्षमता वाली शूटिंग रेंज के साथ चीजें अधिक जटिल हैं।

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

मूव मोड में लगभग यही बात होती है - हम रीटच की प्रतीक्षा करते हैं, स्थानीय स्टोरेज में पुराने को हटाते हैं, और ऑब्जेक्ट स्टोरेज में संग्रहीत को हटाते हैं।

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

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

इसमें मूलतः बस इतना ही है। तो चलिए सबसे कट्टर फीचर की ओर बढ़ते हैं -

अचल स्थिति

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

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

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

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

अब हमारी ब्लॉक जेनरेशन तकनीक को समझाने का बहुत अच्छा समय है। या ब्लॉक जेनरेशन. ऐसा करने के लिए, उस स्थिति पर विचार करें जिसके कारण इसकी उपस्थिति हुई।

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

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

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

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

और, हमेशा की तरह, कुछ उपयोगी लिंक:

• पर ब्लॉक जनरेशन हर विवरण में।
• के बारे में सारी जानकारी वीम बैकअप और प्रतिकृति 10 अपने सर्वोत्तम स्तर पर
• О क्षमता स्तर विवरण में

स्रोत: www.habr.com