உங்கள் ஆப் டேட்டாபேஸை எவ்வாறு பேக்கப் செய்வது (உண்மையில் மீட்டெடுக்கவும்)

உங்கள் ஆப் டேட்டாபேஸை பேக்கப் செய்ய, அதை திட்டமிட்ட நேரத்தில் ஒரு கோப்பாக ஏற்றுமதி செய்யுங்கள் (Postgres-க்கு நிலையான கருவி pg_dump), நகல்களை டேட்டாபேஸிலிருந்து தனியான இடத்தில் சேமியுங்கள், மேலும் அடிக்கடி ஒரு நகலை காலியான டேட்டாபேஸில் மீட்டெடுத்து அது சரியாக வேலை செய்கிறதா என்று சோதியுங்கள். ஆபத்தான மாற்றத்துக்கு முன் கூடுதல் பேக்கப் எடுங்கள். உங்கள் கோட் பேக்கப் (GitHub repository அல்லது export) தரவை உள்ளடக்காது.

இந்த வழிகாட்டி சிறிய ஆப் நடத்தி, அதை இழப்பது பற்றிய கவலையை குறைக்க விரும்புபவர்களுக்கானது. எடுத்துக்காட்டுகளில் Postgres பயன்படுத்தப்படுகிறது, ஏனெனில் பெரும்பாலான AI-உருவாக்கிய ஆப்கள் அதைப் பயன்படுத்துகின்றன, ஆனால் இந்த கொள்கைகள் எந்த டேட்டாபேஸுக்கும் பொருந்தும்.

பேக்கப்பில் என்ன அடங்க வேண்டும்

ஒரு ஆப் என்பது அதன் டேட்டாபேஸை விட அதிகம். ஒவ்வொரு பேக்கப்பும் எந்த பகுதியைப் பாதுகாக்கிறது என்பதை அறிந்திருங்கள்.

மீண்டும் உருவாக்க முடியாத பகுதி தரவுதான். கோடை மீண்டும் எழுதலாம், அமைப்புகளை மீண்டும் உள்ளிடலாம்; வாடிக்கையாளர்களின் ஆர்டர்களை அவ்வாறு மீட்க முடியாது.

படி 1: எவ்வளவு இழக்கலாம் என்று முடிவு செய்யுங்கள்

இரு கேள்விகள் உங்கள் பேக்கப் திட்டத்தை வடிவமைக்கின்றன:

• சமீபத்திய எவ்வளவு தரவை இழக்கத் தயாராக இருக்கிறீர்கள்? ஒரு நாளுக்கு ஒருமுறை பேக்கப் எடுத்து மாலையில் டேட்டாபேஸ் பழுதடைந்தால், அன்றைய மாற்றங்களை இழப்பீர்கள். ஒரு சிறிய hobby ஆப்புக்கு இது பரவாயில்லை. ஆர்டர் எடுக்கும் ஆப்புக்கு இது ஏற்கத்தக்கதாக இருக்காது.
• மீட்டெடுக்கும்போது ஆப் எவ்வளவு நேரம் நிற்கக்கூடும்? சிறிய டேட்டாபேஸ் சில நிமிடங்களில் மீட்கப்படும். பெரிய டேட்டாபேஸ் அதிக நேரம் எடுக்கலாம், அதை தேவைப்படுவதற்கு முன்பே தெரிந்துகொள்ளுங்கள்.

பெரும்பாலான சிறிய ஆப்களுக்கு தினசரி தானியங்கி பேக்கப்பும், ஆபத்தான மாற்றங்களுக்கு முன் கைமுறை பேக்கப்பும் ஒரு நல்ல தொடக்கம். பணம் அல்லது மருத்துவத் தரவு உள்ள ஆப்கள் அடிக்கடி பேக்கப் அல்லது point-in-time recovery (கடைசி பேக்கப் மட்டுமல்ல, எந்த ஒரு நேரத்துக்கும் மீட்டெடுக்கும் வசதி) உள்ள நிர்வகிக்கப்பட்ட டேட்டாபேஸ் தேவைப்படும்.

படி 2: உங்கள் ஹோஸ்ட் ஏற்கனவே என்ன செய்கிறது என்று சரிபாருங்கள்

பல நிர்வகிக்கப்பட்ட டேட்டாபேஸ் வழங்குநர்கள் தானியங்கி பேக்கப் எடுக்கிறார்கள். பின்வருவனவற்றை கண்டறியுங்கள்:

• உங்கள் திட்டத்தில் பேக்கப் இயக்கத்தில் உள்ளதா, எவ்வளவு அடிக்கடி ஓடுகின்றன?
• அவை எவ்வளவு காலம் வைக்கப்படுகின்றன?
• ஒரு குறிப்பிட்ட நேரத்துக்கு மீட்டெடுக்க முடியுமா, அல்லது தினசரி ஸ்னாப்ஷாட்டுக்கு மட்டுமா?
• பேக்கப்பை பதிவிறக்க முடியுமா, அல்லது அவர்களின் அமைப்புக்குள் மட்டுமே மீட்டெடுக்க முடியுமா?

வழங்குநர் பேக்கப்கள் பயனுள்ளவைதான், ஆனால் அவை உங்கள் டேட்டாபேஸுடன் ஒரே தோல்விப் புள்ளியை பகிர்கின்றன: கணக்கு. கணக்கு மூடப்பட்டாலோ, இடைநிறுத்தப்பட்டாலோ, அல்லது திட்டம் நீக்கப்பட்டாலோ பேக்கப்களும் போய்விடலாம். அதனால்தான் உங்கள் சொந்த நகலும் தேவை.

படி 3: pg_dump மூலம் dump எடுங்கள்

pg_dump ஒரு Postgres டேட்டாபேஸை கோப்பாக ஏற்றுமதி செய்கிறது. இது ஒரு நிலையான snapshot-ஐ வாசிக்கிறது, எனவே அது வேலை செய்யும்போதும் ஆப் இயங்கிக்கொண்டிருக்கலாம்.

உங்கள் ஆப் ஏற்கனவே environment variable-ல் வைத்திருக்கும் connection string-ஐப் பயன்படுத்தும் ஒரு வழக்கமான கட்டளை:

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-ஐ custom வடிவத்தில் பயன்படுத்தி ஆப்பின் டேட்டாபேஸின் பேக்கப்பை உருவாக்குங்கள், கோப்பின் பெயரில் இன்றைய தேதி இருக்கட்டும். Connection string அல்லது எந்த ரகசியத்தையும் அச்சிட வேண்டாம். முடிந்ததும் கோப்பின் பெயரையும் அளவையும் சொல்லுங்கள்.

படி 4: தானியங்குபடுத்துங்கள்

கைமுறை பேக்கப்கள் மறக்கப்படும். உங்கள் அமைப்பு ஆதரிக்கும் வழியில் அவற்றை தானியங்குபடுத்துங்கள்:

• உங்கள் டேட்டாபேஸ் வழங்குநரின் திட்டமிட்ட பேக்கப்கள், அவை வழங்கினால்.
• திட்டமிடப்பட்ட job, ஒரு சர்வர் அல்லது CI சேவையில், இது pg_dump இயக்கி கோப்பை சேமிப்பகத்துக்கு பதிவேற்றும்.
• ஹோஸ்ட் செய்யப்பட்ட பேக்கப் சேவை, இது உங்கள் டேட்டாபேஸுடன் இணைகிறது.

எதைத் தேர்ந்தெடுத்தாலும், பேக்கப் தோல்வியடையும்போது அது உங்களுக்குத் தெரிவிக்கும்படி செய்யுங்கள். மூன்று மாதங்களாக அமைதியாகத் தோல்வியடைந்த பேக்கப் job என்பது மிகவும் பொதுவான பயங்கரக் கதை.

படி 5: நகல்களை வேறிடத்தில் சேமியுங்கள்

பொதுவான விதி 3-2-1 என்று அழைக்கப்படுகிறது: உங்கள் தரவின் மூன்று நகல்கள், இரண்டு வெவ்வேறு வகை சேமிப்பகங்களில், ஒன்று தளத்துக்கு வெளியே. ஒரு சிறிய ஆப்புக்கு நடைமுறையான வடிவம்:

• நேரடி டேட்டாபேஸ்
• வழங்குநரின் சொந்த தானியங்கி பேக்கப்கள்
• வேறு கணக்கில் உள்ள object storage bucket போன்ற தனி சேமிப்பகத்தில் உங்கள் சொந்த dump-கள்

மேலும்:

• அணுகலை கட்டுப்படுத்துங்கள். பேக்கப்பில் ஒவ்வொரு பயனரின் தரவும் இருக்கும். அதை நேரடி டேட்டாபேஸைப் போல கருதுங்கள்.
• தக்கவைப்புக் கொள்கையை வையுங்கள். உதாரணமாக, தினசரி பேக்கப்கள் இரண்டு வாரங்களுக்கும், மாதாந்திரம் ஒரு வருடத்துக்கும். பழையவற்றை வேண்டுமென்றே நீக்குங்கள்; தனிப்பட்ட தரவை கோரிக்கையின் பேரில் நீக்க சில தனியுரிமை சட்டங்கள் உங்களைக் கட்டாயப்படுத்தலாம் என்பதை நினைவில் வையுங்கள்.
• பேக்கப்களை ஒருபோதும் Git-ல் commit செய்யாதீர்கள். Repository-யில் உள்ள dump ஒரு தரவுக் கசிவுக்கான காத்திருப்பு.

படி 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-உருவாக்கிய ஆப்பில், ஒரு அம்சத்தின் பகுதியாக ஏஜென்ட் அட்டவணை கட்டமைப்பை மாற்றலாம். Checkpoints மற்றும் பதிப்பு கட்டுப்பாடு உங்கள் கோடை பின்வாங்கச் செய்யும், ஆனால் நீக்கப்பட்ட வரிசைகளை மீண்டும் கொண்டுவராது. பெரிய மாற்றத்துக்கு முன் முப்பது வினாடி பேக்கப் மலிவான பாதுகாப்பு.

பொதுவான தவறுகள்

• Git அல்லது கோட் ஏற்றுமதி ஒரு பேக்கப் என்று நினைப்பது. அதில் கோடு உள்ளது, தரவு இல்லை.
• மீட்டெடுப்பை ஒருபோதும் சோதிக்காதது. பல பேக்கப்கள் தேவைப்படும்போதுதான் வெறுமையாகவோ, பகுதியாகவோ, படிக்க முடியாததாகவோ மாறுகின்றன.
• டேட்டாபேஸின் அதே கணக்கில் பேக்கப்களை வைத்திருப்பது. ஒரு பாதிக்கப்பட்ட அல்லது மூடப்பட்ட கணக்கு இரண்டையும் இழக்கச் செய்கிறது.
• பதிவேற்றிய கோப்புகளை மறப்பது. டேட்டாபேஸ் கோப்பின் பாதையை சேமிக்கிறது; படம் சேமிப்பகத்தில் உள்ளது.
• பேக்கப் ஸ்கிரிப்ட்களில் ரகசியங்களை வைப்பது. Connection string-ஐ ஸ்கிரிப்டின் உரையிலிருந்து அல்ல, environment variable-லிருந்து வாசியுங்கள். API விசைகளை பாதுகாப்பாக வைப்பது எப்படி என்பதைப் பாருங்கள்.

பேக்கப்களும் Mythex-உம்

Mythex திட்டங்களுக்கு பிரத்யேக Postgres டேட்டாபேஸ் இருக்கலாம், அதன் இணைப்பு விவரங்கள் workspace-க்கும் வெளியிடப்பட்ட ஆப்புக்கும் செலுத்தப்படுகின்றன. Mythex ஆவணங்கள் டேட்டாபேஸ் பேக்கப் அல்லது மீட்டெடுப்பு அம்சத்தை விவரிக்கவில்லை, எனவே உங்கள் சொந்த திட்டத்தை வகுங்கள்: ஏஜென்ட்டிடம் dump எடுக்கச் சொல்லுங்கள், அதைப் பதிவிறக்கி பாதுகாப்பான இடத்தில் வையுங்கள், குறிப்பாக பெரிய மாற்றங்களுக்கு முன். திட்ட export (Pro) உங்கள் கோடை கொண்டுள்ளது; ரகசியங்களும் node_modules-உம் விடப்படுகின்றன; அதில் டேட்டாபேஸ் வரிசைகள் இல்லை. ஆவணங்களில் Database மற்றும் Data ownership பார்க்கவும். டேட்டாபேஸ் பற்றி மேலும் அறிய, Postgres என்றால் என்ன என்பதைப் படியுங்கள்.

பேக்கப் சரிபட்டியல்

• எவ்வளவு தரவை இழக்கலாம், எவ்வளவு நேரம் நிற்கலாம் என்று முடிவு செய்தேன்
• என் டேட்டாபேஸ் ஹோஸ்ட் வழங்கும் தானியங்கி பேக்கப்களை சரிபார்த்தேன்
• என் சொந்த dump திட்டமிட்டபடி ஓடுகிறது, தோல்விகள் எனக்குத் தெரிவிக்கின்றன
• நகல்கள் டேட்டாபேஸிலிருந்து தனியாக, கட்டுப்படுத்தப்பட்ட அணுகலுடன் சேமிக்கப்பட்டுள்ளன
• தக்கவைப்புக் கொள்கை எழுதி வைக்கப்பட்டுள்ளது
• பதிவேற்றிய கோப்புகளும் டேட்டாபேஸுடன் பேக்கப் செய்யப்படுகின்றன
• காலியான டேட்டாபேஸில் மீட்டெடுப்பு சோதிக்கப்பட்டது, வரிசை எண்ணிக்கைகள் சரிபார்க்கப்பட்டன
• ஒவ்வொரு ஆபத்தான மாற்றத்துக்கு முன்பும் பேக்கப் எடுக்கப்படுகிறது

கேள்விகள்