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 വഴിയുള്ള പന്ത്രണ്ട് ഗിഗാബൈറ്റ് അപ്ലോഡിനെക്കുറിച്ച് ചെറിയ പരിശോധനയിൽ അളന്ന ഏത് ഉയർന്ന വേഗതയെക്കാളും കൂടുതൽ പറയുന്നു.