നിങ്ങളുടെ ആപ്പ് ഡാറ്റാബേസ് ബാക്കപ്പ് ചെയ്യുന്നത് എങ്ങനെ (യഥാർത്ഥത്തിൽ റീസ്റ്റോർ ചെയ്യാനാകുന്ന രീതിയിൽ)

നിങ്ങളുടെ ആപ്പ് ഡാറ്റാബേസ് ബാക്കപ്പ് ചെയ്യാൻ, ഒരു ഷെഡ്യൂളിൽ അതിനെ ഒരു ഫയലിലേക്ക് എക്സ്പോർട്ട് ചെയ്യുക (Postgres-നായി സാധാരണ ഉപകരണം pg_dump ആണ്), പകർപ്പുകൾ ഡാറ്റാബേസിൽ നിന്ന് വേറിട്ട ഒരിടത്ത് സൂക്ഷിക്കുക, ഒന്ന് ശൂന്യമായ ഡാറ്റാബേസിലേക്ക് പതിവായി റീസ്റ്റോർ ചെയ്ത് അത് പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുക. അപകടസാധ്യതയുള്ള ഏതൊരു മാറ്റത്തിനും തൊട്ടുമുമ്പ് ഒരു അധിക ബാക്കപ്പ് എടുക്കുക. നിങ്ങളുടെ കോഡ് ബാക്കപ്പ്, അത് GitHub റിപ്പോസിറ്ററിയായാലും എക്സ്പോർട്ടായാലും, ഡാറ്റ ഉൾപ്പെടുത്തുന്നില്ല.

ചെറിയ ആപ്പ് നടത്തുന്നവർക്കും ഡാറ്റ നഷ്ടപ്പെടുമോ എന്ന ഭയം ഒഴിവാക്കാനും വേണ്ടിയാണ് ഈ ഗൈഡ്. മിക്ക AI-നിർമ്മിത ആപ്പുകളും Postgres ഉപയോഗിക്കുന്നതിനാൽ ഉദാഹരണങ്ങൾക്ക് Postgres ആണ് എടുത്തിരിക്കുന്നത്, പക്ഷേ തത്വങ്ങൾ ഏത് ഡാറ്റാബേസിനും ബാധകമാണ്.

ബാക്കപ്പ് എന്തൊക്കെ ഉൾക്കൊള്ളണം

ഒരു ആപ്പ് അതിന്റെ ഡാറ്റാബേസിനേക്കാൾ കൂടുതലാണ്. ഓരോ ബാക്കപ്പും ഏത് ഭാഗമാണ് സംരക്ഷിക്കുന്നതെന്ന് അറിയുക.

നിങ്ങൾക്ക് വീണ്ടും സൃഷ്ടിക്കാനാകാത്തത് ഡാറ്റയാണ്. കോഡ് വീണ്ടും എഴുതാം, ക്രമീകരണങ്ങൾ വീണ്ടും നൽകാം; ഉപഭോക്താക്കളുടെ ഓർഡറുകൾ അങ്ങനെയല്ല.

ഘട്ടം 1: എത്ര ഡാറ്റ നഷ്ടപ്പെടുത്താം എന്ന് തീരുമാനിക്കുക

രണ്ട് ചോദ്യങ്ങൾ നിങ്ങളുടെ ബാക്കപ്പ് പദ്ധതി നിശ്ചയിക്കുന്നു:

• അടുത്തിടെയുള്ള എത്ര ഡാറ്റ നഷ്ടപ്പെടുത്താൻ പറ്റും? ഒരു ദിവസം ഒരു തവണ ബാക്കപ്പ് ചെയ്യുകയും വൈകുന്നേരം ഡാറ്റാബേസ് തകരുകയും ചെയ്താൽ അന്നത്തെ മാറ്റങ്ങൾ നഷ്ടപ്പെടും. ഒരു ഹോബി ആപ്പിന് അത് ശരിയായിരിക്കാം. ഓർഡറുകൾ സ്വീകരിക്കുന്ന ആപ്പിന് അത് ശരിയാകണമെന്നില്ല.
• റീസ്റ്റോർ ചെയ്യുമ്പോൾ ആപ്പ് എത്ര നേരം പ്രവർത്തനരഹിതമാകാം? ചെറിയ ഡാറ്റാബേസ് മിനിറ്റുകൾക്കുള്ളിൽ റീസ്റ്റോർ ആകും. വലുതിന് ഏറെ സമയമെടുക്കാം; ആവശ്യം വരുന്നതിന് മുമ്പ് അത് അറിഞ്ഞിരിക്കണം.

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

ഘട്ടം 2: നിങ്ങളുടെ ഹോസ്റ്റ് ഇതിനകം എന്ത് ചെയ്യുന്നു എന്ന് പരിശോധിക്കുക

പല മാനേജ്ഡ് ഡാറ്റാബേസ് ദാതാക്കളും ഓട്ടോമാറ്റിക് ബാക്കപ്പ് എടുക്കുന്നു. ഇവ കണ്ടെത്തുക:

• നിങ്ങളുടെ പ്ലാനിൽ ബാക്കപ്പുകൾ ഓണാണോ, എത്ര തവണയാണ് അവ ഓടുന്നത്?
• അവ എത്ര നാൾ സൂക്ഷിക്കുന്നു?
• ഒരു പോയിന്റ്-ഇൻ-ടൈമിലേക്ക് റീസ്റ്റോർ ചെയ്യാനാകുമോ, അതോ ദിവസേനയുള്ള സ്നാപ്ഷോട്ടിലേക്ക് മാത്രമോ?
• ബാക്കപ്പ് ഡൗൺലോഡ് ചെയ്യാനാകുമോ, അതോ അവരുടെ സിസ്റ്റത്തിനുള്ളിൽ മാത്രം റീസ്റ്റോർ ചെയ്യാനാകുമോ?

ദാതാവിന്റെ ബാക്കപ്പുകൾ ഉപയോഗപ്രദമാണ്, പക്ഷേ അവയ്ക്ക് നിങ്ങളുടെ ഡാറ്റാബേസുമായി ഒരു പൊതു പരാജയ പോയിന്റുണ്ട്: അക്കൗണ്ട്. അക്കൗണ്ട് അടച്ചാലോ സസ്പെൻഡ് ചെയ്താലോ പ്രോജക്റ്റ് ഇല്ലാതാക്കിയാലോ ബാക്കപ്പുകളും പോയേക്കാം. അതുകൊണ്ടാണ് സ്വന്തമായി ഒരു പകർപ്പും വേണ്ടത്.

ഘട്ടം 3: pg_dump ഉപയോഗിച്ച് ഡംപ് എടുക്കുക

pg_dump ഒരു Postgres ഡാറ്റാബേസ് ഒരു ഫയലിലേക്ക് എക്സ്പോർട്ട് ചെയ്യുന്നു. ഇത് ഒരു സ്ഥിരതയുള്ള സ്നാപ്ഷോട്ട് വായിക്കുന്നതിനാൽ ഇത് പ്രവർത്തിക്കുമ്പോഴും ആപ്പ് ഓടിക്കൊണ്ടിരിക്കാം.

ആപ്പിന് ഇതിനകം ഉള്ള എൻവയോൺമെന്റ് വേരിയബിളിലെ കണക്ഷൻ സ്ട്രിംഗ് ഉപയോഗിക്കുന്ന ഒരു സാധാരണ കമാൻഡ്:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

ഓപ്ഷനുകൾ എന്ത് ചെയ്യുന്നു:

• --format=custom pg_restore വായിക്കാനാകുന്ന കംപ്രസ് ചെയ്ത ഫയൽ എഴുതുന്നു, പിന്നീട് ഒറ്റ ടേബിളുകൾ റീസ്റ്റോർ ചെയ്യാനും അനുവദിക്കുന്നു. വായിക്കാവുന്ന .sql ഫയൽ വേണമെങ്കിൽ --format=plain ഉപയോഗിക്കുക.
• --no-owner ഉടമസ്ഥാവകാശ കമാൻഡുകൾ ഒഴിവാക്കുന്നു, ഇത് വേറെ ഡാറ്റാബേസിലേക്ക് റീസ്റ്റോർ ചെയ്യുന്നത് എളുപ്പമാക്കുന്നു.
• ഫയൽ പേരിലെ തീയതി ബാക്കപ്പുകളെ വേർതിരിച്ചു നിർത്തുന്നു.

pg_dump-ന്റെ പതിപ്പ് നിങ്ങളുടെ ഡാറ്റാബേസിന്റെ Postgres പതിപ്പിന് തുല്യമോ പുതിയതോ ആയിരിക്കണം. പഴയ pg_dump പ്രവർത്തിക്കാൻ വിസമ്മതിച്ചേക്കാം.

AI ഉപയോഗിച്ചാണ് നിർമ്മിക്കുന്നതെങ്കിലും കമാൻഡ് ലൈനിൽ തൊടാൻ ആഗ്രഹമില്ലെങ്കിൽ ഇങ്ങനെ ചോദിക്കാം:

കസ്റ്റം ഫോർമാറ്റിൽ pg_dump ഉപയോഗിച്ച് ആപ്പിന്റെ ഡാറ്റാബേസിന്റെ ബാക്കപ്പ് ഉണ്ടാക്കുക, ഫയൽ പേരിൽ ഇന്നത്തെ തീയതി ഉണ്ടാകട്ടെ. കണക്ഷൻ സ്ട്രിംഗോ മറ്റ് രഹസ്യങ്ങളോ പ്രിന്റ് ചെയ്യരുത്. കഴിഞ്ഞാൽ ഫയലിന്റെ പേരും വലിപ്പവും പറയുക.

ഘട്ടം 4: ഓട്ടോമേറ്റ് ചെയ്യുക

മാനുവൽ ബാക്കപ്പുകൾ മറന്നുപോകും. നിങ്ങളുടെ സെറ്റപ്പ് പിന്തുണയ്ക്കുന്ന ഏത് മാർഗവും ഉപയോഗിച്ച് ഓട്ടോമേറ്റ് ചെയ്യുക:

• നിങ്ങളുടെ ഡാറ്റാബേസ് ദാതാവിന്റെ ഷെഡ്യൂൾ ചെയ്ത ബാക്കപ്പുകൾ, അവർ നൽകുന്നുണ്ടെങ്കിൽ.
• ഒരു സെർവറിലോ CI സേവനത്തിലോ ഉള്ള ഷെഡ്യൂൾ ചെയ്ത ജോബ്, അത് pg_dump ഓടിച്ച് ഫയൽ സ്റ്റോറേജിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നു.
• നിങ്ങളുടെ ഡാറ്റാബേസുമായി ബന്ധിപ്പിക്കുന്ന ഒരു ഹോസ്റ്റ് ചെയ്ത ബാക്കപ്പ് സേവനം.

ഏതു തിരഞ്ഞെടുത്താലും, ബാക്കപ്പ് പരാജയപ്പെടുമ്പോൾ അത് നിങ്ങളെ അറിയിക്കണം. മൂന്നു മാസമായി നിശബ്ദമായി പരാജയപ്പെടുന്ന ബാക്കപ്പ് ജോബ് ആണ് ക്ലാസിക് ഭീകര കഥ.

ഘട്ടം 5: പകർപ്പുകൾ മറ്റൊരിടത്ത് സൂക്ഷിക്കുക

ഡാറ്റയുടെ മൂന്ന് പകർപ്പുകൾ, രണ്ട് വ്യത്യസ്ത തരം സ്റ്റോറേജിൽ, ഒന്ന് സൈറ്റിന് പുറത്ത്, എന്നതിനെ പലപ്പോഴും 3-2-1 നിയമം എന്ന് വിളിക്കുന്നു. ചെറിയ ആപ്പിന് പ്രായോഗിക രൂപം ഇതാണ്:

• ലൈവ് ഡാറ്റാബേസ്
• ദാതാവിന്റെ സ്വന്തം ഓട്ടോമാറ്റിക് ബാക്കപ്പുകൾ
• വേറെ അക്കൗണ്ടിലുള്ള ഒരു ഓബ്ജക്റ്റ് സ്റ്റോറേജ് ബക്കറ്റ് പോലുള്ള വേറിട്ട സ്റ്റോറേജിൽ നിങ്ങളുടെ സ്വന്തം ഡംപുകൾ

കൂടാതെ:

• പ്രവേശനം പരിമിതപ്പെടുത്തുക. ബാക്കപ്പിൽ ഓരോ ഉപയോക്താവിന്റെയും ഡാറ്റയുണ്ട്. ലൈവ് ഡാറ്റാബേസ് പോലെ അതിനെ കൈകാര്യം ചെയ്യുക.
• ഒരു നിലനിർത്തൽ നയം വയ്ക്കുക. ഉദാഹരണത്തിന് ദിവസേനയുള്ളവ രണ്ടാഴ്ചയും പ്രതിമാസമുള്ളവ ഒരു വർഷവും. പഴയവ മനഃപൂർവം ഇല്ലാതാക്കുക; അഭ്യർത്ഥന വരുമ്പോൾ വ്യക്തിഗത ഡാറ്റ ഇല്ലാതാക്കാൻ സ്വകാര്യതാ നിയമങ്ങൾ ആവശ്യപ്പെടാമെന്നും ഓർക്കുക.
• ബാക്കപ്പുകൾ ഒരിക്കലും Git-ൽ കമ്മിറ്റ് ചെയ്യരുത്. റിപ്പോസിറ്ററിയിലെ ഡംപ് ഒരു ഡാറ്റാ ചോർച്ച കാത്തിരിക്കുന്നതാണ്.

ഘട്ടം 6: റീസ്റ്റോർ പരീക്ഷിക്കുക

ഒരു ബാക്കപ്പ് അവസാനം വിജയിച്ച റീസ്റ്റോർ പോലെ മാത്രം നല്ലതാണ്. കുറഞ്ഞത് ഓരോ കുറച്ച് മാസത്തിലും, ബാക്കപ്പ് പ്രക്രിയയിൽ മാറ്റം വരുമ്പോഴെല്ലാം:

1. ഒരു പുതിയ, ശൂന്യമായ ഡാറ്റാബേസ് ഉണ്ടാക്കുക. പരീക്ഷിക്കാൻ ഒരിക്കലും ലൈവ് ഡാറ്റാബേസിന് മുകളിൽ റീസ്റ്റോർ ചെയ്യരുത്.
2. ഏറ്റവും പുതിയ ബാക്കപ്പ് അതിലേക്ക് റീസ്റ്റോർ ചെയ്യുക:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

സാദാ .sql ഫയലിന്, പകരം psql "$TEST_DATABASE_URL" -f backup.sql ഉപയോഗിക്കുക.

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

ഘട്ടം 7: അപകടസാധ്യതയുള്ള മാറ്റങ്ങൾക്ക് മുമ്പ് ബാക്കപ്പ് എടുക്കുക

ഇതിന് തൊട്ടുമുമ്പ് ഒരു പുതിയ ബാക്കപ്പ് എടുക്കുക:

• നിരകൾ ഡ്രോപ്പ് ചെയ്യുകയോ പേര് മാറ്റുകയോ ചെയ്യുന്ന ഒരു ഡാറ്റാബേസ് മൈഗ്രേഷൻ ഓടിക്കുമ്പോൾ
• വലിയ തോതിൽ ഡാറ്റ ഇംപോർട്ട് ചെയ്യുമ്പോൾ
• ഒരു AI ഏജന്റ് ഡാറ്റാ മോഡലിൽ വലിയ മാറ്റങ്ങൾ വരുത്താൻ അനുവദിക്കുമ്പോൾ
• പഴയ രേഖകൾ ഇല്ലാതാക്കുമ്പോൾ

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

സാധാരണ തെറ്റുകൾ

• Git അല്ലെങ്കിൽ കോഡ് എക്സ്പോർട്ട് ബാക്കപ്പാണെന്ന് കരുതൽ. അതിൽ കോഡുണ്ട്, ഡാറ്റയില്ല.
• ഒരിക്കലും റീസ്റ്റോർ പരീക്ഷിക്കാതിരിക്കൽ. ആവശ്യം വരുമ്പോൾ മാത്രമാണ് പല ബാക്കപ്പുകളും ശൂന്യമോ അപൂർണ്ണമോ വായിക്കാനാകാത്തതോ ആണെന്ന് തെളിയുന്നത്.
• ബാക്കപ്പുകൾ ഡാറ്റാബേസിന്റെ അതേ അക്കൗണ്ടിൽ സൂക്ഷിക്കൽ. ഒരു അക്കൗണ്ട് ഹാക്ക് ചെയ്താലോ അടച്ചാലോ രണ്ടും നഷ്ടപ്പെടും.
• അപ്‌ലോഡ് ചെയ്ത ഫയലുകൾ മറക്കൽ. ഡാറ്റാബേസ് ഫയലിന്റെ പാത്ത് മാത്രമാണ് സൂക്ഷിക്കുന്നത്; ചിത്രം ജീവിക്കുന്നത് സ്റ്റോറേജിലാണ്.
• ബാക്കപ്പ് സ്ക്രിപ്റ്റുകളിൽ രഹസ്യങ്ങൾ വയ്ക്കൽ. കണക്ഷൻ സ്ട്രിംഗ് സ്ക്രിപ്റ്റിന്റെ ടെക്സ്റ്റിൽ നിന്നല്ല, എൻവയോൺമെന്റ് വേരിയബിളിൽ നിന്ന് വായിക്കുക. API കീകൾ സുരക്ഷിതമായി സൂക്ഷിക്കുന്നത് എങ്ങനെ കാണുക.

ബാക്കപ്പുകളും Mythex-ഉം

Mythex പ്രോജക്റ്റുകൾക്ക് സമർപ്പിത Postgres ഡാറ്റാബേസ് ഉണ്ടാകാം, അതിന്റെ കണക്ഷൻ വിവരങ്ങൾ വർക്ക്‌സ്പേസിലേക്കും പ്രസിദ്ധീകരിച്ച ആപ്പിലേക്കും നൽകപ്പെടുന്നു. ഡാറ്റാബേസ് ബാക്കപ്പ് അല്ലെങ്കിൽ റീസ്റ്റോർ ഫീച്ചർ Mythex ഡോക്സിൽ വിവരിച്ചിട്ടില്ല, അതിനാൽ സ്വന്തം പ്ലാൻ ചെയ്യുക: ഒരു ഡംപ് ഉണ്ടാക്കാൻ ഏജന്റിനോട് ആവശ്യപ്പെടുക, ഡൗൺലോഡ് ചെയ്ത് സുരക്ഷിതമായി സൂക്ഷിക്കുക, പ്രത്യേകിച്ച് വലിയ മാറ്റങ്ങൾക്ക് മുമ്പ്. പ്രോജക്റ്റ് എക്സ്പോർട്ടിൽ (Pro) നിങ്ങളുടെ കോഡ് ഉണ്ടാകും, രഹസ്യങ്ങളും node_modules-ഉം ഒഴിവാക്കിയിരിക്കും; ഡാറ്റാബേസ് വരികൾ അതിൽ ഉണ്ടാകില്ല. Database, Data ownership എന്നിവ ഡോക്സിൽ കാണുക. ഡാറ്റാബേസിനെക്കുറിച്ച് കൂടുതൽ അറിയാൻ എന്താണ് Postgres വായിക്കുക.

ബാക്കപ്പ് ചെക്ക്‌ലിസ്റ്റ്

• എത്ര ഡാറ്റ നഷ്ടപ്പെടുത്താം, എത്ര നേരം പ്രവർത്തനരഹിതമാകാം എന്ന് തീരുമാനിച്ചു
• ഡാറ്റാബേസ് ദാതാവ് നൽകുന്ന ഓട്ടോമാറ്റിക് ബാക്കപ്പുകൾ പരിശോധിച്ചു
• സ്വന്തം ഡംപ് ഷെഡ്യൂളിൽ ഓടുന്നു, പരാജയങ്ങൾ അലേർട്ട് ചെയ്യുന്നു
• പകർപ്പുകൾ ഡാറ്റാബേസിൽ നിന്ന് വേറിട്ട്, പരിമിതമായ പ്രവേശനത്തോടെ സൂക്ഷിക്കുന്നു
• നിലനിർത്തൽ നയം എഴുതി വച്ചിട്ടുണ്ട്
• അപ്‌ലോഡ് ചെയ്ത ഫയലുകളും ഡാറ്റാബേസിനൊപ്പം ബാക്കപ്പ് ചെയ്യുന്നു
• റീസ്റ്റോർ ശൂന്യമായ ഡാറ്റാബേസിൽ പരീക്ഷിച്ചു, വരി എണ്ണം പരിശോധിച്ചു
• അപകടസാധ്യതയുള്ള ഓരോ മാറ്റത്തിനും മുമ്പ് ബാക്കപ്പ് എടുക്കുന്നു

ചോദ്യങ്ങൾ