कॅपॅसिटी टियर (किंवा आपण त्याला Vim - captir मध्ये म्हणतो) Veeam बॅकअप आणि प्रतिकृती 9.5 अपडेट 4 च्या काळात आर्काइव्ह टियर नावाने पुन्हा दिसले. तथाकथित ऑपरेशनल रिस्टोअर विंडोमधून बाहेर पडलेले बॅकअप ऑब्जेक्ट स्टोरेजमध्ये हलवणे शक्य करणे ही त्यामागची कल्पना आहे. यामुळे ज्या वापरकर्त्यांकडे डिस्क स्पेस कमी होती त्यांच्यासाठी जागा मोकळी करण्यात मदत झाली. आणि या पर्यायाला मूव्ह मोड असे म्हणतात.

ही साधी (जसे दिसते) क्रिया करण्यासाठी, दोन अटी पूर्ण करणे पुरेसे होते: हलवलेल्या बॅकअपमधील सर्व बिंदू वर नमूद केलेल्या ऑपरेशनल रिस्टोर विंडोच्या सीमेबाहेर असले पाहिजेत, जे UI मध्ये स्पष्टपणे सेट केले आहे. आणि दुसरे: साखळी तथाकथित "सीलबंद फॉर्म" (सीलबंद बॅकअप चेन किंवा निष्क्रिय बॅकअप चेन) मध्ये असणे आवश्यक आहे. म्हणजेच कालांतराने या साखळीत कोणतेही बदल होत नाहीत.

परंतु व्हीबीआर v10 मध्ये, संकल्पना नवीन फंक्शन्ससह पूरक होती - कॉपी मोड, सीलबंद मोड आणि एक गोष्ट ज्याचा उच्चार करणे कठीण आहे ते अपरिवर्तनीयता दिसले.

या आकर्षक गोष्टी आहेत ज्याबद्दल आपण आज बोलणार आहोत. प्रथम, ते VBR9.5u4 मध्ये कसे कार्य करते आणि नंतर दहाव्या आवृत्तीतील बदलांबद्दल.

आणि शुद्ध भाषेचे चॅम्पियन मला माफ करतील, परंतु अशा अनेक संज्ञा आहेत ज्यांचे भाषांतर केले जाऊ शकत नाही.
त्यामुळे येथे एक टन अँग्लिसिज्म असेल.
आणि भरपूर gif.
आणि चित्रे.

• किंचितही खंत न ठेवता. लेखाचे लेखक.

जसे होते तसे

बरं, ऑपरेशनल रिस्टोअर विंडो आणि सीलबंद बॅकअप (किंवा निष्क्रिय बॅकअप चेन डॉक्युमेंटेशनमध्ये म्हटल्याप्रमाणे) विश्लेषण करून प्रारंभ करूया. त्यांच्या आकलनाशिवाय पुढील स्पष्टीकरण शक्य होणार नाही.

आम्ही चित्रात पाहतो त्याप्रमाणे, आमच्याकडे डेटा ब्लॉक्ससह एक प्रकारची बॅकअप शृंखला आहे, जी क्षमता टियर कनेक्ट केलेल्या रेपॉजिटरीच्या परफॉर्मन्स टियर 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 चा विचार करा. असे गृहीत धरू की पहिले चार दिवस आम्ही फॉरवर्ड फॉरएव्हर इन्क्रिमेंटल मोडमध्ये बॅकअप तयार केले आणि नंतर आम्ही मर्यादा सील केली. यामुळे आम्ही दुसऱ्या उपलब्ध मर्यादेवर नवीन सक्रिय पूर्ण तयार करण्यास सुरुवात करतो. जर आपली धारणा चार असेल, तर जेव्हा सीलबंद मर्यादेवर स्थित संपूर्ण साखळी त्याच्या मर्यादेच्या पलीकडे जाते, तेव्हा ती स्पष्ट विवेकाने हटविली जाते.

अशी परिस्थिती असते जेव्हा हटवणे पूर्वी होते. उदाहरणार्थ, हे नियतकालिक फुलांसह फॉरवर्ड इन्क्रिमेंटल आहे. जर आम्ही पहिले दोन दिवस पूर्ण बॅकअप तयार केले आणि गुरुवारी आम्ही रेपॉजिटरी सील करण्याचा निर्णय घेतला, तर शुक्रवारी, नवीन बॅकअप तयार केल्यावर, सोमवारची फाइल हटविली जाईल कारण या बिंदूवर कोणतेही अवलंबित्व नाहीत. आणि मुद्दा स्वतः कोणावरही अवलंबून नाही. मग आम्ही उपलब्ध मर्यादेवर चार बिंदू तयार होईपर्यंत प्रतीक्षा करतो आणि उर्वरित तीन हटवतो, जे एकमेकांपासून स्वतंत्रपणे हटवले जाऊ शकत नाहीत.

रिव्हर्स इन्क्रिमेंटलसह गोष्टी सोप्या आहेत. त्यामध्ये, सर्वात जुने मुद्दे कशावरही अवलंबून नसतात आणि सुरक्षितपणे हटविले जाऊ शकतात. म्हणून, नवीन .vbk नवीन मर्यादेवर तयार होताच, जुने .vrbs एक एक करून हटवले जातील.

तसे, आम्ही प्रत्येक वेळी नवीन .vbk का तयार करतो: जर आम्ही ते तयार केले नाही, परंतु वाढीची जुनी साखळी चालू ठेवली, तर जुने .vbk कोणत्याही मोडमध्ये अमर्याद काळासाठी फ्रीझ होईल, ते हटवण्यास प्रतिबंध करेल. म्हणून, असे ठरले की हद्द सील होताच, आम्ही विनामूल्य मर्यादेवर संपूर्ण बॅकअप तयार करू.

क्षमता शूटिंग श्रेणीसह गोष्टी अधिक क्लिष्ट आहेत.

प्रथम कॉपी मोड पाहू. चला असे गृहीत धरू की आम्ही चार दिवस सक्रियपणे बॅकअप तयार करत होतो आणि नंतर क्षमता शूटिंग श्रेणी सील केली गेली. आम्ही काहीही हटवत नाही, परंतु नम्रपणे धारणा सहन करतो, त्यानंतर आम्ही क्षमता शूटिंग श्रेणीतील डेटा हटवतो.

मूव्ह मोडमध्ये अंदाजे समान गोष्ट घडते - आम्ही रीटचची प्रतीक्षा करतो, स्थानिक स्टोरेजमधील जुने हटवतो आणि ऑब्जेक्ट स्टोरेजमध्ये संग्रहित हटवतो.

फॉरएव्हर फॉरवर्ड वाढीव सह एक मनोरंजक उदाहरण. आम्ही तीन बिंदूंवर धारणा स्थापित करतो आणि सोमवारी बॅकअप घेणे सुरू करतो, जे नियमितपणे क्लाउडवर कॉपी केले जातात. स्टोरेज सील केल्यानंतर, बॅकअप तयार करणे सुरूच राहते, तीन बिंदू राखून ठेवतात, परंतु क्षमता डॅशमध्ये संचयित केलेला डेटा अवलंबून राहतो आणि हटविला जाऊ शकत नाही. म्हणून, आम्ही गुरुवारपर्यंत प्रतीक्षा करतो, जेव्हा आमची .vbk धारणा पलीकडे जाईल आणि त्यानंतरच आम्ही संपूर्ण जतन केलेली साखळी शांतपणे हटवू.

आणि एक लहान अस्वीकरण: येथे सर्व उदाहरणे एका मशीनसह दर्शविली आहेत. तुमच्‍या बॅकअपमध्‍ये त्‍यांच्‍यापैकी अनेक असल्‍यास, त्‍यांचे रीटच अ‍ॅक्टिव्ह फुल केले आहे की नाही यावर अवलंबून असेल.

मुळात एवढेच आहे. चला तर मग सर्वात हार्डकोर वैशिष्ट्याकडे जाऊया -

अपरिपक्वता

मागील मुद्द्यांप्रमाणे, पहिली गोष्ट म्हणजे हे फंक्शन कोणती समस्या सोडवते. आम्ही आमचे बॅकअप कुठेतरी स्टोरेजसाठी अपलोड करताच, त्यांच्या सुरक्षिततेची हमी देण्याची तीव्र इच्छा असते, म्हणजे, त्यांना हटवण्यास आणि दिलेल्या प्रतिधारणादरम्यान कोणतेही बदल शारीरिकरित्या प्रतिबंधित करण्याची. प्रशासकांसह, त्यांच्या मूळ खात्यांसह. हे आपल्याला त्यांना अपघाती किंवा हेतुपुरस्सर नुकसानापासून संरक्षण करण्यास अनुमती देते. AWS सह काम करणार्‍या कोणत्याही व्यक्तीला ऑब्जेक्ट लॉक नावाचे समान वैशिष्ट्य आढळले असेल.

आता सामान्य शब्दात मोड पाहू, आणि नंतर तपशीलांचा शोध घेऊ. आमच्या उदाहरणात, आमच्या क्षमतेच्या शूटिंग रेंजसाठी अपरिवर्तनीयता चार दिवस टिकवून ठेवण्यास सक्षम केली जाईल. आणि बॅकअपमध्ये कॉपी मोड सक्षम केला आहे.

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

डिहायड्रेशन, इंडेक्सेस आणि मेटाडेटा या पूर्वी स्पष्ट केलेल्या सर्व संकल्पना तंतोतंत समान कार्य करत आहेत. परंतु एका अटीसह - ब्लॉक केवळ डेटासाठीच नाही तर मेटाडेटासाठी देखील सेट केला आहे. एखाद्या धूर्त आक्रमणकर्त्याने आमचा मेटाडेटा डेटाबेस मिटवण्याचा निर्णय घेतल्यास आणि डेटा ब्लॉक्सना निरुपयोगी बायनरी मशमध्ये बदलण्यापासून रोखण्यासाठी हे केले जाते.

आमचे ब्लॉक जनरेशन तंत्रज्ञान समजावून सांगण्याची ही उत्तम वेळ आहे. किंवा ब्लॉक जनरेशन. हे करण्यासाठी, त्या परिस्थितीचा विचार करा ज्यामुळे त्याचे स्वरूप आले.

चला सहा दिवसांचा टाईम स्केल घेऊ आणि खाली आपण अपरिवर्तनीयतेच्या अपेक्षित कालबाह्यतेची वेळ चिन्हांकित करू. पहिल्या दिवशी आम्ही डेटा ब्लॉक a आणि त्याचा मेटाडेटा असलेली फाइल घेतो आणि तयार करतो. जर अपरिवर्तनीयता तीन दिवसांवर सेट केली असेल, तर चौथ्या दिवशी डेटा अनलॉक केला जाईल आणि हटविला जाईल असे मानणे तर्कसंगत आहे. दुसऱ्या दिवशी आम्ही एक नवीन फाइल 2 जोडू, ज्यामध्ये समान सेटिंग्जसह ब्लॉक बी असेल. ब्लॉक ए स्टिल चौथ्या दिवशी काढणे आवश्यक आहे. पण तिसर्‍या दिवशी काहीतरी भयंकर घडते - एक File3 फाइल तयार केली जाते, ज्यामध्ये नवीन ब्लॉक डी आणि जुन्या ब्लॉकची लिंक असते. याचा अर्थ ब्लॉक आणि त्याच्या अपरिवर्तनीयतेसाठी ध्वज नवीन तारखेवर रीसेट करणे आवश्यक आहे, जे सहाव्या दिवशी हलवले जाते. आणि येथे एक समस्या उद्भवते - वास्तविक बॅकअपमध्ये अशा ब्लॉक्सची मोठी संख्या आहे. आणि त्यांची अपरिवर्तनीयता कालावधी वाढवण्यासाठी, आपल्याला प्रत्येक वेळी मोठ्या संख्येने विनंत्या करण्याची आवश्यकता आहे. आणि खरं तर, ही जवळजवळ अंतहीन दैनंदिन प्रक्रिया असेल, कारण उच्च संभाव्यतेसह आम्हाला प्रत्येक कॉपीसह डुप्लिकेट ब्लॉक्सचे मोठे स्टॅक सापडतील. ऑब्जेक्ट स्टोरेज प्रदात्यांकडील मोठ्या संख्येने विनंत्यांचा अर्थ काय आहे? बरोबर! महिन्याच्या शेवटी प्रचंड बिल.

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

चला त्याच परिस्थितीचा विचार करणे सुरू ठेवूया, परंतु ब्लॉक जनरेशनसह. पहिल्या दिवशी आम्ही ब्लॉक ए आणि मेटाडेटा मधून फाइल 1 तयार करतो. आम्ही जनरेशन कालावधी आणि अपरिवर्तनीयता जोडतो - याचा अर्थ फाइल हटविण्याची संधी सहाव्या दिवशी असेल. जर दुसऱ्या दिवशी आम्ही ब्लॉक b आणि ब्लॉक a ला लिंक असलेली File2 तयार केली, तर अपेक्षित हटवण्याच्या तारखेला काहीही होणार नाही. सहाव्या दिवशी ती तशीच उभी राहिली. आणि अशा प्रकारे आम्ही विनंत्यांच्या संख्येवर पैसे वाचवण्याचा प्रयत्न करीत आहोत. जनरेशनचा कालावधी कालबाह्य झाला असेल तरच अंतिम मुदत बदलली जाऊ शकते. म्हणजे, जर तिसऱ्या दिवशी नवीन File3 मध्ये a ब्लॉक करण्यासाठी लिंक असेल, तर Gen2 आधीच कालबाह्य झाल्यामुळे जनरेशन 1 जोडला जाईल. आणि ब्लॉक a हटवण्याची अपेक्षित तारीख आठव्या दिवशी शिफ्ट होईल. हे आम्हाला डुप्लिकेट केलेल्या ब्लॉक्सचे आयुष्य वाढवण्याच्या विनंत्यांची संख्या नाटकीयपणे कमी करण्यास अनुमती देते, ज्यामुळे क्लायंटचे बरेच पैसे वाचतात.

तंत्रज्ञान स्वतः S3 आणि S3-सुसंगत हार्डवेअरच्या वापरकर्त्यांसाठी उपलब्ध आहे, ज्यांचे उत्पादक हमी देतात की त्यांची अंमलबजावणी Amazon पेक्षा वेगळी नाही. म्हणूनच Azure ला समर्थन का नाही या कायदेशीर प्रश्नाचे उत्तर - त्यांच्याकडे समान वैशिष्ट्य आहे, परंतु ते वैयक्तिक वस्तूंच्या नव्हे तर कंटेनरच्या पातळीवर कार्य करते. तसे, ऍमेझॉनमध्ये स्वतःच दोन मोडमध्ये ऑब्जेक्ट लॉक आहे: अनुपालन आणि प्रशासन. दुस-या बाबतीत, अशी शक्यता राहते की अॅडमिन्सच्या वरचा सर्वात मोठा प्रशासक आणि रूट्सच्या वरील रूट, ऑब्जेक्ट लॉक असूनही, तरीही डेटा हटवतो. अनुपालनाच्या बाबतीत, सर्वकाही घट्टपणे खिळले आहे आणि कोणीही बॅकअप हटवू शकत नाही. अगदी ऍमेझॉन प्रशासक (त्यांच्या अधिकृत विधानांनुसार). हे आम्ही समर्थन मोड आहे.

आणि, नेहमीप्रमाणे, काही उपयुक्त दुवे:

• वर ब्लॉक जनरेशन प्रत्येक तपशीलात.
• बद्दल सर्व माहिती वीम बॅकअप आणि प्रतिकृती 10 सर्वोत्तम
• О क्षमता टियर विस्तारित

स्त्रोत: www.habr.com