Rsync के लिए दो रिमोट का उपयोग करना क्यों संभव नहीं है? [बन्द है]

Question

जब स्रोत और गंतव्य दोनों दूरस्थ हों, तो rsync शिकायत करता है:

The source and destination cannot both be remote. rsync error: syntax or usage error (code 1) at main.c(1156) [Receiver=3.0.7]

वहाँ rsync बनाने के लिए एक दुर्गम तकनीकी बाधा है? या यह केवल अभी तक लागू नहीं होने का मामला है? स्मृति में एक स्थानीय बफ़र बनाना अपेक्षाकृत आसान लगता है जो दो रीमेक और डेटा दोनों को पकड़कर स्थानांतरण के बीच मध्यस्थता करता है।

संपादित करें

चूंकि लोग कुछ ठोस सुझाव दे रहे हैं, इसलिए मैंने अपने विशेष उपयोग मामले का विवरण देते हुए एक अलग प्रश्न पोस्ट किया है । ये दो अलग-अलग हैं, वास्तव में, और मुझे लगता है कि rsync के लिए इन विशेष विवरणों को जानना सार्थक होगा

Comments

इसमें एक दूरस्थ ss rsyncd का डेटा भेजने वाला एक src rsyncd शामिल होगा। आप इसे ssh'ing द्वारा src सिस्टम और rsync पर इनवाइट करके काम कर सकते हैं।

— एलेक्स हॉल्स्ट

@ एलेक्सहॉलस्ट मुझे नहीं लगता कि यह मेरे विशेष मामले में काम करेगा। देखें संपादित करें

— goncalopp

क्षमा करें, सर्वर दोष सैद्धांतिक प्रश्नों से निपटता नहीं है; केवल उन समस्याओं के बारे में जवाब देने योग्य प्रश्न जो आप वास्तव में सामना करते हैं। देखें पूछे जाने वाले प्रश्न अधिक जानकारी के लिए।

— क्रिस एस

क्षमा करें (मॉडरेटर्स), यह एक जवाबदेह दिलचस्प सवाल है: इसका कारण यह है कि rdiff एल्गोरिथम सममित नहीं हो सकता है। एक बड़ा सीपीयू और मेमोरी ओवरहेड "सक्रिय" पक्ष पर है। "निष्क्रिय" पक्ष को केवल सभी संशोधित फ़ाइलों के सभी ब्लॉकों (देखें --ब्लॉक-आकार पैरामीटर) के चेकसम की गणना करने और उन्हें फिर से व्यवस्थित करने की आवश्यकता है। यह बहुत ही छोटी मेमोरी आवश्यकताओं के साथ किया जाता है और अधिकांश ऑपरेशन पहले स्तर के सीपीयू कैश में किए जा सकते हैं। "सक्रिय" पक्ष को एक चेकसम के द्वारा खोज करने की आवश्यकता है जहां एक ही डेटा ब्लॉक अभी स्थित है ...

— हाइनेसेर

मुझे लगता है कि यह एक महान प्रश्न है (मेरे पास बिल्कुल यह प्रश्न था, इसीलिए मैं यहां हूं) और समापन कारण फर्जी है। मैं अभी भी जवाब जानना चाहता हूं!

— रीइनियरियरपोस्ट

Answer 1

क्यों नहीं प्रयास करें और रिमोट मशीन से कनेक्ट करें और वहां से स्थानांतरण शुरू करें। यदि आप ssh-keys का उपयोग कर रहे हैं तो आप एजेंट पास का उपयोग कर सकते हैं, हालांकि आपके लिए प्रमाणिकता का प्रबंधन करने के लिए।

ssh -A remotehostA rsync /remote/file/on/host/a remoteHostB:/destination/

यह कमांड आपको रिमोटहॉस्ट पर लॉग करेगा और वहां से rsync चलाएगा।

Comments

इसमें कुछ सुरक्षा विचार शामिल हैं। देखें संपादित करें

— goncalopp

इसके अलावा, अगर आपके पास दो प्रणालियों के बीच सीधी पहुंच नहीं है, तो यह काम नहीं करेगा ... और अगर सीधी पहुंच प्राप्त करना सुरक्षा खंड के लिए दो सप्ताह की प्रतीक्षा करना शामिल है, तो शायद फ़ायरवॉल नियमों को सही ढंग से लागू किया जा सके ...

— Gert van den Berg

परिदृश्य: सर्वर A में सर्वर B और C की कुंजी-आधारित रूट एक्सेस है। आप दोनों पर रूट एक्सेस का उपयोग करके B से C तक सिंक करना चाहते हैं। लेकिन आप B या C को एक दूसरे के लिए रूट एक्सेस नहीं देना चाहते हैं।

— थोमसट्रेटर

Answer 2

scp -3r <remote src> <remote dest>

ऐसा करने में कोई परेशानी नहीं है।

Comments

scp, हालांकि, AFAIK को डेल्टास नहीं करता है और इस मामले में इसकी बुरी तरह से जरूरत है। मेरे संपादन पर अधिक विवरण

— goncalopp

अगर आप मेजबानों के बीच छद्म की तरह रहना चाहते हैं तो Btw, scp -3 के विकल्प -3 के साथ होना चाहिए

— परिवर्तन 18

दुर्भाग्य से एससीपी में rsync की महत्वपूर्ण विशेषताओं का अभाव है जैसे: फाइलसिस्टम से पार नहीं करने का विकल्प (जैसे कि उपयोगकर्ता फ़ोल्डर में नेटवर्क ड्राइव), संग्रह मोड (जिसमें "प्रतीकात्मक लिंक, डिवाइस, विशेषताएँ, अनुमतियां, मालिकाना, आदि संरक्षित हैं"), आदि। ...

— बस्तियन

Answer 3

आप इसके साथ दूरस्थ फाइल सिस्टम के बढ़ते (या दोनों) द्वारा काम कर सकते हैं sshfs। फिर, rsync इसे मानेंगे जैसे कि यह स्थानीय था।

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

बेशक, आदर्श समाधान मशीनों के लिए एक दूसरे से सीधे बात करने के लिए है। मैं किसी भी अच्छे कारण के बारे में नहीं सोच सकता कि उन्हें क्यों नहीं करना चाहिए।

Comments

संपादित देखें। आप जिस कारण का उल्लेख कर रहे हैं वह सुरक्षा है। ए (रूट) समझौता दो मशीनों में से किसी एक को दूसरे के लिए फाइल सिस्टम तक नहीं पहुंचना चाहिए। लेकिन शायद मैं गलत कोण से इस पर हमला कर रहा हूं और एक ऐसा समाधान है जिसमें एक तीसरी मशीन शामिल नहीं है ...

— गॉनकॉप्लॉप

हम्म। मुझे लगता है कि इस विवरण को वास्तव में इस प्रश्न में जोड़ा जाना चाहिए। एक रूट समझौता के लिए, आपको वास्तव में SELinux का उपयोग करना चाहिए।

— माइकल हैम्पटन

मैंने इसे एक छोड़ दिया क्योंकि किसी और को विशेष रूप से rsync पर इस व्यवहार में दिलचस्पी हो सकती है। AFAIK, किसी भी मशीन पर SELinux यह नहीं बता सकता है कि क्या दूसरे से समझौता किया गया है यदि स्थानीय रूप से निष्पादित rsync दोनों मामलों में एक ही व्यवहार है (किसी विशेष निर्देशिका में फाइल सिस्टम का उपयोग)।

— 1

मुझे यकीन नहीं है कि अगर आप समझते हैं कि SELinux कैसे काम करता है। इसकी पूरी बात यह है कि यह एक सेवा (यहां तक ​​कि एक समझौता सेवा) को उन चीजों तक पहुंचने से रोकता है जिन्हें स्पष्ट रूप से उपयोग करने की अनुमति नहीं है, भले ही वह सेवा जड़ के रूप में चलती हो।

— माइकल हैम्पटन

मेरे पास केवल SELinux नीतियों की एक बुनियादी समझ है, लेकिन rsync को फाइल सिस्टम तक पहुँचना चाहिए, है ना? यदि दूरस्थ मशीन से समझौता किया जाता है , तो ठीक उसी तरह का (स्थानीय) एक्सेस पैटर्न अवांछनीय होता है।

— goncalopp