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નેટવર્ક ફેરફાર પછી ટ્રાન્સફર અને પુનઃસ્થાપન બંનેનું પુનરાવર્તન કરો, જેથી સુધારો ફક્ત ડેટા ઝડપથી ખસેડવાનો નહીં પણ બેકઅપની સેવા કરતો દેખાય. તે બીજી રન જ ટિકિટ બંધ કરે છે. અપરીક્ષિત પુનઃસ્થાપન સાથેનું ઝડપી ટ્રાન્સફર અસુરક્ષિત રહેવાની એક ધીમી રીત છે.