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 मार्फत बाह्र गिगाबाइटको अपलोडबारे छोटो परीक्षणमा नापिएको कुनै पनि शिखर गतिभन्दा बढी बताउँछ।