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नेटवर्क बदलने के बाद स्थानांतरण और पुनर्स्थापन दोनों दोहराएँ, ताकि सुधार केवल डेटा तेज़ी से खिसकाने का नहीं बल्कि बैकअप की सेवा करने वाला दिखे। वही दूसरी बारी टिकट बंद करती है। बिना परखे पुनर्स्थापन के साथ तेज़ स्थानांतरण असुरक्षित रहने का एक धीमा तरीका है।