Pritunl: നിയന്ത്രണാവസ്ഥ vs സൃഷ്ടിച്ച പ്രൊഫൈൽ

ഒരു ആർക്കൈവ് പ്രവർത്തിക്കുന്ന Pritunl വിന്യാസം പുനഃസ്ഥാപിക്കുന്നു; മറ്റൊന്ന് അതിന്റെ ചിത്രം മാത്രം പുനഃസ്ഥാപിക്കുന്നു. ക്ലയന്റ് പ്രൊഫൈൽ, ഹോസ്റ്റ് കോൺഫിഗറേഷന്റെ പകർപ്പ്, സ്റ്റേറ്റ് ഡയറക്ടറിയുടെ tarball എല്ലാം ബാക്കപ്പ് പോലെ തോന്നുന്നു, അവയിൽ ഒന്നും ഒറ്റയ്ക്ക് Pritunl കൈകാര്യം ചെയ്യുന്ന സംഘടനകൾ, ഉപയോക്താക്കൾ, സെർവർ നിർവചനങ്ങൾ എന്നിവ തിരികെ കൊണ്ടുവരുന്നില്ല. വ്യത്യാസം ഉടമസ്ഥതയിലാണ്: അവസ്ഥയുടെ ഒരു ഭാഗം ഡാറ്റാബേസിനും, ഒരു ഭാഗം ഹോസ്റ്റിനും ഉള്ളതാണ്, മറ്റൊരു ഭാഗം വീണ്ടും സൃഷ്ടിച്ച ഔട്ട്പുട്ടാണ്. തെറ്റായ പാളി തിരഞ്ഞെടുത്താൽ, പുനഃസ്ഥാപനം ആരംഭിച്ച്, കേട്ട്, ഒന്നും അറിയാത്ത ഒരു സെർവർ സൃഷ്ടിക്കും. ഈ താരതമ്യം മൂന്ന് പാളികളെ വേർതിരിക്കുന്നു, നിങ്ങൾ സൂക്ഷിക്കുന്ന ആർക്കൈവ് നിങ്ങൾ പുനഃസ്ഥാപിക്കുന്ന പരാജയവുമായി പൊരുത്തപ്പെടുന്നു.

രണ്ട് വസ്തുക്കൾ ബാക്കപ്പ് പോലെ തോന്നുന്നു, ഒന്ന് മാത്രം സേവനം പുനഃസ്ഥാപിക്കുന്നു

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

ഹോസ്റ്റ് കോൺഫിഗറേഷന്റെ പകർപ്പും അത്രതന്നെ ഭാഗികമാണ്. /etc/pritunl.conf ഹോസ്റ്റ്-തല ക്രമീകരണങ്ങൾ വയ്ക്കുന്നു, ഡാറ്റാബേസ് എങ്ങനെ എത്തിച്ചേരാം എന്നത് ഉൾപ്പെടെ, VPN വസ്തുക്കൾ സ്വയം ഉൾക്കൊള്ളുന്നില്ല.

ഡാറ്റാബേസ് എന്താണ് കൈവശം വയ്ക്കുന്നത്, ഹോസ്റ്റ് എന്താണ് കൈവശം വയ്ക്കുന്നത്

Pritunl സെർവർ നിർവചനങ്ങൾ, ഉപയോക്താക്കൾ, സംഘടനകൾ, കീകൾ എന്നിവ MongoDB-യിൽ സൂക്ഷിക്കുന്നു. ആ ഡാറ്റാബേസ് അധികാരമുള്ള നിയന്ത്രണ തലമാണ്, ഡിസ്കിൽ സൃഷ്ടിക്കുന്ന ഓരോ OpenVPN ഫയലും അതിൽ നിന്ന് ഉരുത്തിരിഞ്ഞ ഔട്ട്പുട്ടാണ്. സൃഷ്ടിച്ച ഫയലിൽ നേരിട്ട് വരുത്തുന്ന മാറ്റം അടുത്ത പുനഃസൃഷ്ടി വരെ നിലനിൽക്കും, പിന്നീട് അപ്രത്യക്ഷമാകും, അതുകൊണ്ടാണ് റൺടൈം ഫയലുകൾ തിരുത്തുന്നത് ശാശ്വതമായ പരിഹാരമല്ലാത്തത്. അതേ നിയമം ഫലപ്രദമായ റൂട്ടുകൾക്കും ഇന്റർഫേസുകൾക്കും ബാധകമാണ്: അവ നിയന്ത്രണ തലം എന്ത് നിർമ്മിച്ചു എന്ന് വിവരിക്കുന്നു, എന്ത് നിർമ്മിക്കണം എന്നല്ല.

ഹോസ്റ്റ് ചെറിയ പക്ഷേ കൈമാറ്റം ചെയ്യാനാകാത്ത മൂല്യങ്ങളുടെ ഒരു കൂട്ടം നൽകുന്നു. അവയിലൊന്ന് /var/lib/pritunl/pritunl.uuid, ആ പ്രത്യേക നോഡിന്റെ ഐഡന്റിറ്റി.

ആ ഐഡന്റിറ്റി ക്ലസ്റ്ററിൽ ഏറ്റവും പ്രധാനമാണ്. പകരം ഹോസ്റ്റിന് സജീവ നോഡിന്റെ UUID-യുടെ ക്ലോണിന് പകരം സ്വന്തം രജിസ്ട്രേഷൻ ആവശ്യമാണ്, അല്ലെങ്കിൽ രണ്ടും ഒരേ ഐഡന്റിറ്റിക്കായി പോരാടും. ഓരോ ഹോസ്റ്റ്, അതിന്റെ UUID, അത് ചൂണ്ടിക്കാണിക്കുന്ന ഡാറ്റാബേസ് എന്നിവയ്ക്കിടയിലുള്ള മാപ്പിംഗ് രേഖപ്പെടുത്തുക, കാരണം ഒരു ഡാറ്റാബേസ് ഡംപ് ഏത് ഹോസ്റ്റ് ക്രമീകരണങ്ങൾ ഏത് യന്ത്രത്തിന്റേതായിരുന്നു എന്ന് വിവരിക്കുന്നില്ല. സോഫ്റ്റ്വെയർ പതിപ്പുകളും പൊതു എൻഡ്പോയിന്റ് പേരുകളും അതേ രേഖയിൽ വരുന്നു.

സ്ഥിരതയുള്ള ഡംപ് എടുക്കുക, ഡയറക്ടറി പകർപ്പല്ല

സേവനം എഴുതുമ്പോൾ MongoDB ഡാറ്റ ഡയറക്ടറി പകർത്തുന്നത് ഉപയോഗയോഗ്യമായ ഡാറ്റാബേസ് രൂപപ്പെടുത്തിയേക്കില്ലാത്ത ഫയലുകൾ സൃഷ്ടിക്കുന്നു. പകരം ഡാറ്റാബേസ് പിന്തുണയ്ക്കുന്ന ഡംപ് പാത്ത് ഉപയോഗിക്കുക, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള ടോപ്പോളജിക്കെതിരെ പ്രവർത്തിപ്പിക്കുക:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

ഒറ്റ ഹോസ്റ്റ് ആ ലളിതമായ രൂപം സഹിക്കുന്നു. റെപ്ലിക്ക സെറ്റിന് സ്ഥിരതയുള്ള സമയബിന്ദു ആവശ്യമാണ്, oplog അടിസ്ഥാനമാക്കിയ ഡംപിന് സാധാരണ ഡംപിനില്ലാത്ത ആവശ്യകതകളുണ്ട്. പിന്തുണയ്ക്കുന്ന നടപടിക്രമം നിങ്ങളുടെ MongoDB പതിപ്പിനെയും ടോപ്പോളജിയെയും ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഡാറ്റ ഡയറക്ടറിയുടെ സാന്നിധ്യത്തിൽ നിന്ന് അത് അനുമാനിക്കരുത്. ഹോസ്റ്റ് പാളി ഡംപിന് അരികിൽ, അതേ റണ്ണിൽ, അതേ ടൈംസ്റ്റാമ്പോടെ ആർക്കൈവ് ചെയ്യുക.

ആവശ്യമാകുന്നതിന് മുമ്പ് പുനഃസ്ഥാപനം പരിശീലിക്കുക

ആരും പുനഃസ്ഥാപിക്കാത്ത ബാക്കപ്പ് ഒരു സിദ്ധാന്തമാണ്. സേവനം വേർതിരിച്ച ശൃംഖലയിൽ നിർമ്മിക്കുക, ഡംപ് പുനഃസ്ഥാപിക്കുക, ഹോസ്റ്റ് ഫയലുകൾ തിരികെ വയ്ക്കുക:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

അവസാനമായി, പഴയ സ്നാപ്പ്ഷോട്ട് പഴയ തീരുമാനങ്ങൾ പുനഃസ്ഥാപിക്കുന്നു എന്ന് ഓർക്കുക. ഒരു അഡ്മിനിസ്ട്രേറ്റർ ഡംപ് എടുത്തതിന് ശേഷം ഒരു ഐഡന്റിറ്റി പ്രവർത്തനരഹിതമാക്കിയിരുന്നെങ്കിൽ, പുനഃസ്ഥാപനം അത് വീണ്ടും പ്രവർത്തനക്ഷമമാക്കും. പുനഃസ്ഥാപനത്തിന് ശേഷമുള്ള അനുരഞ്ജനം നടപടിക്രമത്തിന്റെ ഭാഗമാണ്, വൈകിയ ചിന്തയുടെ ഭാഗമല്ല.