വലിയ NextCloud സ്റ്റോറേജുകൾ ബാക്കപ്പ് ചെയ്യാൻ GitLab നിങ്ങളെ എങ്ങനെ സഹായിക്കുന്നു

ഹേ ഹബർ!

വ്യത്യസ്‌ത കോൺഫിഗറേഷനുകളിൽ Nextcloud സ്റ്റോറേജുകളിൽ നിന്നുള്ള വലിയ ഡാറ്റയുടെ ബാക്കപ്പ് ഓട്ടോമേറ്റ് ചെയ്യുന്നതിലെ ഞങ്ങളുടെ അനുഭവത്തെക്കുറിച്ച് ഇന്ന് ഞാൻ സംസാരിക്കാൻ ആഗ്രഹിക്കുന്നു. ഞാൻ മൊൾനിയ എകെയിൽ ഒരു സർവീസ് സ്റ്റേഷനായി ജോലി ചെയ്യുന്നു, അവിടെ ഞങ്ങൾ ഐടി സിസ്റ്റങ്ങളുടെ കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് ചെയ്യുന്നു; ഡാറ്റ സംഭരണത്തിനായി നെക്സ്റ്റ്ക്ലൗഡ് ഉപയോഗിക്കുന്നു. വിതരണം ചെയ്ത ഘടനയോടെ, ആവർത്തനത്തോടെ.

ഇൻസ്റ്റാളേഷനുകളുടെ സവിശേഷതകളിൽ നിന്ന് ഉണ്ടാകുന്ന പ്രശ്നങ്ങൾ ധാരാളം ഡാറ്റ ഉണ്ട് എന്നതാണ്. Nextcloud നൽകുന്ന പതിപ്പ്, ആവർത്തനം, ആത്മനിഷ്ഠ കാരണങ്ങൾ എന്നിവയും മറ്റും നിരവധി തനിപ്പകർപ്പുകൾ സൃഷ്ടിക്കുന്നു.

ചരിത്രാതീതകാലം

Nextcloud അഡ്മിനിസ്ട്രേഷൻ ചെയ്യുമ്പോൾ, ഫലപ്രദമായ ഒരു ബാക്കപ്പ് സംഘടിപ്പിക്കുന്നതിനുള്ള പ്രശ്നം ഉയർന്നുവരുന്നു, ഡാറ്റ വിലപ്പെട്ടതിനാൽ അത് എൻക്രിപ്റ്റ് ചെയ്യണം.

ഞങ്ങളുടെ സ്ഥലത്തോ നെക്സ്റ്റ്ക്ലൗഡിൽ നിന്നുള്ള പ്രത്യേക മെഷീനുകളിലോ ഉപഭോക്താവിന്റെ അടുത്തോ ബാക്കപ്പുകൾ സംഭരിക്കുന്നതിനുള്ള ഓപ്‌ഷനുകൾ ഞങ്ങൾ ഓഫർ ചെയ്യുന്നു, ഇതിന് അഡ്മിനിസ്ട്രേഷനിൽ ഒരു ഫ്ലെക്സിബിൾ ഓട്ടോമേറ്റഡ് സമീപനം ആവശ്യമാണ്.

നിരവധി ക്ലയന്റുകൾ ഉണ്ട്, അവയെല്ലാം വ്യത്യസ്ത കോൺഫിഗറേഷനുകളുള്ളവയാണ്, കൂടാതെ എല്ലാം അവരുടെ സ്വന്തം സൈറ്റുകളിലും അവരുടേതായ സവിശേഷതകളിലും. മുഴുവൻ സൈറ്റും നിങ്ങളുടേതായിരിക്കുമ്പോൾ ഇതൊരു സാധാരണ സാങ്കേതികതയാണ്, കൂടാതെ ബാക്കപ്പുകൾ കിരീടങ്ങളിൽ നിന്നാണ് നിർമ്മിച്ചിരിക്കുന്നത്; ഇത് നന്നായി യോജിക്കുന്നില്ല.

ആദ്യം, നമുക്ക് ഇൻപുട്ട് ഡാറ്റ നോക്കാം. ഞങ്ങൾക്ക് ആവശ്യമാണ്:

• ഒരു നോഡിന്റെയോ പലതിന്റെയോ അടിസ്ഥാനത്തിൽ സ്കേലബിളിറ്റി. വലിയ ഇൻസ്റ്റാളേഷനുകൾക്കായി ഞങ്ങൾ മിനിയോ സ്റ്റോറേജ് ആയി ഉപയോഗിക്കുന്നു.
• ബാക്കപ്പുകൾ നിർവഹിക്കുന്നതിലെ പ്രശ്‌നങ്ങളെക്കുറിച്ച് കണ്ടെത്തുക.
• നിങ്ങളുടെ ക്ലയന്റുകളുമായി ഒപ്പം/അല്ലെങ്കിൽ ഞങ്ങളുമായി ഒരു ബാക്കപ്പ് സൂക്ഷിക്കേണ്ടതുണ്ട്.
• പ്രശ്നങ്ങൾ വേഗത്തിലും എളുപ്പത്തിലും കൈകാര്യം ചെയ്യുക.
• ക്ലയന്റുകളും ഇൻസ്റ്റാളേഷനുകളും പരസ്പരം വളരെ വ്യത്യസ്തമാണ് - ഏകീകൃതത കൈവരിക്കാൻ കഴിയില്ല.
• രണ്ട് സാഹചര്യങ്ങളിൽ വീണ്ടെടുക്കൽ വേഗത വളരെ കുറവായിരിക്കണം: പൂർണ്ണമായ വീണ്ടെടുക്കൽ (ദുരന്തം), ഒരു ഫോൾഡർ അബദ്ധത്തിൽ മായ്ച്ചു.
• ഡ്യൂപ്ലിക്കേഷൻ ഫംഗ്‌ഷൻ ആവശ്യമാണ്.

ബാക്കപ്പുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള പ്രശ്നം പരിഹരിക്കാൻ, ഞങ്ങൾ GitLab ഇൻസ്റ്റാൾ ചെയ്തു. ടാക്കിൾ വഴി കൂടുതൽ വിശദാംശങ്ങൾ.

തീർച്ചയായും, അത്തരമൊരു പ്രശ്നം പരിഹരിക്കുന്നതിൽ ഞങ്ങൾ ആദ്യം അല്ല, എന്നാൽ ഞങ്ങളുടെ പ്രായോഗികവും കഠിനാധ്വാനം ചെയ്തതുമായ അനുഭവം രസകരമായിരിക്കാമെന്നും അത് പങ്കിടാൻ ഞങ്ങൾ തയ്യാറാണെന്നും തോന്നുന്നു.

ഞങ്ങളുടെ കമ്പനിക്ക് ഒരു ഓപ്പൺ സോഴ്‌സ് പോളിസി ഉള്ളതിനാൽ, ഞങ്ങൾ ഒരു ഓപ്പൺ സോഴ്‌സ് സൊല്യൂഷൻ തേടുകയായിരുന്നു. അതാകട്ടെ, ഞങ്ങൾ ഞങ്ങളുടെ സംഭവവികാസങ്ങൾ പങ്കിടുകയും അവ പോസ്റ്റുചെയ്യുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, GitHub-ൽ ഉണ്ട് Nextcloud-നുള്ള ഞങ്ങളുടെ പ്ലഗിൻ, ഞങ്ങൾ ക്ലയന്റുകൾക്ക് നൽകുന്നത്, ആകസ്മികമോ മനഃപൂർവ്വമോ ഇല്ലാതാക്കിയാൽ ഡാറ്റ സുരക്ഷ വർദ്ധിപ്പിക്കുന്നു.

ബാക്കപ്പ് ഉപകരണങ്ങൾ

ഒരു ബാക്കപ്പ് സൃഷ്‌ടിക്കൽ ഉപകരണം തിരഞ്ഞെടുത്ത് ഞങ്ങൾ പരിഹാര മാർഗ്ഗങ്ങൾക്കായുള്ള തിരയൽ ആരംഭിച്ചു.

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

ഡ്യൂപ്ലിക്കേഷൻ ഉള്ള ബാക്കപ്പ് ടൂളുകൾ ഓപ്പൺ സോഴ്സിൽ ലഭ്യമാണ് (ഹബ്രെയിൽ ഉണ്ടായിരുന്നു ലേഖനങ്ങൾ ഈ വിഷയത്തെക്കുറിച്ച്) എന്നിവരും ഞങ്ങളുടെ ഫൈനലിസ്റ്റുകളായിരുന്നു ബോർഗ് и റെസ്റ്റിക്. രണ്ട് ആപ്ലിക്കേഷനുകളുടെയും ഞങ്ങളുടെ താരതമ്യം ചുവടെയുണ്ട്, എന്നാൽ ഇപ്പോൾ ഞങ്ങൾ മുഴുവൻ സ്കീമും എങ്ങനെ സംഘടിപ്പിച്ചുവെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും.

ബാക്കപ്പുകൾ കൈകാര്യം ചെയ്യുന്നു

Borg ഉം Restic ഉം നല്ലതാണ്, എന്നാൽ ഒരു ഉൽപ്പന്നത്തിനും കേന്ദ്രീകൃത നിയന്ത്രണ സംവിധാനമില്ല. മാനേജ്മെന്റിന്റെയും നിയന്ത്രണത്തിന്റെയും ഉദ്ദേശ്യത്തിനായി, ഞങ്ങൾ ഇതിനകം നടപ്പിലാക്കിയ ഒരു ടൂൾ ഞങ്ങൾ തിരഞ്ഞെടുത്തു, അതില്ലാതെ ഓട്ടോമേഷൻ ഉൾപ്പെടെയുള്ള ഞങ്ങളുടെ ജോലി സങ്കൽപ്പിക്കാൻ കഴിയില്ല - ഇതാണ് അറിയപ്പെടുന്ന CI/CD - GitLab.

ആശയം ഇപ്രകാരമാണ്: Nextcloud ഡാറ്റ സംഭരിക്കുന്ന ഓരോ നോഡിലും gitlab-runner ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. ബാക്കപ്പ് പ്രോസസ്സ് നിരീക്ഷിക്കുന്ന ഒരു ഷെഡ്യൂളിൽ റണ്ണർ ഒരു സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നു, അത് Borg അല്ലെങ്കിൽ Restic സമാരംഭിക്കുന്നു.

നമുക്ക് എന്താണ് ലഭിച്ചത്? നിർവ്വഹണത്തിൽ നിന്നുള്ള ഫീഡ്ബാക്ക്, മാറ്റങ്ങളിൽ സൗകര്യപ്രദമായ നിയന്ത്രണം, ഒരു പിശകുണ്ടായാൽ വിശദാംശങ്ങൾ.

ഇവിടെ ഇവിടെ GitHub-ൽ വിവിധ ടാസ്ക്കുകൾക്കായി ഞങ്ങൾ സ്ക്രിപ്റ്റിന്റെ ഉദാഹരണങ്ങൾ പോസ്റ്റ് ചെയ്തു, ഞങ്ങൾ അത് നെക്സ്റ്റ്ക്ലൗഡിന്റെ മാത്രമല്ല, മറ്റ് പല സേവനങ്ങളുടെയും ബാക്കപ്പിലേക്ക് അറ്റാച്ചുചെയ്യാൻ അവസാനിപ്പിച്ചു. നിങ്ങൾക്ക് ഇത് സ്വമേധയാ കോൺഫിഗർ ചെയ്യാൻ താൽപ്പര്യമില്ലെങ്കിൽ (ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല) കൂടാതെ .gitlab-ci.yml എന്നിവയും അവിടെ ഒരു ഷെഡ്യൂളർ ഉണ്ട്.

Gitlab API-യിൽ CI/CD കാലഹരണപ്പെടൽ മാറ്റാൻ ഇതുവരെ ഒരു മാർഗവുമില്ല, പക്ഷേ ഇത് ചെറുതാണ്. ഇത് വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്, പറയുക 1d.

GitLab, ഭാഗ്യവശാൽ, ഒരു പ്രതിബദ്ധത അനുസരിച്ച് മാത്രമല്ല, ഒരു ഷെഡ്യൂൾ അനുസരിച്ച് മാത്രമേ സമാരംഭിക്കാൻ കഴിയൂ, ഇതാണ് നമുക്ക് വേണ്ടത്.

ഇപ്പോൾ റാപ്പർ സ്ക്രിപ്റ്റിനെക്കുറിച്ച്.

ഈ സ്ക്രിപ്റ്റിനായി ഞങ്ങൾ ഇനിപ്പറയുന്ന വ്യവസ്ഥകൾ സജ്ജമാക്കി:

• ഒരേ പ്രവർത്തനക്ഷമതയുള്ള കൺസോളിൽ നിന്ന് റണ്ണർ മുഖേനയും കൈകൊണ്ടും ഇത് ലോഞ്ച് ചെയ്യണം.
• പിശക് കൈകാര്യം ചെയ്യുന്നവർ ഉണ്ടായിരിക്കണം:
• റിട്ടേൺ കോഡ്.
• ലോഗിൽ ഒരു സ്ട്രിങ്ങിനായി തിരയുക. ഉദാഹരണത്തിന്, ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം ഒരു പിശക് പ്രോഗ്രാം മാരകമായി കണക്കാക്കാത്ത ഒരു സന്ദേശമായിരിക്കാം.
• പ്രോസസ്സിംഗ് കാലഹരണപ്പെട്ടു. ലീഡ് സമയം ന്യായയുക്തമായിരിക്കണം.
• ഞങ്ങൾക്ക് വളരെ വിശദമായ ഒരു ലോഗ് ആവശ്യമാണ്. എന്നാൽ ഒരു തെറ്റ് സംഭവിച്ചാൽ മാത്രം.
• ആരംഭിക്കുന്നതിന് മുമ്പ് നിരവധി പരിശോധനകളും നടത്തുന്നു.
• പിന്തുണാ പ്രക്രിയയിൽ ഞങ്ങൾ ഉപയോഗപ്രദമെന്ന് കണ്ടെത്തിയ സൗകര്യാർത്ഥം ചെറിയ ബോണസുകൾ:
• ആരംഭവും അവസാനവും ലോക്കൽ മെഷീന്റെ സിസ്ലോഗിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ട്. സിസ്റ്റം പിശകുകളും ബാക്കപ്പ് പ്രവർത്തനവും ബന്ധിപ്പിക്കുന്നതിന് ഇത് സഹായിക്കുന്നു.
• പിശക് ലോഗിന്റെ ഒരു ഭാഗം, എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, അത് stdout-ലേക്ക് ഔട്ട്പുട്ട് ചെയ്യുന്നു, മുഴുവൻ ലോഗും ഒരു പ്രത്യേക ഫയലിലേക്ക് എഴുതിയിരിക്കുന്നു. നിസാരമാണെങ്കിൽ ഉടൻ സിഐയെ നോക്കി പിഴവ് വിലയിരുത്തുന്നത് സൗകര്യപ്രദമാണ്.
• ഡീബഗ്ഗിംഗ് മോഡുകൾ.

പൂർണ്ണ ലോഗ് GitLab-ൽ ഒരു ആർട്ടിഫാക്‌റ്റായി സംരക്ഷിച്ചിരിക്കുന്നു; പിശക് ഇല്ലെങ്കിൽ, ലോഗ് ഇല്ലാതാക്കപ്പെടും. ഞങ്ങൾ തിരക്കഥ എഴുതുന്നത് ബാഷിലാണ്.

ഓപ്പൺ സോഴ്‌സിനെ സംബന്ധിച്ച എന്തെങ്കിലും നിർദ്ദേശങ്ങളും അഭിപ്രായങ്ങളും പരിഗണിക്കുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട് - സ്വാഗതം.

എങ്ങനെ പ്രവർത്തിക്കുന്നില്ല

ബാഷ് എക്സിക്യൂട്ടറുള്ള ഒരു റണ്ണർ ബാക്കപ്പ് നോഡിൽ ലോഞ്ച് ചെയ്യുന്നു. ഷെഡ്യൂളർ അനുസരിച്ച്, ജോലി CI/CD ഒരു പ്രത്യേക ടേണിപ്പിൽ സമാരംഭിക്കുന്നു. റണ്ണർ അത്തരം ടാസ്‌ക്കുകൾക്കായി ഒരു സാർവത്രിക റാപ്പർ സ്‌ക്രിപ്റ്റ് സമാരംഭിക്കുന്നു, ഇത് ബാക്കപ്പ് ശേഖരണത്തിന്റെയും മൗണ്ട് പോയിന്റുകളുടെയും നമുക്ക് ആവശ്യമുള്ള എല്ലാത്തിന്റെയും സാധുത പരിശോധിക്കുന്നു, തുടർന്ന് ബാക്കപ്പ് ചെയ്‌ത് പഴയത് വൃത്തിയാക്കുന്നു. പൂർത്തിയായ ബാക്കപ്പ് തന്നെ S3-ലേക്ക് അയച്ചു.

ഈ സ്കീം അനുസരിച്ച് ഞങ്ങൾ പ്രവർത്തിക്കുന്നു - ഇത് ഒരു ബാഹ്യ AWS ദാതാവാണ് അല്ലെങ്കിൽ റഷ്യൻ തത്തുല്യമാണ് (ഇത് വേഗതയേറിയതും ഡാറ്റ റഷ്യൻ ഫെഡറേഷനിൽ നിന്ന് പുറത്തുപോകില്ല). അല്ലെങ്കിൽ ഈ ആവശ്യങ്ങൾക്കായി ക്ലയന്റിനായി അവന്റെ സൈറ്റിൽ ഞങ്ങൾ ഒരു പ്രത്യേക മിനിയോ ക്ലസ്റ്റർ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. സുരക്ഷാ കാരണങ്ങളാലാണ് ഞങ്ങൾ സാധാരണയായി ഇത് ചെയ്യുന്നത്, ക്ലയന്റ് അവരുടെ സർക്യൂട്ടിൽ നിന്ന് ഡാറ്റ ഉപേക്ഷിക്കാൻ ആഗ്രഹിക്കുന്നില്ലെങ്കിൽ.

ssh വഴി ബാക്കപ്പ് അയക്കാനുള്ള ഫീച്ചർ ഞങ്ങൾ ഉപയോഗിച്ചിട്ടില്ല. ഇത് സുരക്ഷ ചേർക്കുന്നില്ല, കൂടാതെ S3 ദാതാവിന്റെ നെറ്റ്‌വർക്ക് കഴിവുകൾ ഞങ്ങളുടെ ഒരു ssh മെഷീനേക്കാൾ വളരെ ഉയർന്നതാണ്.

ഒരു ഹാക്കറിൽ നിന്ന് നിങ്ങളുടെ ലോക്കൽ മെഷീനെ പരിരക്ഷിക്കുന്നതിന്, അയാൾക്ക് S3-ലെ ഡാറ്റ മായ്ക്കാൻ കഴിയുമെന്നതിനാൽ, നിങ്ങൾ പതിപ്പിംഗ് പ്രവർത്തനക്ഷമമാക്കണം.
ബാക്കപ്പ് എപ്പോഴും ബാക്കപ്പ് എൻക്രിപ്റ്റ് ചെയ്യുന്നു.

Borg-ന് എൻക്രിപ്റ്റ് ചെയ്യാത്ത ഒരു മോഡ് ഉണ്ട് none, എന്നാൽ അത് ഓണാക്കാൻ ഞങ്ങൾ ശക്തമായി ശുപാർശ ചെയ്യുന്നില്ല. ഈ മോഡിൽ, എൻക്രിപ്ഷൻ ഉണ്ടാകില്ലെന്ന് മാത്രമല്ല, എഴുതിയതിന്റെ ചെക്ക്സം കണക്കാക്കില്ല, അതായത് ഇൻഡെക്സുകൾ ഉപയോഗിച്ച് പരോക്ഷമായി മാത്രമേ സമഗ്രത പരിശോധിക്കാൻ കഴിയൂ.

ഇൻഡെക്സുകളുടെയും ഉള്ളടക്കത്തിന്റെയും സമഗ്രതയ്ക്കായി ഒരു പ്രത്യേക ഷെഡ്യൂളർ ബാക്കപ്പുകൾ പരിശോധിക്കുന്നു. പരിശോധന മന്ദഗതിയിലുള്ളതും ദൈർഘ്യമേറിയതുമാണ്, അതിനാൽ ഞങ്ങൾ മാസത്തിലൊരിക്കൽ ഇത് പ്രത്യേകം പ്രവർത്തിപ്പിക്കുന്നു. ഇതിന് കുറച്ച് ദിവസങ്ങൾ എടുത്തേക്കാം.

റഷ്യൻ ഭാഷയിൽ റീഡ്മി

പ്രധാന പ്രവർത്തനങ്ങൾ

• prepare തയാറാക്കുക
• testcheck സന്നദ്ധത പരിശോധന
• maincommand കോർ ടീം
• forcepostscript അവസാനം അല്ലെങ്കിൽ പിശക് വഴി നടപ്പിലാക്കുന്ന ഒരു ഫംഗ്ഷൻ. പാർട്ടീഷൻ അൺമൗണ്ട് ചെയ്യാൻ ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു.

സേവന പ്രവർത്തനങ്ങൾ

• cleanup ഞങ്ങൾ പിശകുകൾ രേഖപ്പെടുത്തുകയോ ലോഗ് ഫയൽ മായ്ക്കുകയോ ചെയ്യുന്നു.
• checklog ഒരു പിശക് ഉള്ള ഒരു വരി ഉണ്ടാകുന്നതിന് ലോഗ് പാഴ്സ് ചെയ്യുക.
• ret എക്സിറ്റ് ഹാൻഡ്ലർ.
• checktimeout സമയപരിധി പരിശോധിക്കുക.

പരിസ്ഥിതി

• VERBOSE=1 ഞങ്ങൾ പിശകുകൾ ഉടൻ സ്ക്രീനിൽ പ്രദർശിപ്പിക്കുന്നു (stdout).
• SAVELOGSONSUCCES=1 വിജയിക്കുമ്പോൾ ലോഗ് സംരക്ഷിക്കുക.
• INIT_REPO_IF_NOT_EXIST=1 അത് നിലവിലില്ലെങ്കിൽ ഒരു ശേഖരം സൃഷ്ടിക്കുക. സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനരഹിതമാക്കി.
• TIMEOUT പ്രധാന പ്രവർത്തനത്തിനുള്ള പരമാവധി സമയം. നിങ്ങൾക്ക് ഇത് അവസാനം 'm', 'h' അല്ലെങ്കിൽ 'd' ആയി സജ്ജീകരിക്കാം.

പഴയ പകർപ്പുകൾക്കുള്ള സംഭരണ ​​മോഡ്. ഡിഫോൾട്ട്:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

സ്ക്രിപ്റ്റിനുള്ളിലെ വേരിയബിളുകൾ

• ERROR_STRING - പിശകിനുള്ള ചെക്ക് ഇൻ ലോഗിനുള്ള സ്ട്രിംഗ്.
• EXTRACT_ERROR_STRING - പിശക് ആണെങ്കിൽ ഷോ സ്ട്രിംഗിനുള്ള എക്സ്പ്രഷൻ.
• KILL_TIMEOUT_SIGNAL - കാലഹരണപ്പെട്ടാൽ കൊല്ലാനുള്ള സിഗ്നൽ.
• TAIL - സ്ക്രീനിൽ പിശകുകളുള്ള എത്ര സ്ട്രിംഗുകൾ.
• COLORMSG - സന്ദേശത്തിന്റെ നിറം (സ്ഥിര മഞ്ഞ).

വേർഡ്പ്രസ്സ് എന്ന് വിളിക്കപ്പെടുന്ന ആ സ്ക്രിപ്റ്റിന് ഒരു സോപാധിക നാമമുണ്ട്, അതിന്റെ തന്ത്രം അത് mysql ഡാറ്റാബേസും ബാക്കപ്പ് ചെയ്യുന്നു എന്നതാണ്. ഇതിനർത്ഥം ഇത് സിംഗിൾ-നോഡ് Nexcloud ഇൻസ്റ്റാളേഷനുകൾക്കായി ഉപയോഗിക്കാമെന്നാണ്, അവിടെ നിങ്ങൾക്ക് ഡാറ്റാബേസ് ബാക്കപ്പ് ചെയ്യാനും കഴിയും. സൗകര്യം എല്ലാം ഒരിടത്ത് മാത്രമല്ല, ഡാറ്റാബേസിലെ ഉള്ളടക്കങ്ങളും ഫയലുകളുടെ ഉള്ളടക്കത്തോട് അടുത്താണ്, കാരണം സമയ വ്യത്യാസം വളരെ കുറവാണ്.

റെസ്റ്റിക് വേഴ്സസ് ബോർഗ്

Borg ഉം Restic ഉം തമ്മിൽ താരതമ്യങ്ങളുമുണ്ട് ഇവിടെ ഹബ്രെയിൽ, മറ്റൊന്ന് ഉണ്ടാക്കുക എന്ന ടാസ്‌ക് ഞങ്ങൾക്കില്ല, മറിച്ച് ഞങ്ങളുടെ സ്വന്തം. ഞങ്ങളുടെ ഡാറ്റയിൽ, ഞങ്ങളുടെ പ്രത്യേകതകൾക്കൊപ്പം അത് എങ്ങനെ കാണപ്പെടും എന്നത് ഞങ്ങൾക്ക് പ്രധാനമായിരുന്നു. ഞങ്ങൾ അവരെ കൊണ്ടുവരുന്നു.

ഞങ്ങളുടെ തിരഞ്ഞെടുക്കൽ മാനദണ്ഡം, ഇതിനകം സൂചിപ്പിച്ചവ കൂടാതെ (ഡീപ്ലിക്കേഷൻ, ഫാസ്റ്റ് റിക്കവറി മുതലായവ):

• പൂർത്തിയാകാത്ത ജോലികൾക്കുള്ള പ്രതിരോധം. കൊല്ലാൻ പരിശോധിക്കുക -9.
• ഡിസ്കിലെ വലിപ്പം.
• വിഭവങ്ങൾക്കുള്ള ആവശ്യകത (സിപിയു, മെമ്മറി).
• സംഭരിച്ച ബ്ലോബുകളുടെ വലുപ്പം.
• എസ് 3 ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു.
• സമഗ്രത പരിശോധന.

പരിശോധനയ്‌ക്കായി, യഥാർത്ഥ ഡാറ്റയും മൊത്തം 1,6 TB വലുപ്പവുമുള്ള ഒരു ക്ലയന്റാണ് ഞങ്ങൾ എടുത്തത്.
വ്യവസ്ഥകൾ.

S3 ഉപയോഗിച്ച് നേരിട്ട് എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് ബോർഗിന് അറിയില്ല, കൂടാതെ ഞങ്ങൾ ഒരു ഫ്യൂസ് ആയി ഡിസ്ക് മൌണ്ട് ചെയ്തു വിഡ്ഢികൾ. Restic അത് S3 ലേക്ക് തന്നെ അയച്ചു.

Goofys വളരെ വേഗത്തിലും നന്നായി പ്രവർത്തിക്കുന്നു, ഉണ്ട് ഡിസ്ക് കാഷെ മൊഡ്യൂൾ, ഇത് ജോലിയെ കൂടുതൽ വേഗത്തിലാക്കുന്നു. ഇത് ബീറ്റ ഘട്ടത്തിലാണ്, കൂടാതെ, പരിശോധനകൾക്കിടയിൽ (മറ്റുള്ളവ) ഡാറ്റ നഷ്‌ടത്തോടെ ഞങ്ങൾ തകർന്നു. എന്നാൽ ബാക്കപ്പ് നടപടിക്രമത്തിന് തന്നെ കൂടുതൽ വായന ആവശ്യമില്ല എന്നതാണ് സൗകര്യം, പക്ഷേ കൂടുതലും എഴുതുന്നു, അതിനാൽ സമഗ്രത പരിശോധിക്കുമ്പോൾ മാത്രമാണ് ഞങ്ങൾ കാഷെ ഉപയോഗിക്കുന്നത്.

നെറ്റ്‌വർക്കിന്റെ സ്വാധീനം കുറയ്ക്കുന്നതിന്, ഞങ്ങൾ ഒരു പ്രാദേശിക ദാതാവിനെ ഉപയോഗിച്ചു - Yandex Cloud.

താരതമ്യ പരിശോധന ഫലങ്ങൾ.

• വീണ്ടും പുനരാരംഭിച്ച കിൽ -9 രണ്ടും വിജയകരമായിരുന്നു.
• ഡിസ്കിലെ വലിപ്പം. Borg ന് കംപ്രസ് ചെയ്യാൻ കഴിയും, അതിനാൽ ഫലങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെയാണ്.

ബാക്കപ്പർ
വലുപ്പം

ബോർഗ്
562Gb

റെസ്റ്റിക്
628Gb

• സിപിയു വഴി
  സ്ഥിരസ്ഥിതി കംപ്രഷൻ ഉപയോഗിച്ച് ബോർഗ് തന്നെ കുറച്ച് മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ, പക്ഷേ അത് ഗൂഫിസ് പ്രക്രിയയ്‌ക്കൊപ്പം വിലയിരുത്തണം. മൊത്തത്തിൽ, അവ താരതമ്യപ്പെടുത്താവുന്നതും ഒരേ ടെസ്റ്റ് വെർച്വൽ മെഷീനിൽ ഏകദേശം 1,2 കോറുകൾ ഉപയോഗപ്പെടുത്തുന്നതുമാണ്.
• മെമ്മറി. Restic ഏകദേശം 0,5GB ആണ്, Borg ഏകദേശം 200MB ആണ്. എന്നാൽ സിസ്റ്റം ഫയൽ കാഷെയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇതെല്ലാം അപ്രധാനമാണ്. അതിനാൽ കൂടുതൽ മെമ്മറി അനുവദിക്കുന്നതാണ് ഉചിതം.
• ബ്ലബ് വലുപ്പത്തിലുള്ള വ്യത്യാസം ശ്രദ്ധേയമായിരുന്നു.

ബാക്കപ്പർ
വലുപ്പം

ബോർഗ്
ഏകദേശം 500MB

റെസ്റ്റിക്
ഏകദേശം 5MB

• Restic-ന്റെ S3 അനുഭവം മികച്ചതാണ്. ഗൂഫികൾ വഴി ബോർഗുമായി പ്രവർത്തിക്കുന്നത് ചോദ്യങ്ങളൊന്നും ഉന്നയിക്കുന്നില്ല, പക്ഷേ കാഷെ പൂർണ്ണമായും പുനഃസജ്ജമാക്കുന്നതിന് ബാക്കപ്പ് പൂർത്തിയായതിന് ശേഷം umount ചെയ്യുന്നതാണ് ഉചിതമെന്ന് ശ്രദ്ധിക്കപ്പെട്ടു. S3 യുടെ പ്രത്യേകത, അണ്ടർ-പമ്പ് ചെയ്ത ചങ്കുകൾ ഒരിക്കലും ബക്കറ്റിലേക്ക് അയയ്‌ക്കില്ല എന്നതാണ്, അതായത് അപൂർണ്ണമായി പൂരിപ്പിച്ച ഡാറ്റ വലിയ നാശത്തിലേക്ക് നയിക്കുന്നു.
• രണ്ട് സാഹചര്യങ്ങളിലും സമഗ്രത പരിശോധന നന്നായി പ്രവർത്തിക്കുന്നു, എന്നാൽ വേഗത ഗണ്യമായി വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.
  റെസ്റ്റിക് എൺപത് മണിക്കൂർ.
  Borg, 100GB SSD ഫയൽ കാഷെ ഉപയോഗിച്ച് – എൺപത് മണിക്കൂർ.ഡാറ്റ ഒരു ലോക്കൽ ഡിസ്കിലാണെങ്കിൽ ഏകദേശം ഒരേ വേഗത ഫലം.
  ബോർഗ് കാഷെ ഇല്ലാതെ S3-ൽ നിന്ന് നേരിട്ട് വായിക്കുന്നു എൺപത് മണിക്കൂർ. ഭയങ്കര നീളം.

ബോർഗിന് കംപ്രസ്സുചെയ്യാനും വലിയ ബ്ലോബുകൾ ഉണ്ടെന്നതുമാണ് പ്രധാന കാര്യം - ഇത് S3-ലെ സംഭരണവും GET/PUT പ്രവർത്തനങ്ങളും വിലകുറഞ്ഞതാക്കുന്നു. എന്നാൽ ഇത് കൂടുതൽ സങ്കീർണ്ണവും വേഗത കുറഞ്ഞതുമായ സ്ഥിരീകരണത്തിന്റെ ചിലവിലാണ് വരുന്നത്. വീണ്ടെടുക്കൽ വേഗതയെ സംബന്ധിച്ചിടത്തോളം, ഞങ്ങൾ ഒരു വ്യത്യാസവും ശ്രദ്ധിച്ചില്ല. Restic തുടർന്നുള്ള ബാക്കപ്പുകൾ (ആദ്യത്തേതിന് ശേഷം) കുറച്ച് സമയമെടുക്കും, പക്ഷേ കാര്യമായില്ല.

തിരഞ്ഞെടുപ്പിൽ അവസാനത്തേത് പക്ഷേ സമൂഹത്തിന്റെ വലുപ്പമായിരുന്നു.

ഞങ്ങൾ ബോർഗ് തിരഞ്ഞെടുത്തു.

കംപ്രഷനെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ

ബോർഗിന് അതിന്റെ ആയുധപ്പുരയിൽ മികച്ച ഒരു പുതിയ കംപ്രഷൻ അൽഗോരിതം ഉണ്ട് - zstd. കംപ്രഷൻ ഗുണനിലവാരം gzip-നേക്കാൾ മോശമല്ല, എന്നാൽ വളരെ വേഗതയുള്ളതാണ്. ഒപ്പം ഡിഫോൾട്ട് lz4 മായി വേഗതയിൽ താരതമ്യപ്പെടുത്താവുന്നതാണ്.

ഉദാഹരണത്തിന്, ഒരു MySQL ഡാറ്റാബേസ് ഡംപ് ഒരേ വേഗതയിൽ lz4 നേക്കാൾ രണ്ട് മടങ്ങ് നന്നായി കംപ്രസ്സുചെയ്യുന്നു. എന്നിരുന്നാലും, നെക്സ്റ്റ്ക്ലൗഡ് നോഡിന്റെ കംപ്രഷൻ അനുപാതത്തിൽ വളരെ ചെറിയ വ്യത്യാസമുണ്ടെന്ന് യഥാർത്ഥ ഡാറ്റയുമായുള്ള അനുഭവം കാണിക്കുന്നു.

ബോർഗിന് ബോണസ് കംപ്രഷൻ മോഡ് ഉണ്ട് - ഫയലിന് ഉയർന്ന എൻട്രോപ്പി ഉണ്ടെങ്കിൽ, കംപ്രഷൻ ഒട്ടും പ്രയോഗിക്കില്ല, ഇത് വേഗത വർദ്ധിപ്പിക്കുന്നു. സൃഷ്ടിക്കുമ്പോൾ ഓപ്‌ഷൻ വഴി പ്രവർത്തനക്ഷമമാക്കി
-C auto,zstd
zstd അൽഗോരിതത്തിനായി
അതിനാൽ ഈ ഓപ്ഷൻ ഉപയോഗിച്ച്, സ്ഥിരസ്ഥിതി കംപ്രഷനുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ, ഞങ്ങൾക്ക് ലഭിച്ചു
യഥാക്രമം 560Gb, 562Gb. മുകളിലെ ഉദാഹരണത്തിൽ നിന്നുള്ള ഡാറ്റ, ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ, കംപ്രഷൻ ഇല്ലാതെ ഫലം 628Gb ആണ്. 2GB വ്യത്യാസത്തിന്റെ ഫലം ഞങ്ങളെ അൽപ്പം ആശ്ചര്യപ്പെടുത്തി, പക്ഷേ ഞങ്ങൾ അത് തിരഞ്ഞെടുക്കുമെന്ന് ഞങ്ങൾ കരുതി. auto,zstd.

ബാക്കപ്പ് സ്ഥിരീകരണ രീതി

ഷെഡ്യൂളർ അനുസരിച്ച്, വെർച്വൽ മെഷീൻ ദാതാവിൽ നിന്നോ ക്ലയന്റിൽ നിന്നോ നേരിട്ട് സമാരംഭിക്കുന്നു, ഇത് നെറ്റ്‌വർക്ക് ലോഡ് വളരെയധികം കുറയ്ക്കുന്നു. കുറഞ്ഞത് അത് സ്വയം ഉയർത്തി ട്രാഫിക്ക് ഡ്രൈവ് ചെയ്യുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ്.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

അതേ സ്കീം ഉപയോഗിച്ച്, ഞങ്ങൾ ഒരു ആന്റിവൈറസ് ഉപയോഗിച്ച് ഫയലുകൾ പരിശോധിക്കുന്നു (വസ്തുതയ്ക്ക് ശേഷം). എല്ലാത്തിനുമുപരി, ഉപയോക്താക്കൾ നെക്സ്റ്റ്ക്ലൗഡിലേക്ക് വ്യത്യസ്‌ത കാര്യങ്ങൾ അപ്‌ലോഡ് ചെയ്യുന്നു, എല്ലാവർക്കും ആന്റിവൈറസ് ഇല്ല. പകരുന്ന സമയത്ത് പരിശോധന നടത്തുന്നത് വളരെയധികം സമയമെടുക്കുകയും ബിസിനസ്സിൽ ഇടപെടുകയും ചെയ്യുന്നു.

വ്യത്യസ്‌ത ടാഗുകളുള്ള വ്യത്യസ്‌ത നോഡുകളിൽ റണ്ണേഴ്‌സ് പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ സ്കേലബിളിറ്റി കൈവരിക്കാനാകും.
ഞങ്ങളുടെ മോണിറ്ററിംഗ് ഒരു വിൻഡോയിൽ GitLab API വഴി ബാക്കപ്പ് സ്റ്റാറ്റസുകൾ ശേഖരിക്കുന്നു; ആവശ്യമെങ്കിൽ, പ്രശ്നങ്ങൾ എളുപ്പത്തിൽ ശ്രദ്ധിക്കപ്പെടുകയും എളുപ്പത്തിൽ പ്രാദേശികവൽക്കരിക്കുകയും ചെയ്യും.

തീരുമാനം

തൽഫലമായി, ഞങ്ങൾ ബാക്കപ്പുകൾ നിർമ്മിക്കുന്നുവെന്നും ഞങ്ങളുടെ ബാക്കപ്പുകൾ സാധുവാണെന്നും അവയിൽ ഉണ്ടാകുന്ന പ്രശ്നങ്ങൾ കുറച്ച് സമയമെടുക്കുമെന്നും ഡ്യൂട്ടി അഡ്മിനിസ്ട്രേറ്ററുടെ തലത്തിൽ പരിഹരിക്കപ്പെടുമെന്നും ഞങ്ങൾക്ക് ഉറപ്പായും അറിയാം. tar.gz അല്ലെങ്കിൽ Bacula എന്നിവയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ബാക്കപ്പുകൾ വളരെ കുറച്ച് സ്ഥലം മാത്രമേ എടുക്കൂ.

അവലംബം: www.habr.com