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നെറ്റ്വർക്ക് മാറ്റത്തിന് ശേഷം കൈമാറ്റവും പുനഃസ്ഥാപനവും രണ്ടും ആവർത്തിക്കുക, മെച്ചപ്പെടുത്തൽ ഡാറ്റ വേഗത്തിൽ നീക്കുന്നത് മാത്രമല്ല, ബാക്കപ്പിന് സേവിക്കുന്നതാണെന്ന് കാണിക്കാൻ. ആ രണ്ടാം ഓട്ടമാണ് ടിക്കറ്റ് അടയ്ക്കുന്നത്. പരിശോധിക്കാത്ത പുനഃസ്ഥാപനത്തോടെയുള്ള വേഗതയേറിയ കൈമാറ്റം സംരക്ഷണമില്ലാതെ തുടരാനുള്ള മന്ദഗതിയിലുള്ള വഴിയാണ്.