VPN पर rsync: टूटे स्थानांतरण का पुनःउपयोग करता फिर से प्रयास

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

फिर से प्रयास स्थिति का पुनर्निर्माण करता है, स्ट्रीम को जारी नहीं रखता

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

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

तय करें कि पुनःउपयोग योग्य टुकड़ा कहाँ रहता है

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

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

गंतव्य पर भी क्रम मायने रखता है: आंशिक निर्देशिका को टुकड़े के लिए पर्याप्त जगह चाहिए, और वॉल्यूम को पूरी फ़ाइल के लिए भी पर्याप्त जगह चाहिए। स्थानांतरण के बीच में लक्ष्य वॉल्यूम भर जाने से ऐसी विफलता होती है जो नेटवर्क समस्या जैसी लगती है पर है नहीं, और वह रखे गए टुकड़े को कटा हुआ छोड़ सकती है। रन शुरू होने से पहले प्राप्त करने वाले होस्ट पर खाली जगह जाँचें, विफल होने के बाद नहीं। उसी SSH पथ पर df -h के साथ कुछ सेकंड योजना की सबसे सस्ती संभव परीक्षा है।

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

वही प्रति चलाएँ, कोई चालाक नहीं

पुनःउपयोग केवल तब लागू होता है जब स्रोत और गंतव्य अब भी वही वस्तु बताते हों। वही पथ, वही नाम, वही फ़ाइल। स्रोत का नाम बदलना या दूसरी गंतव्य निर्देशिका की ओर इशारा करना किसी काम की चीज़ के विरुद्ध नई तुलना शुरू करता है।

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

प्रगति पंक्ति स्थानांतरण की कुल प्रगति बताती है। यह पूर्णता का संकेत नहीं है। कनेक्शन के अभी खुला रहते सौ प्रतिशत तक पहुँची संख्या का अर्थ है कि डेटा भेज दिया गया है, यह नहीं कि प्राप्तकर्ता ने कुछ नाम बदला, समन्वयित या स्वीकार किया है।

वस्तु को मेल खाने के बाद ही स्वीकार करें

पहले निकास स्थिति की पुष्टि करें, फिर त्रुटियों की अनुपस्थिति पर भरोसा करने के बजाय परिणाम की तुलना करें। आकार जाँच अधिकांश कटे स्थानांतरण पकड़ लेती है; चेकसम तुलना बाकी पकड़ लेती है, और अपलोड फिर चलाने की तुलना में दोनों सस्ते हैं।

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

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

जब सीमा लिंक हो, फ़्लैग नहीं

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

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