VPN मा क्लाउड ब्याकअप ढिलो छ: वास्तविक चरण पत्ता लगाउनुहोस्
ढिलो ब्याकअप स्थानान्तरणको सट्टा स्क्यान, ह्यास वा पुनः प्रयास गर्दै हुन सक्छ। मार्गहरू परिवर्तन गर्नु अघि चरण, गन्तव्यको प्रकार र पुनर्स्थापना तुलना गर्नुहोस्।
VPN मा घस्रिरहेको ब्याकअपले टनेल विच्छेद गरेर फेरि नाप्ने स्पष्ट प्रयोगको निम्तो दिन्छ। त्यो प्रयोगले प्रायः अर्कै प्रश्नको उत्तर दिन्छ, किनकि कामले बाइट सार्नुको सट्टा फाइलहरू ह्यास गरिरहेको वा पुनः प्रयासको प्रतीक्षा गरिरहेको हुन सक्छ। पहिले चरणहरू अलग गर्नुहोस्, गुनासो निश्चित अपेक्षित नतिजा भएको निश्चित परीक्षामा परिणत हुन्छ। स्थानान्तरण चरण नै साँच्चै ढिलो भएको अवस्थामा मात्र मार्ग उम्मेदवार बन्छ।
ढिलो लाग्दा काम कुन चरणमा छ
ब्याकअप उपकरणहरू चरणहरूबाट जान्छन्: फाइलहरू पत्ता लगाउने, तिनीहरूलाई पढेर ह्यास गर्ने, सम्पीडन गर्ने, इन्क्रिप्ट गर्ने, अपलोड गर्ने र त्यसपछि प्रमाणित गर्ने। प्रत्येक चरणको आफ्नै अवरोध हुन्छ, र तीमध्ये केहीले मात्र नेटवर्क छुन्छन्। अझै कुनै चरण नबताउने उपकरणले तपाईंलाई स्क्यानिङ सकिएको छैन भनी बताइरहेको हुन्छ।
दश लाख साना फाइल तयार गर्न बीस मिनेट खर्च गर्ने काम टनेल छिटो हुँदा छिटो हुँदैन। अपलिङ्क भर्ने काम फरक समाधान भएको क्षमता समस्या हो। ढिलाइ हुँदै गर्दा प्रगति आउटपुट पढ्नुहोस्, चरण नोट गर्नुहोस् र समय लेख्नुहोस्, किनकि गुनासोको समयको चरण मात्र महत्त्वपूर्ण हुन्छ। साना फाइलहरू एक ठूलो वस्तुभन्दा फरक व्यवहार गर्छन्, किनकि प्रत्येक फाइलको आउने-जाने यात्रा प्रबल हुन्छ र स्थानान्तरण कहिल्यै स्थिर दरमा पुग्दैन। टनेलको बारेमा निष्कर्ष निकाल्नु अघि समानलाई समानसँग तुलना गर्नुहोस्।
सार्वजनिक इन्डपोइन्ट र निजी NAS फरक तरिकाले असफल हुन्छन्
सार्वजनिक ब्याकअप सेवाले आफ्नै प्रमाणित अनुप्रयोग जडान बोक्छ, र टनेल लामो मार्गको एक फड्को हो। निजी NAS सामान्यतया तपाईंको नेटवर्कमा आधारभूत पहुँचका लागि त्यही टनेलमा निर्भर हुन्छ। त्यही भिन्नताले विच्छेद गर्नु वैध आधाररेखा हो वा केही नभएको परीक्षा हो भन्ने निर्धारण गर्छ।
सार्वजनिक अवस्थामा, नीतिले अनुमति दिएमा अर्को मार्गबाट त्यही काम न्यायपूर्ण तुलना हुन सक्छ। निजी अवस्थामा, टनेल हटाउँदा सर्भरसम्म कुनै मार्ग बाँकी रहँदैन, त्यसैले नतिजाले तपाईंले प्रयोग गर्ने मार्ग नभई मेटाएको मार्गको वर्णन गर्छ।
| Destination | What the tunnel provides | Valid baseline |
|---|---|---|
| Public backup service | One hop among several | The same job over another route |
| Private NAS | The only path to the server | None that removes the tunnel |
| Self-hosted gateway | Path plus split-DNS policy | Only if the policy is unchanged |
रोकिनु ढिलो स्थानान्तरणभन्दा फरक असफलता हो
त्यस तालिकाको तेस्रो स्तम्भले स्थिरता परीक्षा नै गर्न सकिन्छ कि सकिँदैन भन्ने निर्धारण गर्छ, किनकि टनेल हटाउने आधाररेखाको अर्थ अर्को मार्ग भएको ठाउँमा मात्र हुन्छ। प्रयोगयोग्य आधाररेखासँग औसत दर नभई असफलताको आकार हेर्नुहोस्। कम तर स्थिर अपलोडले क्षमतातर्फ संकेत गर्छ, जबकि रोकिएर फेरि सुरु हुने कामले अवरोध, प्रमाणीकरण वा एउटा समस्याग्रस्त फाइलतर्फ। यी दुईले लगभग उस्तै गुनासा र पूर्ण रूपमा फरक मर्मत उत्पन्न गर्छन्।
पुनः प्रयासहरूले हरेक मापन विकृत गर्छन्, किनकि तारमा रहेका बाइटहरू वास्तवमा परिवर्तन भएको मात्राभन्दा बढी हुन सक्छन्। के हुन्छ देख्न काम फेरि अवरुद्ध गर्नु अघि पुनः सुरु हुने व्यवहार पढ्नुहोस्, किनकि टुक्राटुक्रा पुनः सुरु हुन सक्ने अपलोडहरू सस्तैमा सुधारिन्छन् र पूरै फाइल पुनः सुरु गर्ने होइन। हरेक केही मिनेटमा फेरि जोडिने टनेल पनि वास्तवमा स्थिरताको समस्या हुँदा ब्यान्डविथ समस्याजस्तो देखिन्छ। मार्गको MTU ले यसलाई बढाउँछ, किनकि उपयोगी पेलोड घटाउने टनेलले ठूला खण्ड रोक्छ, साना भने पार हुन्छन्।
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.comएउटा अपलोडले अन्य सबै प्रवाहलाई भोकाउन सक्छ
अपलिङ्क भर्ने अपलोडले कल र ब्राउजिङलाई प्रतिक्रियाहीन बनाउँछ, र ब्याकअप त्यसका लागि प्रतिस्पर्धा गर्ने एकमात्र वस्तु विरलै हुन्छ। दोस्रो सिंक क्लाइन्टले आफैं त्यही लक्षण उत्पन्न गर्छ। टनेललाई दोष दिनु अघि अरू के अपलोड हुँदै छ हेर्नुहोस्।
अधिकतम थ्रुपुटका लागि लड्नुको सट्टा उपकरणले अभिलेख गर्ने तालिका वा ब्यान्डविथ सीमा प्रयोग गर्नुहोस्; अन्तरक्रियात्मक कामका लागि ठाउँ छोड्नु सामान्यतया अन्तिम केही प्रतिशतभन्दा बढी मूल्यवान हुन्छ। त्यसपछि सीमा वास्तवमा केमा लागू हुन्छ जाँच्नुहोस्, किनकि केही उपकरणले प्रति फाइल, केहीले पूरै रनमा सीमा लगाउँछन्, र केहीले साना फाइलको अतिरिक्त भार पूर्ण रूपमा बेवास्ता गर्छन्। कामको भारसँग नमिल्ने सीमाले केही पनि परिवर्तन गर्दैन। स्प्लिट टनेलिङ पनि यहाँ शंकास्पद छ, किनकि लन्चरलाई टनेलबाट बाहिर राख्दा अपलोड गर्ने सहायक सेवा बाहिर पर्दैन। उदाहरणका लागि Rclone ले स्थानान्तरण सीमा र पुनः प्रयासको व्यवहार दुवै आफ्नो कागजातमा प्रकाशित गर्छ, जसले सीमाले के नियन्त्रण गर्नुपर्छ भन्नेमा उपयोगी सन्दर्भ बनाउँछ।
गति परीक्षणले होइन, पुनर्स्थापनाले अन्त्य गर्नुहोस्
पूरा भएको अपलोड त्यसबाट केही पुनर्स्थापित नभएसम्म ब्याकअप होइन। अपेक्षित संस्करण अवस्थित छ भनी पुष्टि गर्नुहोस्, त्यसपछि उपकरणले अभिलेख गर्ने प्रक्रियाबाट प्रतिनिधि फाइल पुनर्स्थापित गर्नुहोस्। पुनःप्राप्ति जानकारी गुमाउन सकिने मेसिन वा प्रोफाइलबाहेक अन्त कतै राख्नुहोस्, र प्रयोग सफा राख्न मात्र काम गर्ने ब्याकअप कहिल्यै नफाल्नुहोस्।
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hostsनेटवर्क परिवर्तनपछि स्थानान्तरण र पुनर्स्थापना दुवै दोहोर्याउनुहोस्, ताकि सुधार केवल डेटा छिटो सार्ने नभई ब्याकअपकै सेवामा देखियोस्। त्यही दोस्रो रनले टिकट बन्द गर्छ। नपरीक्षिएको पुनर्स्थापनासहितको छिटो स्थानान्तरण सुरक्षाविना रहनुको ढिलो मार्ग हो।