rsync VPN के ज़रिये: कौन-सा पक्ष सच्चाई का स्रोत है?

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

कमांड लिखने से पहले तय करें कौन-सी प्रति जीतती है

दिशा को एक वाक्य में लिखें, हर तरफ़ मेज़बान का नाम और पथ सहित, और डेटा के मालिक से मंज़ूरी लें। इस विवरण में स्रोत /srv/publish/ है और गंतव्य fileserver.example पर एक खाता है जिसे केवल /srv/mirror/ में लिखने की अनुमति है।

प्रतिलिपि से पहले परिवहन के तथ्यों की पुष्टि करें: SSH मेज़बान कुंजी सत्यापित है, गंतव्य खाता प्रतिलिपि क्षेत्र में लिख सकता है और कहीं नहीं, और दोनों मेज़बानों के rsync संस्करण संगत हैं। ये पूर्वशर्तें एक छोटी योजना गलती को अनुमति की घटना बनने से रोकती हैं। वे यह भी बताती हैं कि कुछ गड़बड़ होने पर गंतव्य के लॉग में कौन-सा खाता दिखेगा।

प्रतिलिपि का पूर्वावलोकन देखें और विस्तृत सूची पढ़ें

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

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

हर पंक्ति को अपने इरादे वाले गंतव्य के मुकाबले पढ़ें। पूर्वावलोकन ध्वज हटाना प्रतिलिपि पूरी करता है और फ़ाइलों को ऊपर लिख सकता है, और हटाने के विकल्प के बिना गंतव्य पर पहले से मौजूद अतिरिक्त फ़ाइलें बस वहीं रह जाती हैं जहाँ हैं। यह केवल तभी सुरक्षित चूक है जब आपने सचमुच तय किया हो कि पीछे छोड़ी गई पुरानी फ़ाइलें स्वीकार्य हैं। अगर जवाब नहीं है, तो नीचे दिया गया हटाने का फ़ैसला लेना है, इस कमांड में कोई अतिरिक्त ध्वज बिखेरना नहीं।

फिर तय करें कि हटाना यात्रा करता है या नहीं

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

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

दो एकतरफ़ा काम मिलकर दोतरफ़ा सिंक नहीं बनते

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

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

नीति लिखे जाने के बाद ही स्वचालित करें

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

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

पूर्णताएँ और विफलताएँ दर्ज करें, और केवल निकास कोड के बजाय गंतव्य पर डेटासेट जाँचें। बाधा के बाद VPN बहाल करना कनेक्टिविटी बहाल करता है; यह नहीं बताता कि पिछली प्रति पूरी हुई या परस्पर विरोधी संपादन कभी सुलझे।