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 पुनर्स्थापित गर्दा जडान फर्किन्छ; यसले अघिल्लो प्रतिलिपि पूरा भयो कि भएन वा विरोधाभासी सम्पादन कहिल्यै समाधान भए कि भएन भन्ने बताउँदैन।