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 पुनर्संचयित केल्याने कनेक्टिव्हिटी परत येते; मागील प्रत पूर्ण झाली का किंवा परस्परविरोधी संपादने कधी सुटली का हे ते सांगत नाही।