SSH വഴി rsync കമാൻഡ് ഉപയോഗിച്ച് രണ്ട് സെർവറുകൾക്കിടയിൽ വലിയ ഫയലുകൾ വേഗത്തിൽ മാറ്റം ചെയ്യുക

SSH വഴി rsync കമാൻഡ്, രണ്ട് സെർവറുകൾക്കിടയിൽ വലിയ ഫയലുകൾ വേഗത്തിലും സുരക്ഷിതമായി, ഇടവേളകളില്ലാതെ മാറ്റം നടത്താൻ ഉപയോഗിക്കുന്ന ലിനക്സിലെ ഏറ്റവും പ്രായോഗികമായ മാർഗങ്ങളിൽ ഒന്നാണ്. പ്രത്യേകിച്ച് നൂറുകണക്കിന് ജിബിബി വലുപ്പമുള്ള വെബ്‌സൈറ്റ് ഫയലുകൾ, ബാക്കപ്പ് ആർക്കൈവ്‌സ്, മീഡിയ ഫോളഡറുകൾ അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ ഡാറ്റകൾ മാറ്റുമ്പോൾ rsync വെറും മാറ്റപ്പെട്ട ഭാഗങ്ങൾ മാത്രമേ അയയ്ക്കുകയുള്ളൂ എന്നതിനാൽ പാരമ്പര്യ കോപ്പി രീതികളേക്കാൾ ഗണ്യമായ വേഗത നൽകുന്നു. അടിസ്ഥാന ആശയം ഇതാണ്: സ്രോതസ്സ് സെർവറിലെ ഫയലുകൾ SSH ടണൽ വഴി ലക്ഷ്യ സെർവറിലേക്ക് എൻക്രിപ്റ്റ് ചെയ്ത് സിങ്ക് ചെയ്യുന്നു; കണക്ഷൻ വിച്ഛേദിച്ചാൽ പ്രവർത്തനം അവിടെ നിന്നു തുടരാം.

സെർവർ മാറ്റം, ഹോസ്റ്റിംഗ് അപ്ഗ്രേഡ്, ഡാറ്റ സെന്റർ മാറ്റം അല്ലെങ്കിൽ ബാക്കപ്പ് പ്രവർത്തനങ്ങളിൽ വേഗത മാത്രമല്ല, ഡാറ്റയുടെ സമഗ്രതയും അത്യന്താപേക്ഷിതമാണ്. വലിയ ഒരു ആർക്കൈവ് ഒറ്റ തവണ ഡൗൺലോഡ് ചെയ്ത് വീണ്ടും അപ്‌ലോഡ് ചെയ്യുന്നത് നേരം നഷ്ടപ്പെടുത്തുന്നതോടൊപ്പം കണക്ഷൻ പാളിയാൽ തുടക്കം മുതൽ ആവർത്തിക്കേണ്ടിവരും. rsync ഈ സാഹചര്യത്തിൽ ഫയലുകളുടെ ടൈംസ്റ്റാമ്പുകൾ, അനുമതികൾ, ഉടമസ്ഥാവകാശ വിവരങ്ങൾ, ഫോളഡർ ഘടന എന്നിവ സംരക്ഷിക്കാം. അതുകൊണ്ട് Linux സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ, DevOps ടീമുകൾ, വെബ് ഹോസ്റ്റിംഗ് വിദഗ്ധർ ഇതിനെ ദിവസംപ്രതി പ്രവർത്തനങ്ങളിൽ വ്യാപകമായി ഉപയോഗിക്കുന്നു.

ഈ ഗൈഡിൽ രണ്ട് Linux സെർവറുകൾക്കിടയിൽ SSH വഴി rsync ഉപയോഗിച്ച് വലിയ ഫയലുകൾ മാറ്റം ചെയ്യുന്നതിന്റെ ദിശാനിർദ്ദേശവും, യഥാർത്ഥ കമാൻഡ് ഉദാഹരണങ്ങളോടുകൂടി ഘട്ടം ഘട്ടമായി വിശദീകരിക്കും. കൂടാതെ പെർഫോമൻസ് മെച്ചപ്പെടുത്താനുള്ള പാരാമീറ്ററുകൾ, സുരക്ഷാ പരിശോധനകൾ, പിഴവുകൾ സംഭവിച്ചാൽ എങ്ങനെ കൈകാര്യം ചെയ്യാം, ടെസ്റ്റ് ട്രാൻസ്ഫർ മാർഗങ്ങൾ, പ്രൊഡക്ഷൻ എന്വയോൺമെന്റിലേക്ക് മാറുന്നതിന് മുൻപ് ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ എന്നിവ പങ്കുവെക്കുന്നു. പുതിയ VPS അല്ലെങ്കിൽ ഹോസ്റ്റിംഗ് എന്വയോൺമെന്റിലേക്ക് മാറാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, സ്രോതസ്സ്, ലക്ഷ്യ സെർവറുകളിൽ മതിയായ ഡിസ്ക് സ്പേസ്, SSH ആക്സസ്, ശരിയായ യൂസർ അനുമതികൾ ഉറപ്പുവരുത്തുക. അനുയോജ്യമായ ഇൻഫ്രാസ്ട്രക്ചർ തിരഞ്ഞെടുക്കാൻ Hostragons VPS സർവർ പരിഹാരങ്ങൾയും ലിനക്സ് ഹോസ്റ്റിംഗ് പാക്കേജുകൾയും പരിശോധിക്കാം.

rsync എന്താണ്, വലിയ ഫയലുകൾ മാറ്റുമ്പോൾ ഇതെന്തുകൊണ്ട് പ്രിയങ്കരമാണ്?

rsync ഒരു ശക്തമായ കമാൻഡ് ലൈൻ ഉപകരണമാണ്, ഫയലുകളും ഡയറക്ടറികളും ലോക്കൽ സിസ്റ്റത്തിലോ ദൂര സെർവറുകളിലോ സിങ്ക് ചെയ്യാൻ ഉപയോഗിക്കുന്നു. ഇതിന്റെ പ്രധാന ഫീച്ചർ ഡെൽറ്റ ട്രാൻസ്ഫർ ആൽഗോരിത്തമാണ്. ഇത് ഫയലിന്റെ മുഴുവൻ ഭാഗം വീണ്ടും അയക്കുന്നത് ഒഴിവാക്കി, മാറ്റപ്പെട്ട ഭാഗങ്ങൾ മാത്രം അയയ്ക്കുന്നു. ഉദാഹരണത്തിന്, 80 GB വലിപ്പമുള്ള ഒരു ബാക്കപ്പ് ഫയലിൽ 2 GB മാത്രമേ മാറ്റപ്പെട്ടിട്ടുള്ളൂ എങ്കിൽ, പൂർണ്ണ ഫയൽ പുനഃസ്ഥാപിക്കുന്നതിനുപകരം മാറ്റപ്പെട്ട ബ്ലോക്കുകൾ മാത്രമേ അയക്കൂ.

SSH കണക്ഷൻ ഡാറ്റ ട്രാൻസ്ഫർ എൻക്രിപ്റ്റ് ചെയ്യുന്നു. അതിനാൽ rsync കമാൻഡ് നെറ്റ്‌വർക്ക് വഴി ഡാറ്റ അയയ്ക്കുമ്പോൾ ഫയൽ ഉള്ളടക്കം പ്ലെയിൻ ടെക്സ്റ്റായി കൈമാറുന്നില്ല. ഇത് പ്രത്യേകിച്ച് ഉപഭോക്തൃ ഡാറ്റ, ഇ-കൊമേഴ്സ് ഓർഡർ റെക്കോർഡുകൾ, മീഡിയ ആർക്കൈവ്, ഡാറ്റാബേസ് ബാക്കപ്പുകൾ, സ്വകാര്യ ആപ്ലിക്കേഷൻ ഫയലുകൾ എന്നിവയ്ക്കും അനിവാര്യമാണ്. ഹോസ്റ്റിംഗ് ലോകത്ത് ഡാറ്റ സുരക്ഷ SSL സർട്ടിഫിക്കറ്റിലേക്കു മാത്രം പരിമിതപ്പെടുത്തിയതല്ല; സെർവർകൾക്കിടയിലെ ഡാറ്റ ട്രാൻസ്ഫർ ചാനലും സുരക്ഷിതമായിരിക്കണം. വെബ് ട്രാഫിക്കിനായി SSL സർട്ടിഫിക്കറ്റ് ഉപയോഗിക്കുന്നതു പോലെ സെർവർ ഇടം ഫയൽ ട്രാൻസ്ഫറിനും SSH എൻക്രിപ്ഷൻ നിർബന്ധമാണ്.

rsync, FTP അല്ലെങ്കിൽ മാനുവൽ ഡൗൺലോഡ്-അപ്‌ലോഡ് രീതികളേക്കാൾ കൂടുതൽ ഫ്ലെക്സിബിളാണ്. ഇത് അനുമതികൾ സംരക്ഷിക്കാം, സിംബോളിക് ലിങ്കുകൾ കൈമാറാം, ഡിലീറ്റ് ചെയ്ത ഫയലുകൾ ലക്ഷ്യത്തിൽ നിന്നും നീക്കം ചെയ്യാം, ബാൻഡ്‌വിഡ്ത്ത് നിയന്ത്രിക്കാം, ട്രാൻസ്ഫർ മുമ്പ് ടെസ്റ്റ് നടത്താം. വലിയ ഫയൽ മാറ്റം പോലുള്ള അപകടസാധ്യതയുള്ള പ്രവർത്തനങ്ങളിൽ ഈ നിയന്ത്രണങ്ങൾ വലിയ ഗുണം നൽകുന്നു.

എപ്പോഴാണ് SSH വഴി rsync കമാൻഡ് ഉപയോഗിക്കേണ്ടത്?

SSH വഴി rsync കമാൻഡ് പ്രത്യേകിച്ച് വലിയ, അനേകം അല്ലെങ്കിൽ സ്ഥിരമായി മാറുന്ന ഫയലുകൾ മാറ്റുമ്പോൾ അനുയോജ്യമാണ്. ലളിതമായ ഒരു ഇമേജ് ഫോളഡറിന് മാനുവൽ SFTP മതിയാകാം; പക്ഷേ ആയിരക്കണക്കിന് ഫയലുകൾ, വ്യത്യസ്ത അനുമതികൾ, വലിയ ആർക്കൈവുകൾ വേണമെങ്കിൽ rsync വളരെ വിശ്വസനീയമായൊരു മാർഗമാണ്.

• പഴയ സെർവറിൽ നിന്നു പുതിയ VPS സെർവറിലേക്ക് വെബ്‌സൈറ്റ് മാറ്റുമ്പോൾ.
• WordPress അപ്‌ലോഡുകൾ പോലുള്ള ആയിരക്കണക്കിന് മീഡിയ ഫയലുകൾ ഉള്ള ഫയൽസിസ്റ്റം മാറ്റുമ്പോൾ.
• ദിവസേന, ആഴ്ച, മാസ ബാക്കപ്പുകൾ മറ്റൊരു സെർവറിലേക്ക് പകർത്തുമ്പോൾ.
• ഡാറ്റ സെന്റർ അല്ലെങ്കിൽ ഹോസ്റ്റിംഗ് പ്രൊവൈഡർ മാറ്റുമ്പോൾ.
• ആപ്ലിക്കേഷൻ ഫയലുകൾ പ്രൊഡക്ഷനും ബാക്കപ്പിനും ഇടയിൽ സിങ്ക് ചെയ്യുമ്പോൾ.
• കണക്ഷൻ വിച്ഛേദിക്കപ്പെടാനുള്ള സാധ്യതയുള്ള ദീർഘകാല ട്രാൻസ്ഫറുകൾ പ്ലാൻ ചെയ്തപ്പോൾ.

ഉദാഹരണത്തിന് 250 GB വലിപ്പമുള്ള ഒരു മീഡിയ ഫോളഡർ നിങ്ങളുടെ ഡെസ്ക്ടോപ്പിലേക്ക് ഡൗൺലോഡ് ചെയ്ത് ശേഷം പുതിയ സെർവറിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നത് രണ്ട് തവണ ട്രാൻസ്ഫർ ചെയ്യേണ്ടതാണെന്ന് അർത്ഥം. ഇത് മൊത്തം സമയം ഉയർത്തും കൂടാതെ നിങ്ങളുടെ വീട്ടിലെ അല്ലെങ്കിൽ ഓഫീസിലെ ഇന്റർനെറ്റ് കണക്ഷൻ ബോട്ടിൽനെക്ക് സൃഷ്ടിക്കും. rsync ഉപയോഗിച്ച് സ്രോതസ്സ് സെർവറിൽ നിന്നു ലക്ഷ്യ സെർവറിലേക്ക് നേരിട്ട് ഫയലുകൾ മാറ്റി ഇടവേള ഒഴിവാക്കാം.

ആരംഭിക്കുന്നതിന് മുൻപ് വേണ്ട കാര്യങ്ങൾ

rsync പ്രവർത്തനം വിജയകരമായി നടത്താൻ കമാൻഡ് അറിയുന്നത് മാത്രം മതിയല്ല. സ്രോതസ്സ്, ലക്ഷ്യ സെർവറുകളുടെ അവസ്ഥ പരിശോധിച്ച് ട്രാൻസ്ഫർ സമയത്ത് സംഭവിക്കാവുന്ന ഡാറ്റ നഷ്ടം അല്ലെങ്കിൽ പൂർണ്ണമായില്ലാത്ത മാറ്റം തടയണം. താഴെ കൊടുത്തിരിക്കുന്ന പരിശോധനകൾ പ്രൊഡക്ഷൻ പരിസരങ്ങളിൽ നിർബന്ധമാണ്.

1. SSH ആക്സസ് സ്ഥിരീകരിക്കുക

സ്രോതസ്സ് സെർവറിൽ നിന്നു ലക്ഷ്യ സെർവറിലേക്ക് SSH കണക്ഷൻ സാധ്യമാകണം. സാധാരണ കണക്ഷൻ ഇങ്ങനെ പരിശോധിക്കും: ssh upayogikkan@lakshya-server-ip. SSH വേറെ പോർട്ടിൽ പ്രവർത്തിക്കുന്നുവെങ്കിൽ കണക്ഷൻ ഇങ്ങനെ പരീക്ഷിക്കുക: ssh -p 2222 upayogikkan@lakshya-server-ip. ഈ ടെസ്റ്റ് പരാജയപ്പെട്ടാൽ rsync പ്രവർത്തിക്കില്ല. ഫയർവാൾ, Fail2ban, SSH പോർട്ട്, യൂസർ അവകാശങ്ങൾ, പാസ്‌വേഡ് അല്ലെങ്കിൽ കീ വെരിഫിക്കേഷൻ പരിശോധിക്കണം.

2. rsync പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക

ബഹുഭൂരിപക്ഷം Linux ഡിസ്‌ട്രിബ്യൂഷനുകളിൽ rsync ഡിഫോൾട്ട് ആയി ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നു; എന്നിരുന്നാലും പരിശോധിക്കുക. Debian, Ubuntu പോലുള്ള സിസ്റ്റങ്ങളിൽ rsync --version കമാൻഡ് ഉപയോഗിച്ച് പരിശോധിക്കാം. ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ലെങ്കിൽ apt install rsync കമാൻഡ് ഉപയോഗിച്ച് ഇൻസ്റ്റാൾ ചെയ്യാം. AlmaLinux, Rocky Linux, CentOS പോലുള്ള ഡിസ്‌ട്രിബ്യൂഷനിൽ dnf install rsync അല്ലെങ്കിൽ yum install rsync ഉപയോഗിക്കുക. Hostragons ലിനക്സിൽ VPS ഉപയോഗിക്കുന്നവർക്ക് ഇൻസ്റ്റലേഷൻ വളരെ വേഗത്തിലാണ്.

3. ഡിസ്ക് സ്പേസ് കണക്കാക്കുക

ലക്ഷ്യ സെർവറിൽ മതിയായ ഫ്രീ സ്പേസ് ഇല്ലെങ്കിൽ ട്രാൻസ്ഫർ ഇടവേളയിൽ നിർത്തും. സ്രോതസ്സ് ഡയറക്ടറിയുടെ വലിപ്പം കാണാൻ du -sh /source/directory ഉപയോഗിക്കുക. ലക്ഷ്യത്തിൽ df -h കമാൻഡ് ഉപയോഗിച്ച് ഡിസ്ക് സ്ഥിതി പരിശോധിക്കുക. പ്രായോഗികമായി ഫയൽ വലിപ്പത്തിന് മാത്രം അല്ല, താത്കാലിക ഫയലുകൾക്കും ലോഗുകൾക്കും ഇടം വിട്ടുകൊടുക്കണം. ഉദാഹരണത്തിന് 500 GB ഡാറ്റ മാറ്റുകയാണെങ്കിൽ ലക്ഷ്യത്തിൽ കുറഞ്ഞത് 550-600 GB ഫ്രീ സ്പേസുണ്ടാകണം.

4. ക്രിറ്റിക്കൽ സർവീസുകളും മാറ്റം വരുത്തുന്ന ഫയലുകളും പ്ലാൻ ചെയ്യുക

ലൈവ് വെബ്‌സൈറ്റുകളിൽ ഫയലുകൾ ട്രാൻസ്ഫർ സമയത്ത് മാറാം. പ്രത്യേകിച്ച് യൂസർ അപ്‌ലോഡുകൾ, കാഷെ ഫോളഡറുകൾ, ലോഗ് ഫയലുകൾ സ്ഥിരമായി അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്നു. വലിയ മാറ്റങ്ങളിൽ ആദ്യം പ്രധാന ഡാറ്റ മാറ്റി, പിന്നീട് സൈറ്റ് മെയിൻടനൻസ് മോഡിൽ വെച്ച് അവസാന rsync ഓടിക്കുന്നു. ഇതിലൂടെ ഡൗൺടൈം കുറയ്ക്കാം. WordPress സൈറ്റുകൾക്ക് WordPress ഹോസ്റ്റിങ്ങ് മാറ്റൽ മാർഗ്ഗനിർദ്ദേശം പോലുള്ള സഹായക ലേഖനങ്ങൾ ഉപയോഗിച്ച് പദ്ധതി തയ്യാറാക്കാം.

അടിസ്ഥാന rsync കമാൻഡ്: രണ്ട് സെർവറുകൾക്കിടയിൽ ഫയലുകൾ മാറ്റം ചെയ്യുക

ഏറ്റവും സാധാരണമായി ഉപയോഗിക്കുന്ന കമാൻഡ് രൂപം: rsync -avz /source/directory/ user@target-ip:/target/directory/. ഇവിടെ -a ആർക്കൈവ് മോഡാണ്, ഇത് അനുമതികൾ, ടൈംസ്റ്റാമ്പുകൾ, സിംബോളിക് ലിങ്കുകൾ തുടങ്ങിയവ സംരക്ഷിക്കുന്നു. -v വിശദമായ ഔട്ട്പുട്ട് നൽകുന്നു. -z ട്രാൻസ്ഫർ സമയത്ത് കംപ്രഷൻ പ്രയോഗിക്കുന്നു. ഡയരക്ടറിയുടെ അവസാനം സ്ലാഷ് പ്രധാനമാണ്. /source/directory/ എന്നത് ആ ഡയറക്ടറിയുടെ ഉള്ളടക്കം ലക്ഷ്യത്തിലേക്ക് കോപ്പി ചെയ്യും; /source/directory എന്ന് സ്ലാഷ് ഇല്ലാതെ എഴുതിയാൽ ആ ഡയറക്ടറിയും ലക്ഷ്യത്തിൽ ഉണ്ടാകും.

ഉദാഹരണത്തിന്: പഴയ സെർവറിൽ /var/www/site/public_html/ എന്ന 180 GB വെബ് ഫയലുകൾ പുതിയ സെർവറിലെ അതേ പാതയിലേക്ക് മാറ്റാൻ: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. ഇത് SSH വഴി സ്രോതസ്സ് സെർവറിൽ നിന്ന് ലക്ഷ്യ സെർവറിലേക്ക് ഫയലുകൾ മാറ്റും.

root ആയി കമാൻഡ് ഓടിക്കാൻ ആഗ്രഹിക്കാത്ത പക്ഷം, ലക്ഷ്യ സെർവറിൽ യഥാർത്ഥ ഡയറക്ടറിയിൽ എഴുതാനുള്ള അനുമതിയുള്ള ഒരു ഉപയോക്താവിനെ സൃഷ്‌ടിക്കുക. ഉദാഹരണത്തിന് deploy എന്ന യൂസർ. തുടർന്ന് ഫയൽ ഉടമസ്ഥാവകാശം ശരിയാക്കുക. പ്രൊഡക്ഷൻ പരിസരങ്ങളിൽ നേരിട്ട് root ഉപയോഗിക്കുന്നത് എളുപ്പമാണ്, പക്ഷേ സുരക്ഷാ കാരണങ്ങളാൽ നിയന്ത്രിത അധികാരം ഉള്ള യൂസർ ഉപയോഗിക്കുന്നത് ശുപാർശ ചെയ്യപ്പെടുന്നു.

സുരക്ഷിതവും സ്ഥിരവുമായ rsync പാരാമീറ്ററുകൾ

വലിയ ഫയലുകൾ മാറ്റുമ്പോൾ അടിസ്ഥാന കമാൻഡ് മാത്രം ഉപയോഗിക്കുന്നത് പര്യാപ്തമല്ല. കണക്ഷൻ വിച്ഛേദിക്കൽ, പൂർണ്ണമല്ലാത്ത ഫയലുകൾ, തെറ്റായ ഡിലീറ്റ് പ്രവർത്തനങ്ങൾ, നെറ്റ്‌വർക്ക് സ്ലോവു എന്നിവയ്ക്ക് എതിരായ നിയന്ത്രണങ്ങൾ ആവശ്യമാണ്. താഴെ കൊടുത്ത കമാൻഡ് പല യാഥാർത്ഥ്യ ട്രാൻസ്ഫർ സാഹചര്യങ്ങൾക്കായി വിശ്വസനീയമായ തുടക്കമാണ്:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /source/directory/ user@target-ip:/target/directory/

ഇവിടെ -a ആർക്കൈവ് മോഡും, -H ഹാർഡ് ലിങ്കുകൾ സംരക്ഷിക്കലും, -A ACL അനുമതികളും, -X എക്സ്റ്റെൻഡഡ് ആട്രിബ്യൂട്ടുകളും സംരക്ഷിക്കുന്നതും ഉൾപ്പെടുന്നു. --numeric-ids യൂസർ, ഗ്രൂപ്പ് നാമങ്ങൾക്കായി ഐഡി നമ്പറുകൾ ഉപയോഗിക്കുന്നു; വ്യത്യസ്ത സെർവറുകളിൽ യൂസർ നാമം മാറിയാലും പ്രശ്നമില്ല. --partial പൂർണ്ണമല്ലാത്ത ഫയലുകൾ നീക്കം ചെയ്യാതെ വയ്ക്കും. --progress ട്രാൻസ്ഫർ പുരോഗതി കാണിക്കും. --append-verify വലിയ ഫയലുകളിൽ ഇടവേളയിൽ നിന്ന് തുടർച്ചയായ പരിശോധനയും ഉറപ്പും നൽകുന്നു.

ഓരോ പാരാമീറ്ററും എല്ലാ സാഹചര്യങ്ങളിലും ആവശ്യമാണ് എന്ന് പറയാനാവില്ല. ലളിതമായ വെബ്‌സൈറ്റ് മാറ്റത്തിൽ -aHAX മതിയാകാം; പ്രത്യേക അനുമതികളുള്ള ആപ്ലിക്കേഷൻ ഫയലുകളിൽ ACL, എക്സ്റ്റെൻഡഡ് ആട്രിബ്യൂട്ട് ആവശ്യമാണ്. അതിനാൽ ആദ്യം ടെസ്റ്റ് ട്രാൻസ്ഫർ നടത്തുന്നത് നിർബന്ധമാണ്.

ഭിന്ന SSH പോർട്ട് ഉപയോഗിക്കുന്നുവെങ്കിൽ കമാൻഡ് എങ്ങനെ എഴുതണം?

സുരക്ഷാ കാരണങ്ങൾ കൊണ്ട് SSH പോർട്ട് 22 അല്ലാതെ വേറെ പോർട്ട് ഉപയോഗിക്കുന്നുണ്ടാകാം. അപ്പോഴിതിന് rsync-ൽ SSH ഓപ്ഷൻ നൽകണം. ഉദാഹരണത്തിന്: rsync -avz -e ssh -p 2222 /source/directory/ user@target-ip:/target/directory/. എന്നാൽ കമാൻഡ് ലൈൻിൽ -e ഓപ്ഷന്റെ മൂല്യം കൂടെ പറയണം. ശരിയായ രൂപം: rsync -avz -e 'ssh -p 2222' /source/directory/ user@target-ip:/target/directory/.

JSON അല്ലെങ്കിൽ ചില പ്ലാറ്റ്‌ഫോമുകളിൽ സിംഗിൾ ക്വോട്ടുകൾ വ്യത്യസ്തമായി പ്രവർത്തിക്കാം. ടർമിനലിൽ നേരിട്ട് എഴുതുമ്പോൾ ക്വോട്ടുകൾ ശരിയാണെന്ന് ഉറപ്പാക്കുക. SSH കീ ഉപയോഗിച്ച് കണക്റ്റ് ചെയ്യുമ്പോൾ -i ഓപ്ഷൻ കൂടി ചേർക്കാം: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/directory/ user@target-ip:/target/directory/. ഓട്ടോമേഷൻ, ക്രോൺ ബേസ്ഡ് ബാക്കപ്പുകൾക്കായി ഇത് പ്രയോജനപ്പെടും.

ട്രാൻസ്ഫർ മുൻപ് ടെസ്റ്റ്: --dry-run ഉപയോഗം

വലിയ ഡാറ്റ മാറ്റം ആരംഭിക്കുന്നതിന് മുൻപ് ഏറ്റവും പ്രൊഫഷണൽ മാർഗ്ഗങ്ങളിൽ ഒന്ന് --dry-run ഉപയോഗിക്കുകയാണ്. ഇത് ഫയലുകൾ യഥാർത്ഥത്തിൽ കോപ്പി ചെയ്യാതെ, മാറ്റം നടത്തേണ്ട ഫയലുകൾ മാത്രം കാണിക്കുന്നു. തെറ്റായ ഡയറക്ടറി, അസാധുവായ ലക്ഷ്യ പാത, അനുകൂലമല്ലാത്ത ഡിലീറ്റ് പ്രവർത്തനങ്ങൾ മുതലായവ മുൻകൂട്ടി കണ്ടെത്താൻ ഇത് സഹായിക്കും.

ഉദാഹരണത്തിന്: rsync -avz --dry-run /var/www/site/ user@target-ip:/var/www/site/. ഇതിൽ മാറ്റം ചെയ്യേണ്ട ഫയലുകൾ, സൃഷ്ടിക്കേണ്ട ഡയറക്ടറികൾ, പ്രവർത്തനത്തിന്റെ സംക്ഷിപ്തം കാണാം. --delete ഉപയോഗിക്കുന്നുവെങ്കിൽ dry-run വളരെ നിർണായകമാണ്. കാരണം --delete സ്രോതസ്സിൽ ഇല്ലാത്ത ഫയലുകൾ ലക്ഷ്യത്തിൽ നിന്നും നീക്കം ചെയ്യുന്നു. ശരിയായി ഉപയോഗിച്ചാൽ ലക്ഷ്യം സ്രോതസ്സ് പോലെ തന്നെ കാണും; തെറ്റായ സ്ഥലത്ത് ഉപയോഗിച്ചാൽ വലിയ ഡാറ്റ നഷ്ടം ഉണ്ടാക്കും.

പ്രൊഫഷണൽ പ്രവർത്തനക്രമം സാധാരണയായി ഇങ്ങനെ: ആദ്യം SSH ടെസ്റ്റ്, പിന്നീട് ഡിസ്ക് സ്പേസ് പരിശോധന, പിന്നെ rsync --dry-run, ചെറുതായൊരു ഡയറക്ടറിയിൽ യഥാർത്ഥ ടെസ്റ്റ്, പിന്നീട് പ്രധാന ട്രാൻസ്ഫർ. ഇത് കുറച്ച് മിനിറ്റുകൾ അധികം എടുക്കാം, പക്ഷേ മണിക്കൂറുകൾക്കു നീണ്ട പിഴവുകൾ ഒഴിവാക്കും.

പെർഫോമൻസ്: കംപ്രഷൻ, ബാൻഡ്‌വിഡ്ത് നിയന്ത്രണം, എൻക്രിപ്ഷൻ ക്രമീകരണങ്ങൾ

rsync-ന്റെ പെർഫോമൻസ് ഫയൽ വലുപ്പത്തിൽ മാത്രമല്ല; സെർവറുകളുടെ CPU, ഡിസ്ക് തരം, നെറ്റ്‌വർക്ക് ഡീലേ, ബാൻഡ്‌വിഡ്ത്, ഫയലുകളുടെ എണ്ണം എന്നിവയും പ്രധാനമാണ്. ചെറിയ ഫയലുകൾ അനേകം ഉണ്ടെങ്കിൽ, metadata പ്രോസസ്സിങ് കാരണം വലിയ ഫയലേക്കാൾ മന്ദഗതിയാകും. NVMe ഡിസ്കുള്ള VPS-യിൽ ഫയൽ സ്കാനിംഗ്, എഴുത്ത് കാര്യക്ഷമത ഗണ്യമായി മെച്ചപ്പെടും. അതിനാൽ നീളം കൂടിയ ട്രാൻസ്ഫറുകൾക്ക് NVMe VPS സർവർ പരിഗണിക്കുക നല്ലതാണ്.

-z കംപ്രഷൻ ഓപ്ഷൻ ടെക്സ്റ്റ്, ലോഗ്, ചില ബാക്കപ്പ് ഫയലുകൾക്കായി ഫലപ്രദമാണ്. എന്നാൽ zip, tar.gz, jpg, mp4, gzip പോലുള്ള ഇതിനകം കംപ്രസ് ചെയ്ത ഫയലുകളിൽ CPU അധികമായി ഉപയോഗിച്ച് ഗുണം കുറവാകും. 1 Gbps കണക്ഷനുള്ള ശക്തമായ സെർവറുകൾക്കിടയിൽ വലിയ മീഡിയ ഫയലുകൾ മാറ്റുമ്പോൾ -z ഒഴിവാക്കുന്നത് മെച്ചം. എന്നാൽ കുറവ് ബാൻഡ്‌വിഡ്ത് ഉള്ള ടെക്സ്റ്റ് ഫയലുകളിൽ -z വളരെ സഹായിക്കും.

ബാൻഡ്‌വിഡ്ത് നിയന്ത്രിക്കാൻ --bwlimit ഉപയോഗിക്കാം. ഉദാഹരണത്തിന് --bwlimit=50000 എന്നത് ഏകദേശം 50 MB/s നിരക്ക് സെറ്റ് ചെയ്യുന്നു. ഇത് ലൈവ് വെബ്‌സൈറ്റിന്റെ നെറ്റ്‌വർക്ക് ട്രാഫിക് തടസ്സപ്പെടുത്താതിരിക്കാൻ സഹായിക്കും. പ്രൊഡക്ഷൻ സെർവറിൽ തിരക്കുള്ള സമയത്ത് പൂർണ്ണ വേഗതയിലായുള്ള ട്രാൻസ്ഫർ ഉപഭോക്തൃ അനുഭവം ബാധിക്കാനിടയുണ്ട്. മാറ്റം രാത്രി സമയത്ത് നിശ്ചയിക്കുക, ബാൻഡ്‌വിഡ്ത് പരിധി ഏർപ്പെടുത്തുക, ലോഡ് അവറേജ് നിരീക്ഷിക്കുക നല്ല രീതികളാണ്.

rsync, scp, SFTP, FTP തമ്മിലുള്ള സവിശേഷതകൾ

ഫയൽ മാറ്റത്തിനായി നിരവധി മാർഗ്ഗങ്ങളുണ്ട്; എന്നാൽ ഓരോതിന്റെയും ശക്തിയും ദുർബലതകളും വ്യത്യസ്തമാണ്. താഴെക്കൊടുത്ത പട്ടിക വലിയ ഫയലുകൾ, സെർവർ മാറ്റം എന്നിവയിൽ ഏത് ഉപകരണം എപ്പോൾ ഉചിതമാണെന്ന് സംക്ഷിപ്തമായി കാണിക്കുന്നു.

പട്ടിക കാണിക്കുന്നത് rsync പ്രത്യേകിച്ച് ആവർത്തിക്കുന്ന സിങ്ക്രണൈസേഷനിലും വലുതും സങ്കീർണ്ണവുമായ ഡാറ്റ മാറ്റത്തിലും മുൻപന്തിയിലാണെന്ന്. scp ലളിതവും ഉപയോഗിക്കാൻ എളുപ്പവുമാണ്, എന്നാൽ മാറ്റം വന്ന ഫയലുകൾ തിരിച്ചറിയുന്നതിൽ rsync-നെ അപേക്ഷിച്ച് ശേഷിയില്ല. FTP എൻക്രിപ്ഷൻ ഇല്ലാതെ ഉപയോഗിക്കുന്നത് ആധുനിക സുരക്ഷാ മാനദണ്ഡങ്ങൾക്കനുസരിച്ചല്ല. ഹോസ്റ്റിംഗ് പാനലുകളിൽ FTP പ്രായോഗികമാകാമെങ്കിലും സെർവർ ഇടം നിർണായകമായ മാറ്റങ്ങൾക്ക് SSH അടിസ്ഥാനമായ മാർഗ്ഗങ്ങൾ ഉപയോ​ഗിക്കണം.

ലൈവ് വെബ്‌സൈറ്റ് മാറ്റത്തിനുള്ള ഉദാഹരണ പ്രവൃത്തി പ്രവാഹം

ഒരു വെബ്‌സൈറ്റ് പഴയ സെർവറിൽ നിന്ന് പുതിയ സെർവറിലേക്ക് മാറ്റുമ്പോൾ, ഫയലുകൾ കോപ്പി ചെയ്യുക മാത്രമല്ല ലക്ഷ്യം. DNS, ഡാറ്റാബേസ്, SSL, PHP പതിപ്പ്, ഫയൽ അനുമതികൾ, ഇമെയിൽ കോൺഫിഗറേഷൻ എന്നിവയും പരിശോധിക്കണം. താഴെ വലിയ ഫയലുള്ള വെബ്‌സൈറ്റിനുള്ള കുറഞ്ഞ ഇടവേളയുള്ള ഉദാഹരണ പ്രവൃത്തി ക്രമം കൊടുക്കുന്നു.

• പുതിയ സെർവറിൽ വെബ് സെർവർ, PHP, ഡാറ്റാബേസ്, ആവശ്യമായ മോഡ്യൂളുകൾ ഒരുക്കുക.
• ഡൊമെയ്ൻ DNS TTL മൂല്യം 300 സെക്കൻഡ് പോലുള്ള കുറഞ്ഞതാക്കുക. ഡൊമെയ്ൻ മാനേജ്മെന്റിനായി ഡൊമെയ്ൻ പരിശോധനം و ഡൊമെയ്ൻ നിയന്ത്രണം പരിശോധിക്കുക.
• ആദ്യ rsync ട്രാൻസ്ഫർ സൈറ്റു പ്രവർത്തിക്കുന്നപ്പോൾ ആരംഭിക്കുക. ഇത് വലിയ ഡാറ്റയുടെ ഭൂരിഭാഗവും മാറ്റും.
• ഡാറ്റാബേസ് ബാക്കപ്പ് എടുത്ത് പുതിയ സെർവറിലേക്ക് മാറ്റുക.
• സൈറ്റിനെ താൽക്കാലികമായി മെയിൻടനൻസ് മോഡിലേക്ക് മാറ്റുക.
• രണ്ടാം rsync കമാൻഡ് ഓടിച്ച് മാറ്റപ്പെട്ട ഫയലുകൾ സമന്വയിപ്പിക്കുക.
• ഡാറ്റാബേസ് വീണ്ടും അപ്‌ഡേറ്റ് ചെയ്യുക അല്ലെങ്കിൽ ഇൻക്രീമെന്റൽ ബാക്കപ്പ് ഉപയോഗിക്കുക.
• പുതിയ സെർവറിൽ ഫയൽ അനുമതികൾ, സൈറ്റ് പ്രവർത്തനം, ലോഗുകൾ പരിശോധിക്കുക.
• SSL സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്യുക അല്ലെങ്കിൽ പുതുക്കുക. SSL സർട്ടിഫിക്കറ്റിന്റെ ഇൻസ്റ്റലേഷൻ സഹായകമാണ്.
• DNS റെക്കോർഡുകൾ പുതിയ IP വിലാസത്തിലേക്ക് മാറ്റുക.

ഈ രീതിയിൽ ഏറ്റവും കൂടുതൽ സമയം എടുക്കുന്നത് പ്രധാന ഫയൽ മാറ്റത്താണ്, അത് സൈറ്റ് പ്രവർത്തിക്കുന്ന സമയത്ത് നടക്കുന്നു. ഇടവേളയുള്ളത് അവസാന സിങ്ക്രണൈസേഷനും DNS മാറ്റത്തിനുമാത്രം. വലിയ മീഡിയ ഉള്ള WordPress സൈറ്റുകളിൽ ഇത് മണിക്കൂറുകൾ നീണ്ട ഇടവേള കുറച്ച് മിനിറ്റുകളാക്കി ചുരുക്കും.

ഡാറ്റയുടെ സമഗ്രത പരിശോധിക്കുക

ട്രാൻസ്ഫർ കഴിഞ്ഞപ്പോൾ കമാൻഡ് പൂർത്തിയായതിൽ മാത്രം തൃപ്തരാകരുത്. ഫയൽ എണ്ണം, വലിപ്പം, പ്രധാന ഫയലുകൾ പരിശോധിക്കണം. ലളിതമായി സ്രോതസ്സിലും ലക്ഷ്യത്തിലും du -sh ഉപയോഗിച്ച് ഡയറക്ടറി വലിപ്പങ്ങൾ താരതമ്യം ചെയ്യാം. എന്നാൽ ഫയൽ സിസ്റ്റം ബ്ലോക്ക് വ്യത്യാസങ്ങൾ കാരണം മൂല്യങ്ങൾ കൃത്യമായി ഒന്നുപോലെയായിരിക്കണമെന്നില്ല. കൂടുതൽ വിശദമായ പരിശോധനക്ക് rsync വീണ്ടും അതേ പാരാമീറ്ററുകളിൽ ഓടിക്കാം. പുതിയ ഫയൽ ഒന്നും ട്രാൻസ്ഫർ ചെയ്യേണ്ടതില്ലെങ്കിൽ ഔട്ട്പുട്ട് കുറഞ്ഞിരിക്കും.

ചെക്കുംസം പരിശോധിക്കാൻ rsync -avc --dry-run /source/directory/ user@target-ip:/target/directory/ ഉപയോഗിക്കാം. -c ഫയലുകൾ ടൈംസ്റ്റാമ്പിനും വലിപ്പത്തിനും പുറമെ ചെക്സം ഉപയോഗിച്ച് താരതമ്യം ചെയ്യുന്നു. വളരെ വലുപ്പമുള്ള ഡാറ്റയിൽ CPU, ഡിസ്ക് ലോഡ് ഉണ്ടാക്കാം; അതിനാൽ ശ്രദ്ധിക്കണം. സുപ്രധാന ആർക്കൈവുകൾ, ഡാറ്റാബേസ് ഡംപ് ഫയലുകൾ, ക്ലയന്റ് ഡോക്യുമെന്റുകൾ എന്നിവയ്ക്കു ഈ പരിശോധന സുരക്ഷ ഉറപ്പാക്കും.

വെബ്‌സൈറ്റ് മാറ്റിയാൽ ആപ്ലിക്കേഷൻ ലെവലിലും പരിശോധിക്കുക. ഹോം പേജ്, അഡ്മിൻ പാനൽ, ഇമേജ് അപ്‌ലോഡ്, പേയ്‌മെന്റ് പേജ്, കോൺടാക്റ്റ് ഫോം, എറർ ലോഗുകൾ പരിശോധിക്കുക. ഇ-കൊമേഴ്സ് സൈറ്റുകളിൽ ഫയലുകൾ മാത്രമല്ല, പേയ്‌മെന്റ് ഇന്റഗ്രേഷനുകളും ക്രോൺ ജോബുകളും പുതിയ സെർവറിൽ സജ്ജമാക്കണമാണ്.

സാധാരണ പിഴവുകളും പരിഹാരങ്ങളും

Permission denied പിഴവ്

ഈ പിശക് സാധാരണയായി SSH യൂസർ അനുമതികൾ, ലക്ഷ്യ ഡയറക്ടറി എഴുതാനുള്ള അവകാശം, കീ വെരിഫിക്കേഷൻ തുടങ്ങിയ കാര്യങ്ങളുമായി ബന്ധപ്പെട്ടതാണ്. ആദ്യം ഒരേ യൂസറോടെ സാധാരണ SSH കണക്ഷൻ പരീക്ഷിക്കുക. കണക്ഷൻ സഫലമായാൽ ലക്ഷ്യ ഡയറക്ടറിയിൽ ഫയൽ ഉണ്ടാക്കാൻ ശ്രമിക്കുക. ആവശ്യമെങ്കിൽ chown ഉപയോഗിച്ച് ഉടമസ്ഥാവകാശം അനുയോജ്യമായി മാറ്റുക അല്ലെങ്കിൽ sudo അടിസ്ഥാനമായ ഒരു പ്ലാൻ ആസൂത്രണം ചെയ്യുക.

No space left on device പിശക്

ലക്ഷ്യ സെർവറിൽ മതിയായ ഡിസ്ക് സ്‌പേസ് ഇല്ലാതെ ട്രാൻസ്ഫർ നിർത്തും. df -h ഉപയോഗിച്ച് ഡിസ്ക് പാർട്ടിഷനുകൾ പരിശോധിക്കുക. ചിലപ്പോൾ പ്രധാന ഡിസ്ക് നിറഞ്ഞിട്ടില്ലെങ്കിലും /tmp അല്ലെങ്കിൽ മൗണ്ട് പോയിന്റ് നിറഞ്ഞിരിക്കാം. വലിയ ട്രാൻസ്ഫറുകളിൽ ലോഗ് ഫയലുകൾ, പഴയ ബാക്കപ്പുകൾ, കാഷെ ഫയലുകൾ നീക്കം ചെയ്യാം. സ്ഥിരപരിഹാരമായി ഡിസ്ക് വലുതാക്കി VPS പ്ലാൻ മാറ്റേണ്ടതുണ്ടാവും.

Connection reset അല്ലെങ്കിൽ Broken pipe പിശക്

നീണ്ട ട്രാൻസ്ഫറുകളിൽ നെറ്റ്‌വർക്ക് ഇടവേളകൾ ഉണ്ടായേക്കാം. --partial, --append-verify ഉപയോഗിച്ചാൽ കമാൻഡ് വീണ്ടും ഓടിച്ച് ഇടവേളയിൽ നിന്നു തുടർക്കാം. കൂടാതെ SSH keepalive സെറ്റിംഗുകൾ സഹായിക്കും. ക്ലയന്റ് ഭാഗത്ത് ServerAliveInterval 60 പോലുള്ള ക്രമീകരണം കണക്ഷൻ വിച്ഛേദം കുറയ്ക്കും.

വളരെ മന്ദഗതിയിലുള്ള ട്രാൻസ്ഫർ

മന്ദഗതിക്ക് കാരണം ഫയലുകളുടെ എണ്ണം, ഡിസ്ക് I/O പരിധി, കംപ്രഷൻ ലോഡ്, നെറ്റ്‌വർക്ക് ശേഷി എന്നിവ ആയിരിക്കാം. ചെറിയ ഫയലുകൾ അനേകം ഉണ്ടെങ്കിൽ ആദ്യം tar ആർക്കൈവ് ഉണ്ടാക്കുന്നത് ചിലപ്പോൾ വേഗത കൂട്ടും; എന്നാൽ rsync-യുടെ മാറ്റപ്പെട്ട ഭാഗങ്ങൾ മാത്രം അയയ്ക്കാനുള്ള ഗുണം കുറയും. വലിയ, ഇതിനകം കംപ്രസ് ചെയ്ത ഫയലുകളിൽ -z ഒഴിവാക്കി പരീക്ഷിക്കുക. iotop, htop, iftop പോലുള്ള ടൂൾസുകൾ ഉപയോഗിച്ച് CPU, ഡിസ്ക്, നെറ്റ്‌വർക്ക് ബോട്ടിൽനെക്കുകൾ കണ്ടെത്താം.

സുരക്ഷയ്ക്കുള്ള മികച്ച രീതികൾ

സെർവർ ഇടം ഫയൽ മാറ്റുമ്പോൾ സുരക്ഷ അവഗണിക്കരുത്. പ്രത്യേകിച്ച് root ആക്സസ്, SSH കീകൾ, ബാക്കപ്പ് ഫയലുകൾ സൂക്ഷ്മമായി കൈകാര്യം ചെയ്യണം. പാസ്‌വേഡ് അടിസ്ഥാനമുള്ള ലോഗിൻ ഒഴിവാക്കി SSH കീ ഉപയോഗിക്കുക. കീ ഫയലുകളുടെ അനുമതികൾ കർശനമാക്കുക, സ്വകാര്യ കീ പങ്കുവെക്കരുത്, സാധ്യമായെങ്കിൽ പാസ്ഫ്രേസ് ഉപയോഗിച്ച് സംരക്ഷിക്കുക.

മാറ്റത്തിനായി താൽക്കാലിക യൂസർ ഉണ്ടാക്കി ആവശ്യമായ ഡയറക്ടറികളിൽ മാത്രം ആക്സസ് നൽകുക നല്ല രീതിയാണ്. ട്രാൻസ്ഫർ കഴിഞ്ഞ് ഈ യൂസറിന്റെ അവകാശങ്ങൾ നീക്കം ചെയ്യാം അല്ലെങ്കിൽ അക്കൗണ്ട് ഡിസ്‌ബേൾ ചെയ്യാം. SSH ആക്സസ് പ്രത്യേക IP വിലാസങ്ങളിലേക്കു മാത്രം പരിമിതപ്പെടുത്തുക. ഫയർവാൾ നിയമങ്ങൾ, Fail2ban, അപ്ഡേറ്റ് ചെയ്ത OpenSSH വേർഷൻ എന്നിവ അവലോകനം ചെയ്യുക.

ഡാറ്റാബേസ് ഡംപ് ഫയലുകൾ, ക്ലയന്റ് ഡോക്യുമെന്റുകൾ, വ്യക്തിഗത ഡാറ്റ എന്നിവയുള്ള ആർക്കൈവുകൾ മാറ്റുമ്പോൾ ട്രാൻസ്ഫർ കഴിഞ്ഞ് സ്രോതസ്സ്, ലക്ഷ്യ സെർവറുകളിൽ അനാവശ്യ താൽക്കാലിക ഫയലുകൾ നീക്കം ചെയ്യണം. വെബ് റൂട്ട് ഡയറക്ടറിയിൽ .sql, .zip, .tar പോലുള്ള ബാക്കപ്പ് ഫയലുകൾ വെക്കുന്നത് ഗൗരവമുള്ള സുരക്ഷാ അപകടം ആണ്. ഈ ഫയലുകൾ വെബ് ആക്സസിൽ നിന്ന് പൂർണമായും അടച്ചിട്ടിരിക്കണം അല്ലെങ്കിൽ പ്രവർത്തനം കഴിഞ്ഞു ഉടൻ നീക്കം ചെയ്യണം.

ഓട്ടോമാറ്റിക് ബാക്കപ്പ് വേണ്ടി rsync ഉപയോഗിക്കൽ

rsync ഒറ്റ തവണ മാറ്റം മാത്രമല്ല, നിരന്തരം ബാക്കപ്പ് നൽകാനും ഉപയോഗിക്കാം. ഉദാഹരണത്തിന്, ഓരോ രാത്രിയും ഒരു പ്രത്യേക ഫോളഡർ ബാക്കപ്പ് സെർവറിലേക്ക് അയയ്ക്കാൻ ക്രോൺ ജോബ് സജ്ജീകരിക്കാം. ഈ സാഹചര്യത്തിൽ SSH കീ ഉപയോഗിച്ച് പാസ്‌വേഡ് ഇല്ലാതെ സുരക്ഷിത കണക്ഷൻ ഉണ്ടാക്കുകയും, rsync മാറ്റപ്പെട്ട ഫയലുകൾ മാത്രം അയയ്ക്കുകയും, ബാൻഡ്‌വിഡ്ത് നിയന്ത്രണം ഏർപ്പെടുത്തുകയും ചെയ്യും.

ഉദാഹരണ കമാൻഡ്: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. ഇത് ലക്ഷ്യ ഡയറക്ടറിയെ സ്രോതസ്സ് പോലെ സിങ്ക് ചെയ്യുന്നു. എന്നാൽ --delete കാരണം ശ്രദ്ധയോടെ ഉപയോഗിക്കണം; സ്രോതസ്സ് ഫയലുകൾ ഡിലീറ്റ് ചെയ്താൽ ലക്ഷ്യത്തും നീക്കം ചെയ്യും. അതുകൊണ്ട് ബാക്കപ്പ് തന്ത്രങ്ങളിൽ സ്നാപ്ഷോട്ടുകൾ, ഡെയിലി ഫോൾഡറുകൾ, വേർഷൻ നിയന്ത്രണം എന്നിവ ഉപയോഗിക്കണം.

ഹോസ്റ്റിംഗ് പ്രവർത്തനങ്ങളിൽ 3-2-1 ബാക്കപ്പ് സിദ്ധാന്തം നല്ല മാർഗ്ഗനിർദ്ദേശമാണ്: ഡാറ്റയുടെ കുറഞ്ഞത് 3 പ്രതികൾ, 2 വ്യത്യസ്ത മീഡിയകളിൽ, 1 വ്യത്യസ്ത ലൊക്കേഷനിൽ സൂക്ഷിക്കണം. rsync സെർവർ ഇടം കോപ്പി ചെയ്യൽ ലളിതമാക്കുന്നു. കൂടുതൽ സമഗ്ര ഇൻഫ്രാസ്ട്രക്ചർ തീർക്കാൻ ബാക്കപ്പ് പരിഹാരങ്ങൾയും കോർപ്പറേറ്റ് ഹോസ്റ്റിംഗ് സേവനങ്ങൾയും സഹായിക്കും.

അവസാന പരിശോധന ലിസ്റ്റ്

വലിയ ഫയലുകൾ മാറ്റം ആരംഭിക്കുമ്പോൾ താഴെപ്പറയുന്ന ലിസ്റ്റ് പരിശോധിക്കുന്നത് പിഴവുകൾ കുറയ്ക്കും. പ്രത്യേകിച്ച് പ്രൊഡക്ഷൻ പരിസരങ്ങളിൽ ഈ പ്രക്രിയ സ്റ്റാൻഡേർഡ് ആക്കണം.

• സ്രോതസ്സ്, ലക്ഷ്യ സെർവറുകളിൽ rsync ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടോ?
• SSH കണക്ഷൻ ശരിയായ യൂസർ, പോർട്ട് ഉപയോഗിച്ച് പരീക്ഷിച്ചിട്ടുണ്ടോ?
• ലക്ഷ്യ സെർവറിൽ മതിയായ ഡിസ്ക് സ്പേസ് ഉണ്ടോ?
• ആദ്യം --dry-run ഉപയോഗിച്ച് പരിശോധിച്ചതുണ്ടോ?
• ലൈവ് സൈറ്റിനായി മെയിൻടനൻസ് മോഡ്, അവസാന സിങ്ക്രണൈസേഷൻ പ്ലാൻ ചെയ്തിട്ടുണ്ടോ?
• --delete ഉപയോഗിക്കുമ്പോൾ ലക്ഷ്യ പാത ശരിയായിട്ടുണ്ടോ?
• ട്രാൻസ്ഫർ കഴിഞ്ഞ് ഫയൽ വലിപ്പം, അനുമതികൾ, ആപ്ലിക്കേഷൻ ഫംഗ്ഷണാലിറ്റി പരിശോധിക്കുമോ?
• താൽക്കാലിക ബാക്കപ്പ്, ഡംപ് ഫയലുകൾ സുരക്ഷിതമായി നീക്കം ചെയ്യും?

ഈ പരിശോധനകൾ ലളിതമാണ് എങ്കിലും യഥാർത്ഥത്തിൽ ഏറ്റവും കൂടുതൽ സംഭവിക്കുന്ന പ്രശ്നങ്ങൾ തെറ്റായ ലക്ഷ്യ ഡയറക്ടറി, കുറവായ അനുമതികൾ, മതിയായ ഡിസ്ക് സ്പേസ് ഇല്ലായ്മ, അനിയന്ത്രിത DNS മാറ്റം എന്നിവയാണ്. നല്ല പദ്ധതി ഉള്ള rsync പ്രക്രിയ മാറ്റ സമയം കുറയ്ക്കുകയും പിഴവുകൾ തിരുത്താനുള്ള സാധ്യത ഉയർത്തുകയും ചെയ്യും.

സാധാരണ ചോദ്യങ്ങൾ

SSH വഴി rsync കമാൻഡ് കണക്ഷൻ വിച്ഛേദിച്ചാൽ ട്രാൻസ്ഫർ വീണ്ടും തുടങ്ങുമോ?

ഇല്ല, ശരിയായ പാരാമീറ്ററുകൾ ഉപയോഗിച്ചാൽ തുടക്കം മുതൽ ആവർത്തിക്കേണ്ടതില്ല. --partial, --append-verify ഓപ്ഷനുകൾ വലിയ ഭാഗം പൂർണ്ണമായില്ലെങ്കിലും കണക്കു വച്ചും തുടർച്ചയായി ട്രാൻസ്ഫർ നടത്താൻ സഹായിക്കുന്നു. അതേസമയം പ്രധാന മാറ്റങ്ങൾക്കു മുൻപ് ലക്ഷ്യ സെർവറിലെ ഡിസ്ക് സ്ഥിതി പരിശോധിക്കുക.

rsync ഉപയോഗിച്ച് ഡാറ്റാബേസ് നേരിട്ട് മാറ്റാമോ?

rsync ഫയലുകൾ മാത്രം മാറ്റുന്നു; പ്രവർത്തിക്കുന്ന ഡാറ്റാബേസ് ഫയലുകൾ നേരിട്ട് കോപ്പി ചെയ്യുന്നത് ശുപാർശ ചെയ്യില്ല. MySQL, MariaDB എന്നിവയ്ക്ക് mysqldump പോലുള്ള ബാക്കപ്പ് ടൂളുകൾ ഉപയോഗിച്ച് ഡാറ്റാബേസ് ബാക്കപ്പ് എടുത്ത് ആ ഫയൽ rsync ഉപയോഗിച്ച് മാറ്റണം. ലൈവ് സിസ്റ്റങ്ങളിൽ ഡാറ്റ സമഗ്രതയ്ക്ക് മെയിൻടനൻസ് മോഡ് അല്ലെങ്കിൽ റിപ്ലിക്കേഷൻ പ്ലാൻ ചെയ്യണം.

rsync ഉപയോഗിക്കാൻ രണ്ട് സെർവറുകളിലും root ആക്സസ് ആവശ്യമുണ്ടോ?

root ആക്സസ് അത്യാവശ്യമല്ല. ലക്ഷ്യ ഡയറക്ടറിയിൽ എഴുതാനുള്ള അനുമതിയുള്ള ഒരു യൂസർ മതിയാകും. എന്നാൽ ഫയൽ ഉടമസ്ഥാവകാശം, സിസ്റ്റം ഡയറക്ടറികൾ, ACL, പ്രത്യേക അനുമതികൾ സംരക്ഷിക്കേണ്ടതുണ്ടെങ്കിൽ ഉയർന്ന അധികാരം ആവശ്യമായേക്കാം. സുരക്ഷാ കണക്കുകളിൽ പരിമിത അധികാരമുള്ള യൂസർ ഉപയോഗിക്കുക ഉത്തമം.

--delete ഓപ്ഷൻ സുരക്ഷിതമാണോ?

--delete ശരിയായ രീതിയിൽ ഉപയോഗിച്ചാൽ ലക്ഷ്യ ഡയറക്ടറി സ്രോതസ്സിനെ ഒത്തിരിക്കാൻ ഉത്തമമാണ്; എന്നാൽ തെറ്റായ സ്ഥലത്ത് ഉപയോഗിച്ചാൽ ഡാറ്റ നഷ്ടം സംഭവിക്കും. അതിനാൽ --delete ഉൾപ്പെട്ട കമാൻഡ് ആദ്യം --dry-run ഉപയോഗിച്ച് പരീക്ഷിക്കുക, സ്രോതസ്സും ലക്ഷ്യവും ശ്രദ്ധാപൂർവം പരിശോധിക്കുക.

വലിയ ഫയൽ ട്രാൻസ്ഫറിന് rsync ഉത്തമമാണോ അതോ scp?

ചെറിയ, ഒറ്റ തവണ കോപ്പി ചെയ്യലുകൾക്ക് scp മതിയാകും; പക്ഷേ വലിയ ഫയലുകൾ, അനേകം ഫയലുകൾ, ആവർത്തിക്കുന്ന സിങ്ക്രണൈസേഷനുകൾക്ക് rsync മികച്ചതാണ്. കാരണം ഇത് മാറ്റപ്പെട്ട ഡാറ്റ തിരിച്ചറിയുകയും, ഇടവേള പൂർണ്ണമല്ലാത്ത ട്രാൻസ്ഫറുകൾ തുടരുമെന്നും, ബാൻഡ്‌വിഡ്ത് നിയന്ത്രണം നൽകുകയും, ടെസ്റ്റ് മോഡ് നൽകുകയും ചെയ്യുന്നു.

സംക്ഷേപവും അടുത്ത പടിയും

SSH വഴി rsync കമാൻഡ് ഉപയോഗിച്ച് രണ്ട് സെർവറുകൾക്കിടയിലുള്ള വലിയ ഫയലുകൾ മാറ്റം നടത്തുന്നത് വേഗതയേറിയ, സുരക്ഷിതമായ, നിയന്ത്രിക്കാവുന്ന മാർഗമാണ്. ശരിയായ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് കണക്ഷൻ വിച്ഛേദങ്ങൾ ഒഴിവാക്കാം, മാറ്റപ്പെട്ട ഫയലുകൾ മാത്രം അയച്ച് സമയം ലാഭിക്കാം, ലൈവ് സൈറ്റ് മാറ്റം സമയത്ത് ഇടവേള കുറക്കാം. മികച്ച ഫലം നേടാൻ ആദ്യം SSH, ഡിസ്ക് സ്ഥിതി പരിശോധിക്കുക, --dry-run ഉപയോഗിച്ച് ടെസ്റ്റ് ചെയ്യുക, തുടർന്ന് പ്രധാന ട്രാൻസ്ഫർ പണികൾ പദ്ധതിയാക്കി നടത്തുക.

പുതിയ സെർവറിലേക്ക് മാറൽ, ഉയർന്ന ശേഷിയുള്ള സ്റ്റോറേജ്, മെച്ചപ്പെട്ട ഹോസ്റ്റിംഗ് പ്ലാറ്റ്‌ഫോം എന്നിവ ആവശ്യമായാൽ Hostragons-ന്റെ പരിഹാരങ്ങൾ പരിശോധിച്ച് VPS, ഹോസ്റ്റിംഗ്, ഡൊമൈൻ, SSL എന്നിവ ഉപയോഗിച്ച് മാറ്റം സുരക്ഷിതമാക്കാം. ചെറിയ ടെസ്റ്റുകൾ നടത്തിയും, ഫലം വിലയിരുത്തിയും, അവസാന സിങ്ക്രണൈസേഷൻ കരുതിയ രീതിയിൽ നടത്തിയും പ്രശ്നരഹിതമായ മാറ്റം ഉറപ്പാക്കാം.