क्षमता टियर (वा जसरी हामी यसलाई Vim - captir भित्र बोलाउँछौं) अभिलेख टियर नाम अन्तर्गत Veeam ब्याकअप र प्रतिकृति 9.5 अपडेट 4 को दिनहरूमा देखा पर्‍यो। यसको पछाडिको विचार भनेको तथाकथित परिचालन पुनर्स्थापना विन्डोबाट वस्तु भण्डारणमा खसेका ब्याकअपहरूलाई सार्न सम्भव बनाउनु हो। यसले थोरै भएका प्रयोगकर्ताहरूको लागि डिस्क ठाउँ खाली गर्न मद्दत गर्‍यो। र यो विकल्पलाई Move Mode भनिन्थ्यो।

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

तर VBR v10 मा, अवधारणालाई नयाँ प्रकार्यहरू - प्रतिलिपि मोड, सिल गरिएको मोड र अपरिवर्तनीयता नाम उच्चारण गर्न गाह्रो भएको कुराको साथ पूरक गरिएको थियो।

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

र शुद्ध भाषाका च्याम्पियनहरूले मलाई माफ गरून्, तर त्यहाँ धेरै सर्तहरू छन् जुन अनुवाद गर्न सकिँदैन।
त्यसैले यहाँ एक टन एङ्ग्लिकवाद हुनेछ।
र धेरै gifs।
र चित्रहरू।

• अलिकति पनि पश्चाताप बिना। लेखका लेखक।

जस्तै थियो

ठिक छ, अपरेशनल रिस्टोर विन्डो र सिल गरिएको ब्याकअपको विश्लेषण गरेर सुरु गरौं (वा तिनीहरूलाई निष्क्रिय ब्याकअप चेन कागजातमा भनिन्छ)। तिनीहरूको समझ बिना, थप व्याख्या सम्भव हुनेछैन।

हामीले तस्विरमा देख्यौं, हामीसँग डाटा ब्लकहरूको साथ एक प्रकारको ब्याकअप चेन छ, जुन क्षमता टियर जडान भएको भण्डारको प्रदर्शन स्तर SOBR मा अवस्थित छ। हाम्रो परिचालन ब्याकअप विन्डो तीन दिनको छ।

तदनुसार, सोमबार सिर्जना गरिएको .vbk ले अघिल्लो चेनलाई सील गर्दछ, जसको विन्डो तीन दिनमा सेट गरिएको छ। र यसको मतलब तपाईं सुरक्षित रूपमा यी तीन दिन भन्दा पुरानो सबै चीजहरू शूटिंग दायरामा ढुवानी गर्न सुरु गर्न सक्नुहुन्छ।

तर सील गरिएको चेनको अर्थ के हो र अपडेट 4 मा क्षमता शूटिंग दायरामा के पठाउन सकिन्छ?

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

रिभर्सको अवस्थामा, यी सबै फाइलहरू हुन् जुन अपरेटिङ विन्डोमा पर्दैनन्।

रोलब्याकको साथ फर्वार्ड वृद्धिको मामलामा, यी सबै रोलब्याकहरू र .vbk हुन्, यदि प्रदर्शन सीमामा अर्को .vbk छ भने।

अब ब्याकअप प्रतिलिपि चेनहरूसँग काम गर्ने विकल्पलाई विचार गरौं। GFS अवधारण अन्तर्गत पर्ने वस्तुहरू मात्र यहाँ ढुवानी गरियो। किनभने हालैको ब्याकअप प्रतिलिपि चेनहरूमा भण्डारण गरिएका सबै चीजहरू कुनै न कुनै रूपमा परिवर्तन गर्न सकिन्छ।

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

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

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

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

तर अनुक्रमणिकाको देवताको लागि थप अनुक्रमणिकाहरू! त्यहाँ डाटा रिकभरीको लागि सूचकांक पनि छ! जब हामीले क्षमता ड्यासमा अवस्थित मेसिनलाई पुनर्स्थापना गर्न थाल्छौं, हामी प्रदर्शन ड्यासमा नभएका अद्वितीय डेटा ब्लकहरू मात्र पढ्नेछौं।

याे कसरी भयाे?

त्यो सबै परिचयात्मक भागको लागि हो। यो एकदम विस्तृत छ, तर माथि उल्लेख गरिए अनुसार, यी विवरणहरू बिना यो नयाँ प्रकार्यहरूले कसरी काम गर्छ भनेर व्याख्या गर्न सम्भव छैन। त्यसकारण, थप अडान बिना, पहिलोमा जाऔं।

प्रतिलिपि मोड

यो धेरै हदसम्म अवस्थित प्रविधिहरूमा आधारित छ, तर प्रयोगको पूर्णतया फरक तर्क बोक्छ। 

यस मोडको उद्देश्य भनेको स्थानीय सीमामा अवस्थित सबै डाटाको क्षमता ड्यासमा प्रतिलिपि छ भनी सुनिश्चित गर्नु हो।

यदि तपाइँ हेड-अन सार्नुहोस् र प्रतिलिपि मोडहरू तुलना गर्नुहुन्छ भने, यो यस्तो देखिन्छ:

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

नयाँ मोडलाई विचार गर्दा, म साधारण उदाहरणहरूबाट जटिलमा सार्ने प्रस्ताव गर्छु।

सबैभन्दा सामान्य अवस्थामा, हामीसँग केवल वृद्धिका साथ नयाँ फाइलहरू छन्, र हामी तिनीहरूलाई क्षमता शूटिङ दायरामा प्रतिलिपि गर्छौं। ब्याकअप कार्यमा कुन मोड प्रयोग गरिएको छ, हाम्रो अपरेटिङ सञ्झ्यालको म्याद सकिएको छ कि छैन, चाहे त्यो चेनको सील गरिएको भाग हो वा होइन। तिनीहरूले मात्र यसलाई लिए र प्रतिलिपि गरे।

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

प्रश्न उठ्छ - यदि तपाइँ UI मा हेर्नुहुन्छ, त्यहाँ एकै समयमा दुबै विकल्पहरू चयन गर्ने अवसर छ। यस्तो संयुक्त मोड कसरी काम गर्नेछ?

यसलाई आंकडा गरौं।

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

यो सबै मनमोहक तर्क इन्टरफेसमा केवल एउटा चेकबक्सको लागि जिम्मेवार छ: ब्याकअपहरू सिर्जना हुने बित्तिकै वस्तु भण्डारणमा प्रतिलिपि गर्नुहोस्।

हामीलाई यो प्रतिलिपि मोड किन चाहिन्छ?

यो प्रश्नलाई यसरी दोहोर्‍याउनु अझ राम्रो छ: हामी यसको मद्दतले कस्ता जोखिमहरूबाट सुरक्षित छौं? यसले हामीलाई कुन समस्या समाधान गर्न मद्दत गर्छ?

जवाफ स्पष्ट छ: निस्सन्देह, यो डाटा रिकभरी हो। यदि हामीसँग वस्तु भण्डारणमा स्थानीय डेटाको पूर्ण प्रतिलिपि छ भने, त्यसपछि हाम्रो उत्पादनलाई जे भए पनि, हामी सशर्त Amazon मा अवस्थित फाइलहरूबाट डाटा पुनर्स्थापना गर्न सक्छौं।

त्यसोभए सम्भावित परिदृश्यहरू मार्फत जाऔं, सरलदेखि थप जटिलसम्म।

हाम्रो टाउकोमा पर्न सक्ने सबैभन्दा सरल दुर्भाग्य भनेको जगेडा श्रृंखलामा फाइलहरू मध्ये एउटाको पहुँच नहुनु हो।

एउटा दुखद कथा यो हो कि हाम्रो SOBR भण्डारको एक हद तोडियो।

यो अझ खराब हुन्छ जब सम्पूर्ण SOBR भण्डार दुर्गम भएको छ, तर क्षमता शूटिङ दायरा काम गरिरहेको छ।
र सबै कुरा साँच्चै खराब छ - यो जब ब्याकअप सर्भर मर्छ र तपाइँको पहिलो इच्छा दस मिनेटमा क्यानाडाको सीमामा भाग्ने प्रयास गर्ने हो।

अब प्रत्येक अवस्थालाई अलग-अलग हेरौं।

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

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

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

यस केसको उपप्रकार यो हो कि सम्पूर्ण SOBR भण्डार दुर्गम भयो। यस अवस्थामा, हामीसँग स्थानीय भण्डारणबाट प्रतिलिपि गर्न केहि छैन, र सबै ब्लकहरू क्लाउडबाट डाउनलोड गरिएका छन्।

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

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

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

यो सम्भवतः प्रतिलिपि मोडको बारेमा हो र हामी अगाडि बढ्छौं

सिल गरिएको मोड

मुख्य विचार यो हो कि नयाँ ब्याकअपहरू भण्डारको चयन गरिएको SOBR सीमामा देखा पर्न सक्दैन। v10 अघि, हामीसँग केवल मर्मत मोड थियो, जब भण्डारसँग कुनै पनि काम पूर्ण रूपमा निषेध गरिएको थियो। भण्डारण बन्द गर्नको लागि एक प्रकारको हार्डकोर मोड, जहाँ केवल Evacuate बटन उपलब्ध छ, जसले ब्याकअपहरूलाई एक पटक अर्को हदसम्म ढुवानी गर्छ।

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

तदनुसार, सञ्चालनको सिद्धान्त एकदम सरल छ: सबै लेखन कार्यहरू (नयाँ डेटाको उपस्थिति) निषेध गर्न आवश्यक छ, पढ्न छोड्नुहोस् (पुनर्स्थापना) र मेटाउनुहोस् (अवधारण)।

दुबै मोडहरू एकै साथ प्रयोग गर्न सकिन्छ, तर ध्यान राख्नुहोस् कि मर्मतसम्भार उच्च प्राथमिकता छ।

उदाहरणको रूपमा, दुई विस्तारहरू समावेश भएको SOBR लाई विचार गर्नुहोस्। मानौं कि पहिलो चार दिनको लागि हामीले Forward Forever Incremental मोडमा ब्याकअपहरू सिर्जना गर्यौं, र त्यसपछि हामी हदलाई सील गर्छौं। यसले यो तथ्यलाई निम्त्याउँछ कि हामीले दोस्रो उपलब्ध सीमामा नयाँ सक्रिय पूर्णको सिर्जना सुरु गर्छौं। यदि हाम्रो अवधारण चार छ, तब जब सील गरिएको सीमामा अवस्थित सम्पूर्ण चेन यसको सीमा भन्दा बाहिर जान्छ, यो स्पष्ट विवेक संग मेटिन्छ।

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

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

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

क्षमता शूटिङ दायरा संग चीजहरू अधिक जटिल छन्।

पहिले प्रतिलिपि मोड हेरौं। मानौं कि हामीले सक्रिय रूपमा चार दिनको लागि ब्याकअपहरू सिर्जना गरेका थियौं, र त्यसपछि क्षमता शूटिंग दायरा बन्द गरिएको थियो। हामी केहि पनि मेटाउँदैनौं, तर विनम्रतापूर्वक अवधारण सहन्छौं, त्यसपछि हामी क्षमता शूटिङ दायराबाट डेटा मेटाउँछौं।

लगभग एउटै कुरा सार्न मोडमा हुन्छ - हामी रिटचको लागि पर्खन्छौं, स्थानीय भण्डारणमा पुरानो मेटाउँछौं, र वस्तु भण्डारणमा भण्डारण गरिएको मेटाउँछौं।

सधैं अगाडि बढेको साथ एक रोचक उदाहरण। हामी तीन बिन्दुहरूमा अवधारण स्थापना गर्छौं र सोमबार ब्याकअपहरू बनाउन थाल्छौं, जुन नियमित रूपमा क्लाउडमा प्रतिलिपि गरिन्छ। भण्डारण सिल गरिसकेपछि, ब्याकअपहरू सिर्जना गर्न जारी रहन्छ, तीन बिन्दुहरू कायम राख्दै, तर क्षमता ड्यासमा भण्डारण गरिएको डाटा निर्भर रहन्छ र मेटाउन सकिँदैन। त्यसकारण, हामी बिहीबारसम्म पर्खन्छौं, जब हाम्रो .vbk अवधारणभन्दा बाहिर जान्छ, र त्यसपछि मात्र हामी शान्तपूर्वक सम्पूर्ण सुरक्षित गरिएको चेन मेटाउँछौं।

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

मूलतः यो सबै त्यहाँ छ। त्यसोभए सबैभन्दा हार्डकोर सुविधामा जाऔं -

अपर्याप्तता

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

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

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

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

अब हाम्रो ब्लक जेनरेशन टेक्नोलोजी व्याख्या गर्न एक राम्रो समय हो। वा अवरुद्ध पुस्ता। यो गर्नको लागि, स्थितिलाई विचार गर्नुहोस् जसले यसको उपस्थितिको नेतृत्व गर्यो।

छ दिनको टाइम स्केल लिनुहोस् र तल हामी अपरिवर्तनीयताको अपेक्षित म्याद समाप्त हुने समयलाई चिन्ह लगाउनेछौं। पहिलो दिन हामी डाटा ब्लक ए र यसको मेटाडेटा समावेश गरी एउटा फाइल लिन्छौं र सिर्जना गर्छौं। यदि अपरिवर्तनीयता तीन दिनमा सेट गरिएको छ भने, यो तार्किक छ कि चौथो दिनमा डाटा अनलक र मेटिनेछ। दोस्रो दिनमा हामी समान सेटिङहरूसँग ब्लक बी समावेश गरी नयाँ फाइल २ थप्नेछौं। ब्लक ए अझै चौथो दिनमा हटाउन आवश्यक छ। तर तेस्रो दिनमा केहि भयानक हुन्छ - एउटा File2 फाइल सिर्जना गरिएको छ, नयाँ ब्लक d र पुरानो ब्लक ए को लिङ्क समावेश गर्दछ। यसको अर्थ ब्लक र यसको अपरिवर्तनीयता झण्डाको लागि नयाँ मितिमा रिसेट गरिनु पर्छ, जुन छैटौं दिनमा सारियो। र यहाँ एक समस्या उत्पन्न हुन्छ - वास्तविक जगेडा मा त्यस्ता ब्लक को एक ठूलो संख्या छन्। र तिनीहरूको अपरिवर्तनीयता अवधि विस्तार गर्न, तपाईंले प्रत्येक पटक अनुरोधहरूको ठूलो संख्या बनाउन आवश्यक छ। र वास्तवमा, यो लगभग अन्तहीन दैनिक प्रक्रिया हुनेछ, किनकि उच्च स्तरको सम्भाव्यताको साथ हामीले प्रत्येक प्रतिलिपिको साथ डुप्लिकेट ब्लकहरूको भारी स्ट्याकहरू फेला पार्नेछौं। वस्तु भण्डारण प्रदायकहरूबाट अनुरोधहरूको ठूलो संख्याको अर्थ के हो? सहि ! महिनाको अन्त्यमा ठूलो बिल।

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

हामी समान स्थितिलाई विचार गर्न जारी राखौं, तर ब्लक उत्पादनको साथ। पहिलो दिन हामी ब्लक ए र मेटाडेटाबाट फाइल १ सिर्जना गर्छौं। हामी पुस्ताको अवधि र अपरिवर्तनीयता थप्छौं - यसको मतलब फाइल मेटाउने अवसर छैटौं दिनमा हुनेछ। यदि दोस्रो दिनमा हामीले ब्लक b र ब्लक गर्ने लिङ्क समावेश गरी फाइल २ सिर्जना गर्छौं भने, अपेक्षित मेटाउने मितिमा केही हुँदैन। उनी छैटौं दिनमा जस्तै उभिइन्। र यसरी हामी अनुरोधहरूको संख्यामा पैसा बचत गर्ने प्रयास गर्दैछौं। म्याद सार्न सकिने अवस्था मात्र हो यदि उत्पादन अवधि समाप्त भएको छ। त्यो हो, यदि तेस्रो दिनमा नयाँ File1 ले a ब्लक गर्न लिङ्क समावेश गर्दछ भने, Gen2 पहिले नै समाप्त भइसकेकोले जेनेरेशन 3 थपिनेछ। र ब्लक a मेटाउने अपेक्षित मिति आठौं दिनमा सर्नेछ। यसले हामीलाई डुप्लिकेट ब्लकहरूको जीवनकाल विस्तार गर्न अनुरोधहरूको संख्या नाटकीय रूपमा घटाउन अनुमति दिन्छ, जसले ग्राहकहरूलाई धेरै पैसा बचत गर्छ।

टेक्नोलोजी आफैं S3 र S3-कम्प्याटिबल हार्डवेयरका प्रयोगकर्ताहरूका लागि उपलब्ध छ, जसका निर्माताहरूले ग्यारेन्टी दिन्छन् कि तिनीहरूको कार्यान्वयन अमेजनको भन्दा फरक छैन। तसर्थ वैध प्रश्नको जवाफ किन Azure समर्थित छैन - तिनीहरूसँग समान सुविधा छ, तर यसले कन्टेनरको स्तरमा काम गर्दछ, व्यक्तिगत वस्तुहरू होइन। वैसे, Amazon आफैंमा दुई मोडमा वस्तु लक छ: अनुपालन र शासन। दोस्रो अवस्थामा, त्यहाँ सम्भाव्यता रहन्छ कि व्यवस्थापक माथिको सबैभन्दा ठूलो प्रशासक र जरा माथिको मूल, वस्तु लकको बाबजुद, अझै पनि डाटा मेट्छ। अनुपालनको मामलामा, सबै चीजहरू कडा रूपमा नेल गरिएको छ र कसैले पनि ब्याकअपहरू मेटाउन सक्दैन। अमेजन प्रशासकहरू पनि (तिनीहरूको आधिकारिक बयान अनुसार)। यो हामीले समर्थन गर्ने मोड हो।

र, सामान्य रूपमा, केहि उपयोगी लिङ्कहरू:

• बारेमा ब्लक जेनेरेसन प्रत्येक विवरणमा।
• बारे सबै जानकारी Veeam ब्याकअप र प्रतिकृति 10 यसको सबै भन्दा राम्रो मा
• О क्षमता टियर विवरण मा

स्रोत: www.habr.com