Pritunl: नियंत्रण स्थिती विरुद्ध तयार केलेली प्रोफाइल

एक संग्रह कार्यरत Pritunl तैनाती पुनर्संचयित करतो; दुसरा फक्त त्याची प्रतिमा पुनर्संचयित करतो। क्लायंट प्रोफाइल, होस्ट कॉन्फिगरेशनची प्रत आणि स्थिती निर्देशिकेचा tarball सर्व बॅकअपसारखे दिसतात आणि त्यापैकी कोणतेही एकटे Pritunl व्यवस्थापित करते ते संस्था, वापरकर्ते आणि सर्व्हर व्याख्या परत आणत नाही। फरक मालकीचा आहे: स्थितीचा काही भाग डेटाबेसचा, काही होस्टचा आणि काही पुन्हा तयार केलेला आउटपुट आहे। चुकीचा स्तर निवडा आणि पुनर्संचयन असा सर्व्हर तयार करते जो सुरू होतो, ऐकतो आणि काहीही जाणत नाही। ही तुलना तीन स्तर वेगळे करते जेणेकरून तुमचा ठेवलेला संग्रह तुम्ही ज्या बिघाडातून सावरत आहात त्याला जुळेल।

दोन वस्तू बॅकअपसारख्या दिसतात आणि फक्त एक सेवा पुनर्संचयित करते

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

होस्ट कॉन्फिगरेशनची प्रतही तितकीच अर्धवट आहे। /etc/pritunl.conf होस्ट-स्तरीय सेटिंग्ज ठेवते, ज्यात डेटाबेसपर्यंत पोहोचण्याचा मार्ग समाविष्ट आहे, आणि स्वतः VPN ऑब्जेक्ट ठेवत नाही।

डेटाबेस काय ठेवते आणि होस्ट काय ठेवते

Pritunl सर्व्हर व्याख्या, वापरकर्ते, संस्था आणि की MongoDB मध्ये ठेवते। तो डेटाबेस अधिकृत नियंत्रण तल आहे आणि डिस्कवर तयार केलेली प्रत्येक OpenVPN फाइल त्यातून घेतलेला आउटपुट आहे। तयार केलेल्या फाइलमध्ये थेट केलेला बदल पुढील पुनर्निर्मितीपर्यंत टिकतो आणि नंतर नाहीसा होतो, म्हणून रनटाइम फाइल्स संपादित करणे टिकाऊ दुरुस्ती नाही। तोच नियम प्रभावी मार्ग आणि इंटरफेसना लागू होतो: ते नियंत्रण तलाने काय तयार केले हे सांगतात, त्याने काय तयार केले पाहिजे हे नाही।

होस्ट लहान पण हस्तांतरित न होणारा मूल्यांचा संच देतो। त्यापैकी एक म्हणजे /var/lib/pritunl/pritunl.uuid, त्या विशिष्ट नोडची ओळख।

ती ओळख क्लस्टरमध्ये सर्वात महत्त्वाची आहे। बदली होस्टला सक्रिय नोडच्या UUID च्या क्लोनऐवजी स्वतःची नोंदणी हवी असते, अन्यथा दोन्ही एकाच ओळखीसाठी भांडतात। प्रत्येक होस्ट, त्याचे UUID आणि तो ज्या डेटाबेसकडे निर्देश करतो त्यामधील मॅपिंग नोंदवा, कारण एकच डेटाबेस डंप कोणत्या होस्ट सेटिंग्ज कोणत्या मशीनच्या होत्या हे सांगत नाही। सॉफ्टवेअर आवृत्त्या आणि सार्वजनिक एंडपॉइंट नावे त्याच नोंदीत येतात।

सुसंगत डंप घ्या, निर्देशिकेची प्रत नाही

सेवा लिहित असताना MongoDB डेटा निर्देशिकेची प्रत केल्यास अशा फाइल्स तयार होतात ज्या वापरण्यायोग्य डेटाबेस बनवू शकत नाहीत। त्याऐवजी डेटाबेसचा समर्थित डंप मार्ग वापरा, जो तुमच्याकडे प्रत्यक्षात असलेल्या टोपोलॉजीविरुद्ध चालवला जाईल:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

एकटा होस्ट तो साधा आकार सहन करतो। प्रतिकृती संचाला सुसंगत वेळ-बिंदू हवा असतो आणि oplog-आधारित डंपला अशा गरजा असतात ज्या साध्या डंपला नसतात। समर्थित प्रक्रिया तुमच्या MongoDB आवृत्ती आणि टोपोलॉजीवर अवलंबून असते, म्हणून ती डेटा निर्देशिकेच्या उपस्थितीवरून ठरवू नका। होस्ट स्तर डंपच्या शेजारी, त्याच रनमध्ये, त्याच टाइमस्टॅम्पसह संग्रहित करा।

गरज पडण्यापूर्वी पुनर्संचयनाचा सराव करा

जे बॅकअप कोणीही पुनर्संचयित केले नाही ते गृहीतक आहे। सेवा वेगळ्या नेटवर्कमध्ये उभारा, डंप पुनर्संचयित करा आणि होस्ट फाइल्स परत ठेवा:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

शेवटी, लक्षात ठेवा की जुना स्नॅपशॉट जुने निर्णय पुनर्संचयित करतो। जर प्रशासकाने डंप घेतल्यानंतर ओळख अक्षम केली असेल, तर पुनर्संचयन ती पुन्हा सक्षम करते। पुनर्संचयनानंतरचा मेळ प्रक्रियेचा भाग आहे, उशिराच्या विचाराचा नाही।