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नेटवर्क बदलानंतर हस्तांतरण आणि पुनर्संचयन दोन्ही पुन्हा करा, जेणेकरून सुधारणा केवळ डेटा वेगाने हलवण्यासाठी नव्हे, तर बॅकअपसाठी काम करते हे दिसेल. तीच दुसरी फेरी तिकीट बंद करते. न तपासलेल्या पुनर्संचयनासह वेगवान हस्तांतरण हा संरक्षणाशिवाय राहण्याचा हळू मार्ग आहे.