VPN પર rsync: તૂટેલા સ્થાનાંતરણનો પુનઃઉપયોગ કરતો ફરી પ્રયાસ

તમારું અપલોડ બાર ગીગાબાઇટના આર્કાઇવના ચાર ગીગાબાઇટ પર અટકે છે, અને ડાઉનલોડ મેનેજરમાંથી શીખેલી ટેવ કહે છે કે ફરી ચાલુ કરો દબાવો. rsync TCP પ્રવાહ ફરી ચાલુ કરશે નહીં, કારણ કે એ પ્રવાહ ટ્યુનલના છેલ્લા પુનઃપ્રસારણ સાથે ગયો. તે જે કરી શકે છે તે છે પહેલેથી મળેલા બાઇટ રાખવા અને તેમને આગલા પ્રયાસ માટે આધાર તરીકે વાપરવા, જે અલગ નિયમોના સમૂહ સાથેની અલગ પદ્ધતિ છે. તમે પસંદ કરો છો તે ફ્લેગ નક્કી કરે છે કે આ પુનઃઉપયોગ બને છે કે નહીં.

ફરી પ્રયાસ સ્થિતિ ફરી બનાવે છે, પ્રવાહ ફરી ચાલુ કરતો નથી

જ્યારે SSH સત્ર પડે છે, ત્યારે દૂરના છેડે ફક્ત ડિસ્ક પર લખાયું તે જ રહે છે, બીજું કંઈ નહીં. ફરી જોડાવા માટે કોઈ સત્ર ટોકન નથી અને ફરી વગાડવા માટે કોઈ ક્રમ નંબર નથી. આગલી વાર ચલાવવાથી નવું જોડાણ ખૂલે છે, સ્રોત ફરી વાંચે છે અને પ્રાપ્તકર્તાને પૂછે છે કે તેની પાસે પહેલેથી શું છે.

એ જ છેલ્લો પ્રશ્ન સમજાવે છે કે આંશિક ફાઇલ રાખવી કેમ યોગ્ય છે. પ્રાપ્તકર્તાની નકલ rsyncને સરખાવવા માટે કંઈક આપે છે, અને અલ્ગોરિધમ ફક્ત એ જ ફરક મોકલે છે જે તે ઓળખી શકે છે. આ હજી મેટાડેટાનું નવું સ્થાનાંતરણ અને સ્રોત પરની નવી પસંદગી છે, તેથી બચેલો સમય ફાઇલમાંથી કેટલું મળે છે તેના પ્રમાણમાં છે, પાછલા જોડાણ કેટલું આગળ વધ્યું તેના પ્રમાણમાં નહીં. જો પ્રાપ્તકર્તાએ કંઈ રાખ્યું ન હોય, તો આગલો પ્રયાસ પૂરી નકલ છે, પહેલાએ કેટલા ગીગાબાઇટ ખસેડ્યા તે ગમે તે હોય.

પુનઃઉપયોગી ટુકડો ક્યાં રહે છે તે નક્કી કરો

મૂળભૂત વર્તન આંશિક ફાઇલને ગંતવ્ય પથ પર લખે છે, જે અડધી લખાયેલી આર્કાઇવને અંતિમ નામ હેઠળ દેખાય તેમ કરે છે. --partial-dir તેને તમારી પસંદગીની ડિરેક્ટરીમાં ખસેડે છે, અને માર્ગદર્શિકા તે ડિરેક્ટરીને પછીના સ્થાનાંતરણ દ્વારા ડેટા તરીકે વાપરવા માટે રાખેલી ગણાવે છે. સાપેક્ષ નામ ગંતવ્ય ડિરેક્ટરી હેઠળ ઉકેલાય છે, જે તમે ત્યારે ઇચ્છો છો જ્યારે બંને છેડાની ગોઠવણી અલગ હોઈ શકે.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

ગંતવ્ય પર પણ ક્રમ મહત્વનો છે: આંશિક ડિરેક્ટરીને ટુકડા માટે પૂરતી જગ્યા જોઈએ, અને વોલ્યુમને પૂર્ણ ફાઇલ માટે પણ પૂરતી જગ્યા જોઈએ. સ્થાનાંતરણની વચ્ચે લક્ષ્ય વોલ્યુમ ભરાઈ જવાથી નિષ્ફળતા થાય છે જે નેટવર્ક સમસ્યા જેવી લાગે છે પણ છે નહીં, અને રાખેલો ટુકડો કપાયેલો રહી શકે છે. ચલાવવાનું શરૂ થાય તે પહેલાં પ્રાપ્ત કરતા હોસ્ટ પર ખાલી જગ્યા તપાસો, નિષ્ફળ થયા પછી નહીં. એ જ SSH પથ પર df -h સાથે થોડી સેકન્ડ યોજનાની સૌથી સસ્તી શક્ય કસોટી છે.

પરવાનગીઓ નાની પણ વાસ્તવિક ચિંતા છે. અસંબંધિત ખાતાં લખી શકે એવી આંશિક ડિરેક્ટરી બીજા કોઈને એવી સામગ્રી બદલવા દે છે જેને તમારી આગલી વાર પહેલેથી મળેલી ગણશે. તેને સ્થાનાંતરણ ખાતાની માલિકીમાં રાખો, અને જ્યાંથી બીજી સેવાઓ પ્રકાશિત કરે છે ત્યાં ન મૂકો.

એ જ નકલ ચલાવો, વધુ ચાલાક નહીં

પુનઃઉપયોગ ફક્ત ત્યારે જ લાગુ પડે છે જ્યારે સ્રોત અને ગંતવ્ય હજી એ જ વસ્તુ વર્ણવે. એ જ પથ, એ જ નામ, એ જ ફાઇલ. સ્રોતનું નામ બદલવું કે બીજી ગંતવ્ય ડિરેક્ટરી તરફ ઈશારો કરવો કંઈ કામના ન હોય તેની સાથે નવી સરખામણી શરૂ કરે છે.

ડેલ્ટા વર્તનની આશા રાખતી વખતે --whole-file ઉમેરશો નહીં. એ વિકલ્પ rsyncને રોલિંગ-ચેકસમ સરખામણી વગર આખી ફાઇલ નકલ કરવાનું કહે છે, જે ઝડપી સ્થાનિક કડી પર વ્યાજબી પસંદગી છે અને નિષ્ફળ લાંબા અંતરના અપલોડ પછી બરાબર ખોટી. --inplace પણ વાર્તા બદલે છે: તે સીધું ગંતવ્ય ફાઇલમાં લખે છે, તેથી વિક્ષેપ જૂની અને નવી સામગ્રી ભેળવતી ફાઇલ છોડે છે, પાછા ફરવા માટે અલગ ટુકડો રહેતો નથી.

પ્રગતિ લીટી સ્થાનાંતરણની એકંદર પ્રગતિ જણાવે છે. તે પૂર્ણતાનો સંકેત નથી. જોડાણ હજી ખુલ્લું હોય ત્યારે સો ટકા સુધી પહોંચેલો આંકડો એટલો જ અર્થ ધરે છે કે માહિતી ધકેલાઈ ગઈ છે, એ નહીં કે પ્રાપ્તકર્તાએ કંઈ નામ બદલ્યું, સમન્વય કર્યું કે સ્વીકાર્યું છે.

વસ્તુ મળી ગયા પછી જ સ્વીકારો

પહેલાં નિકાસ સ્થિતિ ખાતરી કરો, પછી ભૂલોની ગેરહાજરી પર ભરોસો રાખવાને બદલે પરિણામ સરખાવો. કદની ચકાસણી મોટાભાગનાં કપાયેલાં સ્થાનાંતરણ પકડે છે; ચેકસમ સરખામણી બાકીનાં પકડે છે, અને અપલોડ ફરી ચલાવવાની સરખામણીમાં બંને સસ્તાં છે.

જો આર્કાઇવ નીચેની પ્રક્રિયા દ્વારા પ્રકાશિત થાય, તો એ પ્રક્રિયાને સ્વીકૃત ફાઇલની રાહ જોવા દો. અંતિમ નામ હેઠળ દેખરેખવાળી ડિરેક્ટરીમાં પડતો રાખેલો ટુકડો આગલા સ્કેન દ્વારા ઉપાડાય છે, અને ઉપભોક્તાની ભૂલ ભ્રષ્ટ ઇનપુટ વિશે હશે, કદી પૂરું ન થયેલા સ્થાનાંતરણ વિશે નહીં.

પ્રાપ્તકર્તા ખાતરી આપે ત્યાં સુધી સ્રોતને અડશો નહીં. પ્રયાસો વચ્ચે આર્કાઇવ ફરી બનાવવાથી સરખામણીનો આધાર બદલાય છે, અને આગલી વાર ક્યાં તો લગભગ બધું જ સ્થાનાંતરિત કરે છે અથવા એવી ફાઇલ બનાવે છે જે ન જૂના ન નવા સ્રોત સાથે મળે.

જ્યારે મર્યાદા કડી છે, ફ્લેગ નહીં

હેડર અને પ્રોટોકોલનો વધારાનો ખર્ચ સ્થાનાંતરણનો એક ખર્ચ છે, અને મોટી ફાઇલ કેટલો સમય લે તે નક્કી કરે તે ભાગ્યે જ એ હોય છે. ફરી શરૂ કરવાનું વર્તન વધુ મહત્વનું છે: જે પદ્ધતિ હાથે કોઈ પગલાં વગર વિક્ષેપમાંથી પસાર થાય છે તે ફરી શરૂ કરવી પડતી ઝડપી પદ્ધતિ કરતાં વહેલી વાપરી શકાય એવી ફાઇલ આપે છે. બંને છેડે સંગ્રહ અને પ્રમાણીકરણનો પથ એ જ સરખામણીમાં આવે છે.

માન્ય વૈકલ્પિક પથને એ જ ફાઇલ અને એ જ ગંતવ્ય સાથે સરખાવો, અને વિક્ષેપ પછી દરેક ક્યાંથી ફરી શરૂ થાય તે નોંધો. એ એક જ કૉલમ VPN પર બાર ગીગાબાઇટના અપલોડ વિશે ટૂંકી કસોટીમાં માપેલી કોઈ પણ ટોચની ઝડપ કરતાં વધુ કહે છે.